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 <[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
> _______________________________________________
>
>   



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







_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev

Reply via email to