I've added rudimentary* support to ufl in next for representing

  v0 = TestFunction(V0, part=0)
  v1 = TestFunction(V1, part=1)
  u0 = TrialFunction(V0, part=0)
  u1 = TrialFunction(V1, part=1)

No algorithms are updated, so e.g. lhs,rhs,adjoint won't work with this yet.

I've also added the 'quadrature' measure *dQ to ufc, and the
'quadrature_integral' to ufc.

So then we can represent the diagonal terms of a coupled system:

  v0*u0*dx
  v1*u1*dx

and the offdiagonals:

  v0*u1*dQ(...)
  v1*u0*dQ(...)

all in one form:

  a = v0*u0*dx + v1*u1*dx + v0*u1*dQ(...) + v1*u0*dQ(...)

One approach going forward could be to split "a" automatically into the
blocks and create separate forms, and create some type of ufc::block_form
to collect them.

For me the unclear part now is represented by the (...) above. The
ufc::quadrature_integral::tabulate_tensor signature is generic enough for
both overlapping and interface types of integrals, with mesh and level sets
or two meshes.

But we still need to create some kind of "Domain" object in ufl to
represent whatever it is dQ integrates over. The properties of that object
must include the geometric dimension, but cell and tdim can be undefined.
In the python layer this object can possibly carry a mesh-like data
structure with e.g. cell relations between meshes, within the current ufl
design.

  mesh0 = Mesh(...)
  mesh1 = Mesh(...)

  # Create dolfin data structure for
  # mesh-mesh or mesh-levelset relations,
  # basically something providing a set of
  # (cell0,cell1,qpoints) tuples to iterate over in the assembler:
  meshrelations = MeshWhatever(mesh0, mesh1)

  a = (u0*v0*dx(mesh0)
    + u1*v1*dx(mesh1)
    + u0*v1*dQ(meshrelations)
    + u1*v0*dQ(meshrelations))

Comments? Do we have any use cases that doesn't fit into this?

Martin
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to