Consider using pure UFL in Python, replacing DOLFIN wrapper classes for UFL types?

[w1th0utnam3]

Currently, it isn't really possible for a user to assemble a system using a pure UFL form + separate DOLFIN objects for the problem instance. DOLFIN wrapper classes have to or should be used to define the form in the first place. Even if conversion between an UFL form and DOLFIN form were possible it seems a little bit weird from a user's perspective to have these two groups of classes that have similar (or the same) names but use different constructor arguments etc.

Maybe it would be clearer and more straight forward to drop all DOLFIN Python wrapper classes for UFL objects, use pure UFL forms for form definitions and ask for function spaces, meshes, etc. only during assembly.

[garth-wells]

This isn't really clear to me. DOLFIN cannot assemble a UFL form directly - it needs to be made into a concrete implementation. Can you clarify?

The naming issue can/will be fixed with proper importing and namespacing, e.g. ufl.Form and dolfin.fem.Form. The present mixing of the namespaces is indeed confusing.

[w1th0utnam3]

Yes, sorry, I thought that some parts of the idea were already established because @blechta suggested that it was already discussed sometime. Maybe I'm also missing some points because I don't have the whole picture.

So, FFC can compile a form defined using only UFL classes. In order to solve a problem with DOLFIN, problem instance specific information is needed as you said. I think the idea was to also split these two parts when using DOLFIN. Define the form using pure UFL first (so that it could be compiled by FFC), followed by attaching the problem specific information. The latter could be done e.g. using arguments for the assembly function.

I guess that one motivation of the current approach of using the DOLFIN wrappers is to make the the problem definition look more math like and more intuitive for a user? That would probably require some thinking in a split approach.

Initially I asked in Slack about the compatibility between UFL and Dolfin forms because I benchmarked the code generated by FFC from UFL forms (by supplying random data to the generated tabulate_tensor functions). When I wanted to benchmark the assembly using DOLFIN afterwards, I noticed that I basically have to create a second list of forms, by rewriting all forms using DOLFIN classes instead of just being able to attach some data to the UFL forms.

[blechta]

I agree with @w1th0utnam3 that this is a known problem. DOLFIN does not allow to use pure UFL for assembly along the lines of

e = ufl.FiniteElement("P", ufl.triangle, 1)
u, v = ufl.TrialFunction(e), ufl.TestFunction(e)
a = u*v*ufl.dx

V = dolfin.FunctionSpace(mesh, e)
dolfin.assemble(a, function_spaces=[V, V])

Instead DOLFIN requires that DOLFIN/UFL wrappers (for form arguments and coefficients which already live on dolfin function space) are used to make it more user friendly. We have already seen elsewhere that (#1) that mixing FE aspects of DOLFIN and UFL for convenience is problematic and arguably should not be done. I believe this aspect has been mentioned when drafting FEniCS-X roadmap.

[garth-wells]

Related issue that should help fix this is FEniCS/ffcx#5.

UFL has a concept of meshes and function spaces (element + continuity + mesh). This is abstract in that a UFL mesh is cell shape(s) and geometric dimension. A UFL form (and the FFC generated code) will know the cell type and dim, and DOLFIN can compliment this with a real dolfin.Mesh, with checking on the dimension and cell types performed at the appropriate point.

The code snippets from @blechta would need some thought on checking the element type.

[jorgensd]

@garth-wells Is there more left in this issue?

[garth-wells]

No recent activity, so closing.