Open kynan opened 13 years ago
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 :-)
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.
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.
... 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.
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".
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.
MCFC extends UFL in two respects:
uflnamespace
adds convenience wrappers forTestFunction
andTrialFunction
(these get imported into the execution namespace influidityequation
)fludityequation
populates the execution namespace with Fluidity specific extensionssolve
andstate
/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):