← Back to team overview

dolfin team mailing list archive

Re: DofMapSet design

 

Niclas Jansson wrote:
Anders Logg wrote:
On Thu, Aug 14, 2008 at 01:23:26PM +0200, Johan Hoffman wrote:

On Thu, Aug 14, 2008 at 11:48:14AM +0200, Johan Hoffman wrote:

On Wed, Aug 13, 2008 at 2:57 PM, Johan Hoffman <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?

We have discussed this, and it seems that for our adaptive algorithms we
need some more info. Basically, we have two aims:

1. Fully distributed computing (no collection of data on one processor)
2. Possibility for dynamic load balancing

To realize 1-2 we need information on the processor ownership of
entities,
and for resdistributing the mesh we need global vertex numbering. That
is,
we would need something like: {T,S,F,V,O}, where V is global vertex
number
and O is information whether boundary (between processors) vertices are
own by the processor or if they are ghost nodes.

How do you deal with global edge or face numbers?

I believe this is rebuilt from global vertex numbers.

The mesh will number the edges and faces, and then the generated UFC
code will compute a dof map from those edge and face numbers. The
local dof map will look different for different elements and the
global must be based on the local.


My suggestion is to start without a global numbering and then build it
(in parallel).

I am not sure how from only local info you can construct information on
which boundary vertices are owned by which processes?

Each processor knows which facets are shared and with which other
process.


 Possibly this is too much information, since for example S,F can be
computed from V,O, but by storing all info faster algorithms can be
constructed, so there is a trad-off between speed and memory.

What do you say?

If you have something that works, just send us a patch so we can try it.

Niclas can send you his code.

Send it to the list, and even better as a patch for DofMapBuilder::build().
If it works we can just use it.

--
Anders

I send the code to the list.  It's not suitable as a patch due to the
modification done to the Mesh class.

Niclas
_______________________________________________




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









Follow ups

References