dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Dec 03, 2006 at 09:54:18PM +0100, Garth N. Wells wrote:
> kent-and@xxxxxxxxx wrote:
> >>>> One thing to consider is more sophisticated dof mapping. It is worth
> >>>> considering a special class to take care of this. This would be useful
> >>>> for meshes with mixed cell/element types, parallel assembly and
> >>>> computing sparsity patterns.
> >>> Yes, we could create a separate class in src/fem/ that takes care of
> >>> this. Name suggestions: NodeMap, NodeMapping, Nodes, Dofs, DofHandler,
> >>> ...
> >>>
> >> What about DofHandler or DofManager? I see the class handling the dof
> >> mapping, as well as generating sparsity patterns. I'll add something,
> >> and start with a function for computing the number of non-zeroes per
> >> matrix row (we're overestimating this at the moment substantially which
> >> is giving me some memory problems).
> >>
> >> Garth
> > 
> > You can consider the dof-handler used in SyFi/PyCC. It is not as fast as the
> > nodemap generated by FFC, but it is very flexible. It works for any dofs
> > I know.
> > 
> > It is also only about 100 lines of code, using a STL map. You can find it
> > in the file DofT.h
> >
> 
> I'm working on this right now so I'll take a look at the SyFi handler. 
> I'm planning to offer different possibilities for the mapping, and also 
> to allow user to provide something for special problems if they wish. 
> The current FFC mapping is about as fast as it gets for scalar valued 
> equations. For vector-valued equations, it's not good for sparse assembly.
> 
> Garth

My suggestion would be to let FFC compute the mapping and then reorder
what FFC produces:

  1. Iterate over cells, call FFC code and build mapping

  2. Assembly using the generated mapping

Is this what you have in mind?

Or will the new class know about how to distribute dofs for different
elements?

/Anders