On Mon, Aug 25, 2008 at 06:14:49PM -0400, Shawn Walker wrote:
So, would this function be read into a variable inside the MeshGeometry
class? if so, then I will try to modify the XMLMesh file to account for
reading a <coordinates> tag. Although I am still a little confused on
how the proposed <dofmap> tag in <function> works.
- Shawn
Yes, I'd suggest that we add a (private) member variable
Function* coordinates;
to the MeshGeometry class and rename the current array
coordinates to vertex_coordinates.
It should be set to zero if there are no higher order coordinates
available.
--
Anders
On Mon, 25 Aug 2008, Anders Logg wrote:
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.
