This component is not strictly part of MCFC, but rather Fluidity. It is however an essential prerequisite for the MCFC OP2 backend.
To interface Fluidity to OP2, Fluidity needs to be OP2-aware, which doesn't break our abstractions since Fluidity sits "on top" of OP2.
Fluidity fields carry a pointer to an op_dat, which is intialised with a raw pointer to the Fluidity field data as the host pointer and device memory (de)allocation will be handled by OP2
The op_dat is initialised when the Fluidity field is created and destroyed when the Fluidity field is destroyed
For this purpose, the Fluidity field type is subclassed and other Fluidity components wouldn't need to know about OP2. A change to Fluidity state should not be necessary.
Since device memory is managed by OP2, the OP2 <-> Fluidity state interface should be simpler than the legacy CUDA state interface.
It should be pointed out that Fields aren't actually implemented as classes as we don't trust F2003 compilers to get it right so we do actually have to change the types. But conceptually it's just subclassing.
This component is not strictly part of MCFC, but rather Fluidity. It is however an essential prerequisite for the MCFC OP2 backend.
To interface Fluidity to OP2, Fluidity needs to be OP2-aware, which doesn't break our abstractions since Fluidity sits "on top" of OP2.
op_dat
, which is intialised with a raw pointer to the Fluidity field data as the host pointer and device memory (de)allocation will be handled by OP2op_dat
is initialised when the Fluidity field is created and destroyed when the Fluidity field is destroyedSince device memory is managed by OP2, the OP2 <-> Fluidity state interface should be simpler than the legacy CUDA state interface.