gmarkall / manycore_form_compiler

MCFC is deprecated. See https://code.launchpad.net/~grm08/ffc/pyop2
https://code.launchpad.net/~grm08/ffc/pyop2
GNU General Public License v3.0
3 stars 1 forks source link

Translate prescribed fields in Fluidity options file to UFL Expression / Constant #9

Open kynan opened 13 years ago

kynan commented 13 years ago

MCFC should be smart and translate prescribed fields of type python into Expression and of type constant into Constant instead of FiniteElement

See https://github.com/gmarkall/manycore_form_compiler/wiki/UFL-equations-for-Fluidity-fields for a discussion

gmarkall commented 13 years ago

Isn't this a Dolfin feature and not a UFL feature?

kynan commented 13 years ago

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.

gmarkall commented 13 years ago

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?

kynan commented 13 years ago

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).