@JDBetteridge and I took a harder look at your code yesterday and came up with an idea that we think could reduce a large amount of boilerplate.
The key idea is the introduction of what I have called a MirroredArray. It is effectively a host/device 'aware' version of a numpy array. It would have a few responsibilities:
Ensure that the data on the host/device is up-to-date when needed
Do the correct transformation to a PETSc Vec depending on the backend
Return an appropriate pointer for passing to the kernel (_kernel_args_), depending on whether or not offloading is enabled
I think this would be good for removing lots of boilerplate because it would (I think) remove the need for us to have separate implementations of Dat, ExtrudedSet, Global, etc per backend. All that would need to be done instead is to replace any numpy arrays that we want to exist on both host and device with MirroredArrays.
What I've provided here is quite a rough sketch of what I think such a solution would look like. The key thing I have not yet tackled is how we might transform these arrays into PETSc Vecs with context managers and such.
Please let me know your thoughts. @JDBetteridge and I would be very happy to have a call with you at some point to discuss it further.
@kaushikcfd
@JDBetteridge and I took a harder look at your code yesterday and came up with an idea that we think could reduce a large amount of boilerplate.
The key idea is the introduction of what I have called a
MirroredArray
. It is effectively a host/device 'aware' version of a numpy array. It would have a few responsibilities:_kernel_args_
), depending on whether or notoffloading
is enabledI think this would be good for removing lots of boilerplate because it would (I think) remove the need for us to have separate implementations of
Dat
,ExtrudedSet
,Global
, etc per backend. All that would need to be done instead is to replace any numpy arrays that we want to exist on both host and device withMirroredArrays
.What I've provided here is quite a rough sketch of what I think such a solution would look like. The key thing I have not yet tackled is how we might transform these arrays into PETSc Vecs with context managers and such.
Please let me know your thoughts. @JDBetteridge and I would be very happy to have a call with you at some point to discuss it further.