dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Aug 13, 2008 at 05:23:19PM +0200, Niclas Jansson wrote:
> Ola Skavhaug wrote:
> >
> >
> > On Wed, Aug 13, 2008 at 2:57 PM, Johan Hoffman <jhoffman@xxxxxxxxxx 
> > <mailto:jhoffman@xxxxxxxxxx>> wrote:
> >
> >     >
> >     >
> >     > Johan Hoffman wrote:
> >     >>>
> >     >>> Anders Logg wrote:
> >     >>>> On Tue, Jun 17, 2008 at 02:45:41PM +0100, Garth N. Wells wrote:
> >     >>>>> It would be useful to lay out a plan for tackling DofMaps.
> >     Getting
> >     >>>>> this
> >     >>>>> right is the key to parallel assembly, assembly
> >     optimisations and
> >     >>>>> applying Dirichlet boundary conditions by eliminating
> >     Dirichlet dofs
> >     >>>>> from the global system.
> >     >>>>>
> >     >>>>> I'm happy to take a look, but I'll need some time because
> >     I've lost
> >     >>>>> my
> >     >>>>> overview of DofMaps. If someone else is already on top of
> >     it, I'd be
> >     >>>>> happy to provide feedback.
> >     >>>>>
> >     >>>>> Garth
> >     >>>> I won't have time to look at it until after the summer and I
> >     haven't
> >     >>>> started.
> >     >>>>
> >     >>>> Anyway, I think we should wait until after the next release
> >     until we
> >     >>>> start messing with the dof maps.
> >     >>>>
> >     >>>> Are there any issues we need to sort out before releasing
> >     0.8? I'm
> >     >>>> thinking about a new release some time this or next week.
> >     >>>>
> >     >>>> One is to fix the bug in DirichletBC, but other than that?
> >     >>>>
> >     >>> Now would be a good time for a release so I can start messing with
> >     >>> DofMaps.
> >     >>>
> >     >>> Garth
> >     >>
> >     >> Has anything more been done about the DofMap design? During the
> >     summer
> >     >> Niclas has extended to general elements his adaptive algorithm for
> >     >> distributed parallel computing, so we are now ready to start
> >     messing
> >     >> with
> >     >> the DofMaps in order to implement his algorithm in DOLFIN.
> >     >>
> >     >
> >     > It has been given some thought, but no changes have been made in the
> >     > code yet.
> >
> >     Ok. Any threads on the list to point to where this is discussed?
> >
> >     If you have something already, I would suggest making it
> >     > publicly available somewhere for feedback before starting work
> >     on DOLFIN.
> >
> >     It is a refinement and generalization of the thesis work of Niclas
> >     Jansson
> >     which was discussed on the list before the summer. Is is outlined
> >     in his
> >     report:
> >     http://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2008/rapporter08/jansson_niclas_08051.pdf
> >
> >     My announcement here was to initiate a discussion of the detailed
> >     implementation, and to check if other DOLFIN-people were working on
> >     similar stuff to avoid double/conflicting development.
> >
> >     /Johan
> >
> >
> > Very good. We were about to start on this task, so now a good point in 
> > time to join forces.
> > As a starting point, it would be nice to agreeing on what data is 
> > needed in addition to the partitioned meshes to construct the global 
> > dofmap. I.e. which MeshFunctions to construct during the mesh 
> > paritioning process. Are you people using the same {T,S,F} input as 
> > Anders describes in Algorithm 5 in his paper?
> >
> >
> > Ola
> 
> No, we use a set of MeshFunctions marking ghosted/shared vertices.
> However, the algorithm is almost the same.
> 
> Input: Distributed mesh T
> 
> 1) extract interior boundary I of T  (boundary between processors).
> 
> 2) iterate over I and decide which processor should renumber which 
> shared dof.
> 
> 3) compute offset_i for each processor i.
> 
> 4) renumber all dofs on processor i starting from offset_i (local + 
> (assigned) shared).
> 
> 5) exchange assigned numbers for shared dofs.

Yes, it's very similar. The main difference seems to be that you start
with markers for shared vertices and we plan to mark shared facets.
It seems easier to work with facets since the key to resolving shared
dofs is a call to tabulate_facet_dofs.

The plan is for the assembler to call DofMapSet::build() somewhere
before assembly. This is now commented out in Assembler.cpp in the
function initGlobalTensor().

This will generate a call to the build() function for each DofMap in
the DofMapSet, which in turn will call DofMapBuilder::build() which
implements the algorithm for computing the global (parallel) dof map.

The idea (of Algorithm 5 in the paper) is to compute a global dof map
in parallel from a given local dof map (as given by tabulate_dofs) on
each local mesh.

Each processor owns a Mesh (conceptually a part of a bigger mesh) and
data encoding the overlap (in Sieve-speak). The overlap is stored as
two MeshFunctions in the data section (MeshData) of the Mesh:

  MeshFunction<uint>* S = mesh.data().meshFunction("subdomain overlap");
  MeshFunction<uint>* F = mesh.data().meshFunction("facet overlap");

If you have a working algorithm you can throw into
DofMapBuilder::build(), please send a patch so we can try it out.

-- 
Anders

Attachment: signature.asc
Description: Digital signature