MCFC UFL extensions

[kynan]

MCFC extends UFL in two respects:

1. uflnamespace adds convenience wrappers for TestFunction and TrialFunction (these get imported into the execution namespace in fluidityequation)
2. fludityequation populates the execution namespace with Fluidity specific extensions solve and state/states

The first is a modification introducing new semantics to existing UFL constructs (which could be used in any UFL input and PyDOLFIN), whereas the second is a "pure" extension of UFL with new keywords (currently) only applicable to Fluidity as the application.

The issue to discuss is compatibility to other UFL codes (i.e. FEniCS):

• Is separating these 2 kinds of extensions the right thing to do? Or should they be packaged at the same place?
• Do we want to introduce any extension that change existing UFL semantics and could break MCFC UFL -> FEniCS UFL compatibility? FEniCS UFL -> MCFC UFL compatibility remains unaffected
• Is there a need to formalise the Fludity specific extension and/or bundle them outside of MCFC in something like PyFluidity (even though at this point we are not currently targeting complete Fluidity python bindings).

[gmarkall]

I don't see the advantages of separating them, but it does sound like it makes more work. I'm welcome to being shown why it is desirable though.

I don't think we want to change the way that anything that could get run through the UFL preprocessor works, as I think it will introduce fragility and make it hard to keep up with changes in the UFL library. However, I think we are OK to change things at the level we presently are doing (e.g. we don't use FiniteElement constructors, but state instead). Another way of thinking about it could be that we don't change semantics that Dolfin doesn't change.

I have no idea about the third question :-)

[kynan]

I don't see the advantages of separating them, but it does sound like it makes more work. I'm welcome to being shown why it is desirable though.

I separated them because I think - as argued in the opening post - these are conceptually different. But I'm open to debate, that's why I posed the question.

I don't think we want to change the way that anything that could get run through the UFL preprocessor works, as I think it will introduce fragility and make it hard to keep up with changes in the UFL library. However, I think we are OK to change things at the level we presently are doing (e.g. we don't use FiniteElement constructors, but state instead). Another way of thinking about it could be that we don't change semantics that Dolfin doesn't change.

We will be changing the semantics of derivative and measure operators for naturally integrating transformations from physical to reference elements, see issue #37.

[gmarkall]

We will be changing the semantics of derivative and measure operators for naturally integrating transformations from physical to reference elements, see issue #37.

Apologies for the misunderstanding - what I meant was that we shouldn't change the semantics of UFL so that you couldn't feed the same UFL forms to dolfin.

[gmarkall]

... and I thought that "anything that goes thropugh preprocess" would mean the same thing as what I just meant, but I had forgotten about the Jacobian stuff.

[kynan]

I agree we shouldn't change UFL semantics and maintain Dolfin compatibility. However I don't understand what you mean by "everything goes through the preprocessor".

[gmarkall]

I don't understand what you mean by "everything goes through the preprocessor".

Ignore that bit, it was a load of rubbish. I was just trying to explain that I now realised that what I said earlier made no sense.