Open kynan opened 13 years ago
Isn't this a Dolfin feature and not a UFL feature?
That is correct indeed, I hadn't realised this. However, we could treat these cases at some point and not pull the fields from Fluidity state then, but generate code for assign the constant / compute the python expression in a kernel.
I presume the motivation for this is to reduce the amount of data that needs to be transferred by a kernel? If so, is this worth doing yet, since it will only save time at the initial timestep in most cases?
I imagine that the case when it saves time on every timestep is in the implementation of boundary conditions that are prescribed?
Yes, the motivation is reducing data transfer and also benefit from evaluating complex expressions in parallel. Since Fluidity does actually need to call python to evaluate a prescribed field of type python, this is very slow. We could on the other hand generate a kernel to do the evaluation efficiently on the target hardware (resp. have OP2 do it for us).
However in terms of potential savings this will be minor as you rightly pointed out and might not be worth the effort (at least not for the moment).
MCFC should be smart and translate prescribed fields of type python into
Expression
and of type constant intoConstant
instead ofFiniteElement
See https://github.com/gmarkall/manycore_form_compiler/wiki/UFL-equations-for-Fluidity-fields for a discussion