dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, May 15, 2009 at 01:06:44PM +0100, Garth N. Wells wrote:
> 
> 
> Martin Sandve Alnæs wrote:
> > On Fri, May 15, 2009 at 1:37 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> There have been some big changes to the code lately. Here's a summary:
> >>
> >> 1. We now use the wrappers module in dolfin_utils to generate the
> >> DOLFIN wrapper code (in both FFC and SFC). This module generates
> >> slightly different code to the old FFC wrappers. Most notably,
> >> typedefs are used to avoid code duplication and classes/namespaces are
> >> now nested. For application code, that means one must change from
> >>
> >>  PrefixBilinearForm
> >>  PrefixLinearForm
> >>  PrefixTestSpace
> >>  PrefixTrialSpace
> >> to
> >>
> >>  Prefix::BilinearForm
> >>  Prefix::LinearForm
> >>  Prefix::BilinearForm::TestSpace
> >>  Prefix::BilinearForm::TrialSpace
> >>
> >> etc.
> >>
> >> If all test and trial spaces are equal, then a common class named
> >>
> >>  Prefix::FunctionSpace
> >>
> >> will be created (a typedef).
> >>
> >> Some of you may remember that we've had this interface before, but
> >> then had to remove it due to problems with SWIG. Now that SWIG just
> >> looks at the pure UFC code it's not a problem anymore.
> > 
> > Also note that forms and function spaces for coefficients are available by name:
> > 
> > a = c*u*v*dx
> > L = f*v*dx
> > ->
> > Prefix::Form_a
> > Prefix::Form_L
> > Prefix::Form_a::CoefficientSpace_c
> > Prefix::Form_a::CoefficientSpace_L
> > 
> 
> This is very useful and a nice improvement.
> 
> > and coefficients can be set easily using
> > 
> > Prefix::CoefficientSet coeffs;
> > coeffs.c = my_function_c;
> > coeffs.f = my_function_f;
> > Prefix::Form_a a(V, V, coeffs);
> > Prefix::Form_L L(V, coeffs);
> > 
> > which avoids duplication of  lines like "my_form.f = my_function_f;"
> > for coefficients shared by multiple forms.
> > 
> 
> Nice.
> 
> 
> > 
> >> 2. Initialization of mesh entities now happens in the constructor of
> >> DofMap. The initialization happens automitcally only if the new
> >> non-const (wrt Mesh) constructor of FunctionSpace is used. If the
> >> const version is used, then an error message is given. So if you solve
> >> something with P2 elements and need the edges, these must either first
> >> be generated using mesh.init(1) or the non-const constructor must be
> >> used. Most demos should remain unchanged.
> >>
> >> 3. When running in parallel not only will the entities be generated,
> >> but they will also be numbered globally. So all mesh entities have a
> >> unique global index accessible in the data section of a mesh (named
> >> "global entity indices %d"). The global dof map should also be
> >> computed correctly now but I haven't checked. This means we may in
> >> principle assemble in parallel now. But probably not in
> >> practice... :-)
> > 
> > 
> > Great :)
> > 
> 
> Very good. What's the situation with mesh i/o? Is is serial?

No, that's also parallel (at least the i part). Here's a quick summary:

1. The mesh is read in parallel, each process reading data into LocalMeshData.

2. The cells are partitioned in parallel using ParMETIS (we can add an
interface to SCOTCH later).

3. The cells are redistributed among the processes according to the
partition.

4. The vertices are redistributed among the processes according to the
cell distribution.

5. Each process then sits with its own Mesh (just a standard DOLFIN
mesh) for its part of the domain. The data for parallel computation is
stored as auxiliary data in the data section:

  "num global entities"
  "global_entity_indices 0"
  "global_entity_indices 1"
  ...
  "overlap"

6. Mesh entities are created in the DofMap constructor and then
numbered globally.

7. UFCCell is parallel aware and fills in the ufc::cell data using the
global entity indices (from the mesh data section) rather than the
local entity indices (from the mesh topology) when running in
parallel.

8. Assembly should then essentially work. But note that the dof map is
not very efficient since it may be spread all over the place. To make
it efficient, we need to renumber the dofs. Having unique global
entity indices guarantees a correct dof map, but it may not be
optimally ordered. So the reordering needs to be (re)implemented to
make it efficient. We also need to look over the initialization of
sparsity patterns and parallel matrices.

Most things are handled by the class MeshPartitioning.

-- 
Anders

Attachment: signature.asc
Description: Digital signature