On Mon, 5 Jan 2009, Anders Logg wrote:
On Fri, Dec 12, 2008 at 08:53:22AM -0500, Shawn Walker wrote:
I have not been saying much during all of this, but I have been listening
a bit. :)
I would like to know if the new function space stuff is ready to be used
in implementing higher order meshes. I started looking into this a long
time ago, but then there was this big re-work. The stuff I did before
was kind of a hack, so hopefully this new function space interface will
allow for easily reading in higher order mesh info.
At this point, I just want to read in a higher order mesh and have that
info be available to the matrix assembly. And nothing else. I'm also
not proposing that this go into your release.
Any comments? I will have to relearn this new interface.
Sorry about the long delay.
Now problem.
The new class FunctionSpace makes it possible to put the information
about the higher order mapping either into the mesh or into the
function space. So there seem to be three options:
1. Add the extra information for higher order meshes into
MeshGeometry. I think this is what was planned before.
2. Add the extra information as auxiliary mesh data in the MeshData of
a Mesh.
3. Add the extra information as an additional member in FunctionSpace,
in addition to a Mesh, FiniteElement and DofMap.
I don't have a clear view on how to do this and haven't thought much
about it for a long time so let's hear some opinions.
It seems that #3 is the most logical. A higher order mesh will affect
the domain shape and also the way the edge facets are shaped. As long as
all of this information is available to the assembler, then that should
be fine.
However, in using iso-parametric elements, one needs a 'reference' mesh
to define them. So would one use a reference functionspace here? I
think we agreed way back that the higher order mesh data should be stored
as a finite element function. But then you need a functionspace, right?
But before a function space is even declared, we need to create a mesh
with the higher order data stored somewhere. Probably, we will still
need either #1 or #2.
Any other comments are more than welcome!