Skip to content

Split driver module and apply component-wise code generation without FunctionView (rebased)

Dominic Kempf requested to merge mergesplit into master

This is the rebased version of the merge requests !160 (closed) and !161 (closed) . Description (copied):

Rewrite accumulation term splitting to not use FunctionView

The introduction of FunctionView turned out to be a major problem with more complicated forms. The original idea was to preserver the structure of the finite element in a way, that loops over components of a mixed element are realized by actual loops (treating them with free indices and such). However, this causes quite some nightmares and was never implemented as generically as needed (I even doubt that is possible).

However, there is another option, which is to unroll any such loops on a symbolic level. While this may sound like a bad idea at first there is some really positive aspects about it:

  • ListTensor and ComponentTensor nodes collapse completely (and would otherwise have a big nightmare potential)
  • Symbolic zeroes do not generate code - important in hyperbolic problems where the system matrices are quite sparse or for axiparallel grids, where geometric quantities have many zeroes.
  • The compiler would unroll these small loops anyway.
  • TSFC (and I guess also FFC) do it the same way.

Implementing this required me to redo the form splitting algorithm. I rethought it and integrated it into the main ufl->loopy visitor.

This closes #5 (closed) (though not by fixing it :D), supersedes !153 (closed)

Reworking driver generation

Things done:

  • Split into several modules within a subpackage driver
  • Do not annotate ufl.FiniteElement, instead use magic variables in UFL file
  • Remove our Expression hack
  • interpolate initial conditions
Edited by Dominic Kempf

Merge request reports