I cleared out the old email some because the discussion had changed a
little. See below for a recap of higher order mesh data stuff:
-------------
It will if we want to be able to store a higher-order function space
as a function space with a regular mesh and an additional function
that stores the layout of the coordinates.
Perhaps that is not the best way to do the higher order mesh
coordinates.
If we want the higher order mesh data to be a general Function
(requiring
a FunctionSpace), then I do not see how you can get away from needing
the
FiniteElement signature associated with it, and possibly other things.
Even if you have the vector of data and the DoFmap, that info must
still
be used to create a Function/FunctionSpace in the code. And in order
for
that to work the DoFmap must be `compatible' with the particular
FiniteElement you will be using. I probably have this wrong, sorry for
my confusion.
Another way to do the higher order mesh data would be to keep a little
simpler. Have a vector of data, a DoFmap, and an indicator about the
degree of polynomial used. This would be less general but not bad. In
case of higher-order mesh data, you will ALWAYS use a continuous
lagrange
finite element. At least I cannot think of a situation where you would
use something else. Would this not be desirable?
If we decide to remove input/output for Functions and FunctionSpaces
(as I've understood is desirable since we then we don't need to rely
on precompiled elements and dofmaps) then how should we read in a
higher-order mesh from file?
Anders wrote:
Here's one option:
Mesh mesh("mesh");
LagrangeFunctionSpace V(mesh);
File file("mesh_coordinate_vector.xml");
Vector x;
file >> x;
V.set_coordinates(x);
That might work, but it's a bit long. There should be room for
improvement.
The discussion on higher-order meshes got a bit confusing for me a
little while back. In summary, exactly what information intended to be
in the mesh file for a high-order mesh?
Garth
-------------------------------------------
Ok, I will try to recap the higher order mesh stuff.
Currently, in a triangulation, there is an implicit assumption on the
form of the map that takes you from the `unit' reference triangle (or
tetrahedron). The assumption is that the local map is linear. As you
well know, this makes for various simplifications which can be used
during matrix assembly.
But, for various reasons, it can be more useful (or possibly required
depending on the nature of the FEM method) to have a curved triangle to
better approximate domain boundaries or to better compute higher order
geometric motion!
In this case, one could use a vector quadratic polynomial map and have a
triangle with edges given by a quadratic parametrization. The
implementation of this only requires a local Lagrange finite element
basis, whose DoFs are just the coordinates of the nodes (for a quadratic
polynomial on a 2-D triangle, this would be 6 nodes per triangle). Of
course, you will have this for every triangle, and it makes sense to
take the finite element basis to be continuous lagrange over the whole
domain. This continuity is especially important when deforming the mesh!
So, way back we thought it would be a good idea to have a separate
functionspace to store this `higher order' mesh data. But that seemed
problematic.
