Generate transforms experimental

[gmarkall]

Changes required for the transform to be generated as part of the kernel. Tested on the buildbot and passing all tests.

A high-level overview of the changes made:

• The vector field Coordinate is added to the state so that it is extracted from the Fluidity state in the generated code.
• Factory functions for the Jacobian, its determinant and its inverse have been added - these generate the UFL representation of J, detJ and invJ.
• A string preprocessing pipeline stage has been added that post-multiplies each form by detJ. This incorporates the determinant into the code that is generated automatically. grad and div are also re-defined so that they give the code to perform the computation of the transformed derivative by multiplication of the values at the coordinates and the inverse of the Jacobian.
• Femtools is now queried for quadrature and shape information. This is used to declare automatic arrays inside kernels for the quadrature weights and basis function values.
• The code generation module has support for building multi-dimensional array initialisers for the basis functions and quadrature weights.
• The transform_to_physical kernels are removed. Instead of passing detwei and basis functions to local assembly kernels, the kernel receives the Coordinate field as a Coefficient instead. The Jacobian is calculated in the quadrature loop as a function of the coordinates and derivatives of the basis functions in the standard way.
• The KernelParameterGenerator has been removed completely as it is now superfluous.
• A partitioner has been added to the pipeline that finds the maximal subtrees of a UFL expression tree that contain the same indices and is rooted by a single node. It denotes these by inserting SubExpr nodes at these points.
• The code generation in the ExpressionBuilder class has been changed so that it generates an expression for each SubExpr partition, and accumulates its value into a temporary variable. The Local Tensor expression is computed from these subexpression contributions at the end of the loop body.
• Support for generating code for representing ListTensors has been added - these are represented by a name that is a function of the indices by which they are subscripted.

[gmarkall]

I'm not sure what you mean but I'll try to answer - we can't keep these objects as subclasses of Transformer because the Transformer._handlers_cache doesn't get updated, only the UserDefinedClassTransformer._handlers_cache gets updated with handlers for our user-defined classes.

The reason that the handlers are only updated in UserDefinedClassTransfomer was to avoid messing with the internal state of ufl.Transformer.

Or do you mean that the name UserDefinedClassTransformer is inappropriate? It is a bit long.

[kynan]

My comment was confusing. I meant to say it could override ufl.Transformer in the same way we have overrides for TestFunction/TrialFunction - which is exactly what your last commit does.