dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 06, 2009 at 09:16:42AM -0400, Shawn Walker wrote:
>
> On Mon, 6 Apr 2009, Anders Logg wrote:
>
>> On Thu, Apr 02, 2009 at 11:12:20AM -0400, Shawn Walker wrote:
>>> Hello all.
>>>
>>> I have finally got some time to put in (at least the first stage) the
>>> higher order mesh stuff for triangles
>>> mapped with P2 lagrange elements. Just to remind you, the agreement that
>>> we came up with was this:
>>>
>>> 1. The local mapping for each element is independent of whatever finite
>>> elements you are using.  Thus, there
>>> should be a completely different description of the mapping.
>>
>> Sounds good.
>>
>>> 2. This info will be stored in MeshGeometry with extra data structures.
>>
>> Sounds good.
>>
>>> 3. The info to store is (i) all the higher order vertex position data, and
>>> (ii) the `DoFmap' for your
>>> particular map.  Storing the extra vertex data is just like storing the
>>> usual 3 triangle coordinates.
>>
>> Are you thinking of using DofMap for this?
>
> I was thinking of this, but not sure how to do it, i.e. read it into the  
> DoFmap structure.  For now I just have it as an array.

An array is good.

>>> 4. Eventually, for computing the local finite element matrices, there just
>>> needs to be a short subroutine
>>> that returns the higher order vertex data (for a specific cell) to be used
>>> by, say, the code generated by
>>> FFC.
>>
>> Yes.
>>
>>> My question is about the dofmap.  It is certainly reasonable to store it
>>> similarly to the vertex data.  But
>>> there is a problem if the mesh is locally refined.  It seems like it will
>>> be a pain to modify this data
>>> structure.  Any suggestions for this?
>>
>> When a mesh is locally refined, an entirely new mesh is created. The
>> mesh class stores all data in large arrays so all mesh data needs to
>> be copied to new data structures anyway.
>
> ok.  Are there any plans to have binary tree type meshes?  This is the  
> main reason some people use Alberta, plus it has multigrid.

No immediate plans that I know of (but it might be nice to have).
We could also consider other stuff like extension to hex meshes and
using http://p4est.org/. It's just a matter of resources/priorities.

>>> Remember, we do NOT want to use a function space here.  This was already
>>> discussed!
>>
>> I know, but I keep forgetting why. :-)
>
> One problem was that a Function Space needs a mesh first.  But the higher 
> order geometric mapping is defining the mesh, so kind of a 
> chicken-and-egg problem.  Another thing to keep in mind is that the 
> mapping is completely independent of the finite element.  For instance, 
> you could mix Raviart-Thomas with P2 triangles.

Yes, one would need a different FunctionSpace for the geometry.
But I see the problem.

>> We just removed all the precompiled elements which means one must
>> always instantiate the correct function spaces maunually (at least in
>> C++). The question here is how to create/number the extra nodes. The
>> form compilers already know how to generate code for this, and it
>> would be extra work to try to duplicate that code for the mapping of
>> higher order coordinates. Do you have a good plan for how to number
>> the coordinates?
>
> Well, not particularly, other than the `standard' way.  Any suggestions  
> would be good.

Maybe we can manage for now with having the mapping stored in an
array. It's then the responsibility of the input file to create the
dofmap.

> I have tried emailing my patch twice, but I have not seen that it has 
> come through.  Has anyone seen it?

I haven't. Is it big? Try posting a URL instead.

I won't apply any more patches until we've made the new release. We're
waiting for the buildbot to become green so we can release and then
start breaking stuff again.

-- 
Anders

Attachment: signature.asc
Description: Digital signature