dolfin team mailing list archive

[Bartosz Sawicki <sawickib@xxxxxxxxxxxxx>]

On 29/12/08 04:14 PM, Anders Logg wrote:
> On Thu, Dec 18, 2008 at 11:55:12AM -0700, Bartosz Sawicki wrote:
> > On 15/12/08 02:26 PM, Bartosz Sawicki wrote:
> > > Hi there,
> > >
> > > I've recently found MeshData class which is very useful for storing 
> > > boundary indicators, materials data and other stuff. I start to use this 
> > > features for my projects, and realized that some details can be easily 
> > > improved.
> > > My ideas for the better MeshData structure:
> > >
> > > 1. const Mesh& Mesh::operator=(const Mesh& mesh)
> > > I think that the live would be much easier, when you add line:
> > >    _data = mesh._data;
> > > This is probably the bug, because I can't understant why not to copy 
> > > data related with mesh object.
>
> Fixed, but I left the assignment operator in MeshData for you to
> implement if you need it. It's there now but there's a warning where
> there needs to be some code. Note that all mesh data must be recreated
> and then the values copied (not one by one, but list by list, the STL
> structures can be copied).

Thanks. I'll send you patch when this will be implemented.

> > > 2. MeshData::createMeshFunction(std::string name)
> > > Would it be possible to create function with 'dim' parameter for new 
> > > MeshFunction? Something like this:
> > > MeshFunction<dolfin::uint>* MeshData::createMeshFunction(std:string 
> > > name, uint dim)
>
> Fixed.
>
> > > 3. MeshData::clear()
> > > The method should clear also 'maps'.
>
> Fixed.
>
> > > 4. MeshData::display()
> > > The method should print also 'maps'.
>
> Please send a patch... :-)

In the attachment. I slightly changed formating, for more pretty printout.

> > > 5. Mesh::data() and its const version can be inline.
>
> Fixed.
>
> > > 6. Do we really need three kinds of structures inside the MeshData 
> > > (MeshFunctions, Arrays, maps)? Every different structure need separate 
> > > treatment, so it would be easier to mountain and learn when it would be 
> > > as simple as possible.
>
> I think we need all three. We obviously need MeshFunction. Then we
> also need Arrays (or rather std::vector) for boundary conditions where
> we have markers on the facets only on the boundary (not the internal
> facets) so we can't use MeshFunction (since the size of the array must
> then be equal to the total number of facets). Then we need the map for
> parallel stuff.

Boundary indicators can be stored in easily MeshFunction( mesh, dim-1), 
as it is done in demos stokes and advection-diffusion.
The most of elements will be zero, but it seems to me as a  more general 
and elegant approach.

The problem with Arrays and maps is that it can't be transformed 
according to the mesh modifications. Meshfunction is perfect solution, 
because it is related with mesh entities.

> > > Any way, I think that MeshData is great feature. :) Thanks.
>
> Thanks. Looking forward to your patch. ;-)

Here you have :)


BArtek

> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

diff -r 815e8988a17d dolfin/mesh/MeshData.cpp
--- a/dolfin/mesh/MeshData.cpp	Tue Dec 30 14:32:00 2008 +0100
+++ b/dolfin/mesh/MeshData.cpp	Tue Dec 30 15:58:04 2008 -0700
@@ -160,9 +160,7 @@
 void MeshData::disp() const
 {
   // Begin indentation
-  cout << "Auxiliary mesh data" << endl;
-  begin("-------------------");
-  cout << endl;
+  begin("Auxiliary mesh data");
 
   for (mf_const_iterator it = meshfunctions.begin(); it != meshfunctions.end(); ++it)
   {
@@ -177,6 +175,10 @@
     cout << "Array<uint> of size " << static_cast<uint>(it->second->size())
          << ": \"" << it->first << "\"" << endl;
 
+  for (m_const_iterator it = maps.begin(); it != maps.end(); ++it)
+    cout << "map<uint, uint> of size " << static_cast<uint>(it->second->size())
+         << ": \"" << it->first << "\"" << endl;
+
   // End indentation
   end();
 }