dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #09357
Re: XML format for Higher Order meshes
On Mon, Aug 25, 2008 at 12:14:15PM -0400, Shawn Walker wrote:
>
> On Mon, 25 Aug 2008, Jed Brown wrote:
>
> > It would be nice to store and manipulate the coordinates just like any
> > other Function. Suppose the basis operations accept (in some way) a
> > NULL coordinate vector which means that the element Jacobian is the
> > identity everywhere. That way you could manipulate mesh geometry by
> > evaluating forms to construct a new geometry Function. Then register
> > this new Function (i.e. compute associated element Jacobians, required
> > facet normals).
>
> I agree it would be nice. But this function would need to feed into
> various routines, like Tabulate_Tensor. Would this just become part of
> the `w' coefficient vector? Or would there need to be another input to
> these routines? Or could the cell class contain this? I will have to
> think about it some more...
>
> - Shawn
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.
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
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.
--
Anders
Attachment:
signature.asc
Description: Digital signature
Follow ups
References
-
Re: XML format for Higher Order meshes
From: Shawn Walker, 2008-08-24
-
Re: XML format for Higher Order meshes
From: Anders Logg, 2008-08-24
-
Re: XML format for Higher Order meshes
From: Shawn Walker, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Anders Logg, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Jed Brown, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Shawn Walker, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Jed Brown, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Shawn Walker, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Jed Brown, 2008-08-25
-
Re: XML format for Higher Order meshes
From: Shawn Walker, 2008-08-25