Shawn Walker wrote:
> 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.
>
Sounds complicated.
> However, in principle, all you need is a DoFmap and a vector of data
> containing the node coordinate positions.
This is what I thought. Will we add a field the Mesh xml file to store
this extra data?
And you need a method for
> updating the positions (for a deforming mesh) but that isn't a big deal.
> Once this information is properly stored, and accessible to the matrix
> assembler, THEN...
>
> Then the next step would be to modify FFC to use this higher order
> (locally defined) map to compute the local matrices, INSTEAD of the
> linear map that is implicitly assumed now.
>
> I realize this will take some time, but we at least need to get a
> storage scheme for the higher order mesh data to even proceed!
>
Kristian is looking at the UFL transition for the FFC quadrature
representation at the moment which will be needed for non-affine maps.
Perhaps a smaller first step in the non-affine direction would be to
support quadrilateral elements.
Garth
> - Shawn
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
