Current status

What works now:

• Expression of multimesh/cut FEM methods in UFL using ``dc = Measure("custom")``` .
• Code generation with FFC for forms containing dc (using quadrature backend).
• Interface in UFC using custom_integral.
• Assembly in DOLFIN of custom_integral using ``MultiMeshAssembler``` .

What needs to be improved / work in progress:

• New special (named) measures in UFL: dc (cut cells), di (interface), do (overlap) so that integral can be expressed without using dc + metadata as today.
• Interface extensions for these new measures in UFC.
• Syntactic sugar (lots of it) in DOLFIN so that function spaces etc can be created more easily without needing to repeatedly add to multimesh objects and then calling build().
• Python interface support.

UFL interface to multimesh

Multiple domains in form

MSA already implemented infrastructure for multiple domains within a form last year. Each function can have a different domain, and the integration domain is specified separately with the measure.

Get num_cells from the actual number of domains

By adding num_meshes to ufc::form and friends, we can easily propagate the actual number of meshes from the UFL form/integrand to the ufc form and the dolfin assembler. Coordinate dofs from the meshes will be passed to UFC ordered by id() just like dofs from Functions are. The assembler must also assert that the functions and meshes match as expected by getting that from suitable new ufc::form functions.

AL: Not sure num_meshes a good idea. The number of meshes is decided at run-time and the same form should be able to work seamlessly with any number of meshes.

Splitting custom integral measure into three

All the other integrals follow the same pattern: *dFoo with measure name "bar" in ufl matches "bar_integral" in ufc and "assemble_bar_integrals" in dolfin. The multimesh work seems to stabilise on three measure types in practice:

• "domain integral" (needs another name): regular dx where possible + custom points in some cells to subtract overlapping region. Could this just be *dx, with the custom quadrature point version of tabulate_tensor always generated?

AL: Yes, this might be a good idea since we actually do this:

dX = dx + dc0 # domain integral

and then use dX in the integrals. BUT: One should also be able to express integrals over only the cut cells so I'm not sure.

• "overlap integral": do is almost like dx, but over fragments of cells.

AL: The point with do is that it is like a dS integral in that it integrates functions from different overlapping meshes in that region. So it is on a fragment common to several cells (possibly more than two).

MSA: Say the integration fragment is a subset of three cells. Can you identify one of the three meshes as being more like "the mesh" than the other two, while the other meshes are found from the function spaces occuring in the form? If so we can maybe use

f_on_mesh1 * g_on_mesh2 * do(mesh0)

Otherwise we may need to add a Domain subclass MeshOverlap to ufl:

overlap = MeshOverlap([mesh0, mesh1, mesh2])
f_on_mesh1 * g_on_mesh2 * do(overlap)

Here all three meshes must have the same gdim and tdim, right?

AL: Yes, this might be useful. But: what is interface and what is overlap etc is (at least for the methods we have considered and implemented) always decided canonically from the meshes involved. So it may be any number of meshes (decided at runtime) and what is the overlap and what is interface etc is decide by a convention.

• "interface integral": di is almost like ds, but over fragments of the facets of one mesh, with coefficients and/or arguments living on a number of domains. Suggested notation: integrand*di(domain=mesh_which_owns_the_facets).

Moving the encoding of integral type from the subdomain id property of the measure to the integral type property of the measure will also stop misuse of abstractions and open for use of subdomain ids and mesh markers in the multimesh assembler.

AL: My suggestion would be to add three new integrals: dc, di, do and let each of these correspond to a new integral class in UFC with the corresponding name: cut_cell_integral, interface_integral, overlap_integral. We also need to keep custom_integral for special cases.

Automating the choice of assembler to use in dolfin

Ideally, by looking at the integral types available in the form, dolfin should be able to invoke the multimesh assembler when necessary. All the above can however be done first, and then we can see. We can possibly generate some boilerplate dolfin code as well as mentioned in demos

AL: Good point

Dependencies

See also FunctionSpace_in_UFL.