dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Aug 25, 2008 at 01:18:33PM -0400, Shawn Walker wrote:
>
> On Mon, 25 Aug 2008, Anders Logg wrote:
>
>> Actually, this would work and would require the least amount of
>> modification of current code.
>>
>> We can just store a vector-valued P2 Function for the coordinates (or
>> any other order).
>>
>> The XML format already handles input/output of Functions so this would
>> be easy.
>>
>> A couple caveats though:
>>
>> 1. This requires having the corresponding elements and dof maps
>> precompiled in DOLFIN. This should be ok, considering they are already
>> there.
>
> Just to clarify, you mean if we were to use 5th order continuous lagrange 
> elements for the mesh element geometry, we must make sure this particular 
> finite element is implemented.  That is certainly reasonable!

It's definitely implemented (in FIAT/FFC or SyFi) for general order,
but it also needs to be precompiled into DOLFIN so that DOLFIN knows
how to layout degrees of freedom and evaluate basis functions.

This is done in dolfin/elements/, in particular the file elements.py
which defines the elements that are compiled into DOLFIN. We need to
be restrictive with which elements we include since it adds to the
compilation time for DOLFIN.

>> 2. It also makes an assumption about the numbering of degrees of
>> freedom (and mesh entities) always being the same. This can be handled
>> by adding a new tag <dofmap> under <function> that contains the dofs
>> explicitly (not the signature of the FFC dof map).
>>
>> The XML format could be something like
>>
>>  <mesh celltype="triangle" dim="2">
>>    <vertices size="2868">
>>      <vertex index="0" x="0.534923" y="0.326073"/>
>>      ...
>>    </vertices>
>>    <cells size="5400">
>>      <triangle index="0" v0="76" v1="914" v2="1153"/>
>>      ...
>>    </cells>
>>    <coordinates>
>>      <function>
>>
>>      </function>
>>    </coordinates>
>>  <mesh
>
> ok, I guess you would need to add an attribute to the `function' to  
> specify what kind of finite element it is.  You could also add a boolean  
> function to the <coordinates> section that would indicate whether the  
> element is indeed curved or not.

Yes, we could do something like

<coordinates degree="2">

and then have the boolean affine="true"/"false" inside the cell tags.

>> This would mean storing the vertex coordinates twice, but I think we
>> can live with that. The <coordinates> section would be optional. If it
>> exists, it will allocate a Function inside MeshGeometry which would
>> otherwise be null.
>
> As long as this function is easily accessible by the relevant routines  
> (i.e. Tabulate_Tensor) this seems ok.  Then it would just be a matter of  
> how FFC implements the computation.

The only place we need to worry about this is in UFCCell where we copy
the values from DOLFIN data structures (like Cell, Vertex etc) to the
UFC data structure ufc::cell. This is easy to modify.

> Is there a specific demo that reads in a function similar to this?  I  
> would like an example to look at.
>
> - Shawn

Yes, demo/pde/convection-diffusion/.

-- 
Anders

Attachment: signature.asc
Description: Digital signature