Extend ufl/dolfin integration with mirroring of function space and mesh classes
New types will need to be introduced in ufl for this, and dolfin types will need adjustment as well. A natural progression seems to be:
- DONE: Make a new ufl.FunctionSpace class
- DONE: Make a ufl.Mesh class (formerly ufl.Domain) (For now dolfin.Mesh has a ufl.Mesh instead of being one).
- DONE: Revert ufl.FiniteElement to use a Cell and not a Domain. (For now dolfin.FunctionSpace has a ufl.FunctionSpace instead of being one).
- DONE: Make ufl.Mesh have a coordinate element without circular references
- DONE: Add a 'degree' property to dolfin.MeshGeometry (currently always 1) and use this to create a ufl.Mesh with a Lagrange coordinate element
This involved a lot of refactoring and renaming and is infrastructure for a range of features. One such feature is non-affine domains fully integrated in all of dolfin. Another feature is a nice interface for the multimesh support that Anders is working on. The final goal includes being able to express mixed function spaces over multiple meshviews of different topological dimension, with the possible extension to multiple meshes. Something like this, but the design will be iterative:
cell = triangle
coordinate_element = VectorElement("Lagrange", cell, 2)
element = FiniteElement("Lagrange", cell, 2)
mesh = Mesh(coordinate_element)
meshview1 = MeshView(mesh, codim=1)
meshview2 = MeshView(mesh, codim=0)
V = FunctionSpace(mesh, element)
V1 = FunctionSpace(meshview1, element)
V2 = FunctionSpace(meshview2, element)
W = MixedFunctionSpace(V, V1, V2)
u = TrialFunction(W)
v = TestFunction(W)
a = inner(u,v)*dx
Having a nice interface to these features is not just sugar coating, it's necessary to be able to fully combine these features with automatic differentiation and automated optimization.
Work on MeshView and MixedFunctionSpace was previously mentioned here, but those warrant their own issues. Further work on extending dolfin Mesh degree > 1 should also be its own issue.
Comments (13)
-
reporter -
reporter - edited description
-
reporter - edited description
-
reporter - changed milestone to 1.6
-
reporter - removed responsible
-
reporter -
assigned issue to
-
assigned issue to
-
reporter -
reporter This is work in progress now, however it's difficult and possibly not necessary to use as much inheritance as suggested above.
-
reporter - changed title to Extend ufl/dolfin integration with mirroring of function space and mesh classes
- changed component to python interface
- edited description
-
reporter With the branches in next now much of the fundamentals here are done. However don't get your hopes up when reading this: the issue was too big so I narrowed it down quite a bit. Also the non-affine mesh functionality will be inaccessible now until we fix dolfin.
-
Could we close this issue and create new issues for the specifics?
-
reporter - changed status to resolved
Most of the issues mentioned here are done. If anything important is left, it will show up when considering other issues.
-
- removed milestone
Removing milestone: 1.7 (automated comment)
- Log in to comment
Here's a use case that shows why these design changes are necessary:
Reason:
I'll get back to explaining in more detail.