Mixed multimesh function spaces in Python

[Anders Logg (Chalmers)]

Mixed multimesh function spaces must currently be created in a somewhat cryptic fashion:

def function_space_constructor(mesh):
    V = VectorFunctionSpace(mesh, "Lagrange", 2)
    Q = FunctionSpace(mesh, "Lagrange", 1)
    return V * Q
W = MultiMeshFunctionSpace(multimesh, function_space_constructor)

This is because a multimesh function space must be created from a collection of standard spaces and also because the function space algebra is not support specifically for multimesh function spaces. Things would be messed up if one took the product of two multimesh spaces, since the multimesh hierarchy is by design above the mixed space hierarchy (think offsets).

[Anders Logg (Chalmers)]

This might be solved as part of the removal of MixedFunctionSpace: https://bitbucket.org/fenics-project/dolfin/pull-requests/251/deprecate-mixedfunctionspace/diff#chg-demo/documented/stokes-taylor-hood/python/demo_stokes-taylor-hood.py

[Martin Sandve Alnæs]

Yes, you should just change the second argument to be the mixed element. If I understand it correctly.

[Martin Sandve Alnæs]

Do you always need the original single mesh function spaces?

[Anders Logg (Chalmers)]

Yes, at least that's the design I have chosen. The multimesh space is composed of N singlemesh spaces, but has its own dofmap that is built from the singlemesh dofmaps. Perhaps the initial spaces could be thrown away after they have been used.

[Martin Sandve Alnæs]

Ok, that's what I was wondering about.

If you do not keep relations to the original function spaces, the input should be the element and whether you construct the single-mesh spaces or not is an internal optimization 'detail'.

If you do keep relations to the original function spaces, the input should rather be the actual function spaces.

Can you consider how the multimesh function space should relate to the (currently unused) ufl.MixedFunctionSpace construct? Should they be the same?

ufl.MixedFunctionSpace takes a list of single-mesh(view) FunctionSpaces, however there is no notion of the 'multimesh'.

[Anders Logg (Chalmers)]

I think the right way to think about this is that multimesh is one level above everything else. So first we have single-elements. They can be composed to create mixed-elements. Then elements (single or mixed) can be used to create single-mesh function spaces. Then single-mesh function spaces (either single-element or mixed-element) can be composed to create multi-mesh function spaces. This means that the element types can be different on different spaces.

[Martin Sandve Alnæs]

Yes, and both ufl.MixedFunctionSpace (not the deprecated dolfin.MixedFunctionSpace) and dolfin.MultiMeshFunctionSpace are composed of multiple single-mesh function spaces. (As a sidenote this is also true for the ufl.TensorFunctionSpace to be implemented in the AUQPDE project).

However a difference between ufl.MixedFunctionSpace and dolfin.MultiMeshFunctionSpace is that there is no multimesh data structure in the former. If you want to integrate better with ufl, dolfin.MultiMeshFunctionSpace should inherit from a ufl class for a matching concept, and I'm wondering if ufl.MixedFunctionSpace as it is drafted today is sufficient.

[Anders Logg (Chalmers)]

I think we need to take a longer discussion on this in person. The current design is quite nice and clean in UFL/C++ (I think) but the Python version contains a few tricks and hacks. I can show you when we meet.

[Anders Logg (Chalmers)]

Fix issue #609: Mixed multimesh function spaces in Python

→ <<cset 33715bcf4e9b>>

[Anders Logg (Chalmers)]

Removing milestone: 1.7 (automated comment)