dolfin team mailing list archive

[Niclas Jansson <njansson@xxxxxx>]

Anders Logg wrote:
> On Thu, Aug 14, 2008 at 03:26:07PM +0200, Niclas Jansson wrote:
>   
> > The code could be fetched from
> >
> > http://www.csc.kth.se/~njansson/dolfin-2008-08-14.tar.bz2
> >
> > Requires PETSc and parmetis, (customLinkFlags = '-lmetis -lparmetis')
> >
> > DofMap::build don't construct a global dofmap. It reorders the map in
> > order to minimize communication during assembly.
> > The global dofmap is obtained from the ordinary tabulate_dofs call.
> >
> > Niclas
> >     
>
> I think it looks good.
>
> As far as I understand, you build a global numbering of all mesh
> entities (which may be different from the local numbering on each
> processor), and then the (global parallel) local-to-global mapping
> follows from tabulate_dofs just as usual.
>
> So, the difference is that you build a global numbering of the mesh
> entities, and we wanted to build a global numbering of the dofs. The
> only advantage I can see with our approach is that it may use less
> memory, since we don't need to store an extra numbering scheme for all
> mesh entities but this not a big deal.
>
> A few questions:
>
> 1. Is the above interpretation correct?
>   
Yes.

Another disadvantage with the global numbering scheme is the mesh 
connectivity calculations (mesh.init in MeshRenumber).
> 2. Is there a simple example that I can run to test. The code built
> fine but I didn't find any demo.
>   

The poisson, elasticity and nonlinearpoisson demos should work with the 
following modifications
1) Meshes must be loaded from file.
2) plot(u) must be disabled.

or fetch the following http://www.csc.kth.se/~njansson/poisson.tar.bz2
Poisson with mesh refinement and load balancing.
> 3. Does the partitioning require that one processor reads the entire mesh
> and then sends it to ParMetis?
>   
No, the mesh is always distributed.
> 4. Is the extra storage dynamic? If only vertices are needed (for P1
> elements), then we only need to store extra vertex numbers.
>   
No, it always stores a global number for each mesh entity.
> 5. MeshRenumber seems specific to triangles and tets. Can it be done
> without reference to specific entities with special cases put in
> CellType?
>   
Maybe, the problem is to construct a key that could be used to uniquely 
identify the entity.
But, since each entity could be seen as a set of vertices it shouldn't 
be any problem.
> 6. Does it work for assembly over interior facets (like in DG
> methods)?
>   
I'm not sure, haven't tried any DG type problems.
> 7. Is it possible to make it work with SCOTCH (in addition to
> ParMetis)?
>   
Yes, with some modification to MPIMeshCommunicator.
> Then some suggestions:
>
> 1. I'd like to move the implementation of DofMap::build() to
> DofMapBuilder (to simplify DofMap.cpp).
>
> 2. Function names should be fooBar(), not foo_bar().
>   
I recently found doc/misc/policy :)
> 3. There needs to be some #ifdef HAS_PARMETIS so it may be built
> without Parmetis.
>
> 4. I'd like to add a new class GlobalNumbering (to replace
> MeshDistributedData) that holds the global numbering scheme.
>
> The Mesh class can have a pointer to a GlobalNumbering object which is
> 0 by default so no extra data (or at least not more than 4 bytes) is
> stored when not running in parallel.
>
> Then we can add a function MeshEntity::number() which returns the same
> as index() if GlobalNumbering is 0. Otherwise, it returns what is
> stored in GlobalNumbering.
>
> GlobalNumbering can have an array of MeshFunctions, one for each
> topological dimension, that maps the local entity indices to their
> global numbers.
>
> Thus, a MeshEntity will have two functions index() and number().
> These will return the same value in sequential and possibly different
> values in parallel.
>
> Let's await some more comments and then get started. It would be nice
> to get it in small patches to give us an opportunity to comment/edit.
> Adding GlobalNumbering and MeshEntity::number() would be a good start.
>
> --
> Anders
>   
Sounds good, However I think the {T,S,F,V,O} design mentioned by Johan 
is more efficient.

Niclas