Extend CUDA StateHolder to support different meshes

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

Extend CUDA StateHolder to support different meshes #15

Open kynan opened 13 years ago

kynan commented 13 years ago

The following member functions of StateHolder need to take the field name as a parameter and return data corresponding to the given field (currently the first field is hard coded):

getCoordinates
getEleNodes
getNumEle
getNumNodes

Updating the following member functions is not necessary, since they will not be used anymore:

getBasisFunction
getDimension
getNumNodesPerEle
getNumQuadPoints
getQuadWeights
getReferenceDn

These might be used (pending implementation details):

getBasisFunctionDerivative
getDetwei

kynan commented 13 years ago

I realised this might not actually be the case. Coordinates, eleNodes, numEle, numNodes will only differ if fields were actually using different meshes, which I think we currently don't support. Does Fluidity support this case at all? I think this would mean different material phases and then we'd have different states anyway, is that correct?

kynan commented 13 years ago

Since any change to the CUDA backend <-> Fluidity state interface will have to be duplicated for OP2, we want to minimise the effort put into the CUDA state holder and implement the features in the OP2 <-> Fluidity state interface instead.

gmarkall commented 13 years ago

Is there an OP2 <-> Fluidity state interface? If so, how much does it differ from the CUDA state interface?

kynan commented 13 years ago

No, there isn't one yet, but there will have to be. It will be simpler than the CUDA state interface since (according to current plans) Fluidity will carry part of the burden, see #41.