Add coordinate degree/element property to MeshGeometry

Issue #321 resolved
Martin Sandve Alnæs created an issue

MeshGeometry needs at least a coordinate_degree() property (currently always 1 because we only support affine meshes) or even better a coordinate_family() property as well. Alternatively a full coordinate_element/FiniteElement property, but that raises dependency issues I'd like to avoid for now: this way Mesh is free to store the coordinate dofs independently of the FiniteElement and DofMap implementation.

Completing this step is the next step for this issue

https://bitbucket.org/fenics-project/dolfin/issue/307

and a necessary step for getting non-affine domains properly in place.

The most critical reason why this is necessary is that whenever dolfin code gets a Mesh from e.g. a FunctionSpace, it needs to know whether the mesh geometry should use an affine or non-affine parameterisation, and the python layer needs to be able to reconstruct the ufl layer with this information from the information available through the C++ Mesh class.

Last year @garth-wells started the implementation of a CoordinateFunction in the branch

https://bitbucket.org/fenics-project/dolfin/branch/garth/add-coordinate-function

but I don't think we'll go that route. We do however need to define a way to access the coordinate dofs, from the assembler what's needed is "get the coordinate dofs for cell i", which for affine meshes is just the vertex coordinate values, and define the numbering (should agree with local finite element numbering to keep ffc/uflacs simple).

Comments (11)

  1. Martin Sandve Alnæs reporter

    I'm just adding MeshGeometry::degree() returning 1 for now. This is then used by ufl/uflacs to define a Lagrange degree N=1 element for the coordinate field. This means when MeshGeometry gets support for degree>1, returning the correct degree will connect to the form compilation pipeline.

  2. Log in to comment