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 <[EMAIL PROTECTED]> >>>>> 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
