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
