Migrating tsfc backend away from coffee

[wence-]

Hi folks,

we have an intermediate-length plan to drop the coffee code generation backend in tsfc (most of the effort is in the loopy backend, since that's what we're using further down the pipeline). Given that you're presently not doing further transformations on the kernels once they come out of the form compiler, loopy is a pretty large and heavy dependency.

The rationale for this is also that we migrated the coffee optimisation algorithms into earlier tsfc passes, so we're just carrying around a coffee dependency as an IR->C converter [it also has some ugly code generation issues that were fixed "badly"].

At the moment the backend IR -> C code generation is pretty well encapsulated (it's not perfect, but a little refactoring would get there). My suggestion would therefore be to have FFC provide (here, rather than in the tsfc repo) an implementation of TSFCs "kernel_interface" and extend the interface to require code generation too. FFC could then use the existing C IR it has for the uflacs backend.

Am happy to help with the design and implementation, but I expect I will need some help on the FFC side.

Does this sound like a reasonable route forward? We're not going to do this imminently, but flagging now so things don't suddenly break.

[michalhabera]

Hi Lawrence,

thanks for letting us know.
Honestly, current "TSFC representation" is probably broken anyway in FFCx/master. There were several serious changes that impacted the kernel signature.

I think the issue is a bit more global than just your own COFFEE policy. We should in the first place decide about the support for TSFC within FFCx, @garth-wells @chrisrichardson @mscroggs.

Its definitely a good time to think about FFCx-TSFC interface in the light of your loopy pipeline.

[miklos1]

Let me chip in with a few thoughts about the costs and benefits of re-establishing the "TSFC representation" in FFC-X. I think we can all agree that the old UFC interface was ripe for revision, and that the new interface is a clear improvement. However, due to recent developments in FFC-X, there are some more issues than just minor adjustments to kernel argument names and types:

• Ordering and/or sign of facet DoFs: FEniCS uses explicit facet orientations for quadrilaterals and hexahedra, which the form compiler has to know about. (Firedrake, on the other hand, establishes consistent orientations in advance, so that the form compiler does not need to know about orientations.) It is probably not terribly difficult to apply orientations in TSFC, one could just prepend and append the appropriate DoF reordering and/or sign flipping code.
• Loopy transition: see Lawrence's initial comment above.
• FFC-X's own vectorisation: I don't know very much about that, but I saw some time ago that FFC-X has also got support for vectorisation. How does even the assembler interface look like for vectorised kernels? It seems that this feature has been never merged ([WIP] Implementing cross-cell code generation in UFLACS #52).

On the benefits side, I think the primary gain for FEniCS of supporting TSFC is the more intimate integration of the form compiler with the finite elements (through FInAT). This allows to

• Support elements with "strange" pullbacks (e.g., Hermite, Morley, Argyris, Bell, see Add Bell, Argyris, Hermite, and Morley elements FInAT/FInAT#48 and Support for H2 conforming element #245) or directly constructed in physical space (Direct serendipity FInAT/FInAT#58).
• Automatically sum factorise tensor-product elements (Q- family of elements, arXiv:1711.02473).

[miklos1]

Forgot to add to the benefits that, if FEniCS wants to have these features without relying on TSFC, it is hard to see how it could be done without essentially reinventing FInAT and its intermediate representation, etc.

I think all these things are working already with old FEniCS (which has a "TSFC representation"), except for the zany elements (Hermite, Argyris, Morley, Bell) which would need cell sizes information from DOLFIN.

[garth-wells]

Closing this issue as things have move on considerably in the meantime.