Note in particular that some classes/functionality are duplicated in
two places after the merge, for example MFEMCeedOperator should be
combined with mfem::ceed::Operator
Notes:
- All the operator applications and smoothers appear to happen on
GPU; there is a pointwise vector scaling in the interpolation/restriction
that happens on CPU, and there are a bunch of memory copies, overall not
very fast.
- The coarsest solver is a *single* sweep of Jacobi. This is terrible
but it does run on GPU and some improvements are relatively easy
(though note the right answer here is an *assembled* GPU AMG, which
is not easy).
- In general the border between "Ceed" and "MFEM" is pretty
debatable.
Modify the Device class to require the creation of an object in
order to use backends other then Backend::CPU. At destriction,
this object will call the Destroy() method of the MemoryManager to
deallocate any remaining registered device pointers.
In class Device, remove the method Disable() and make the method
Enable() private.
Use a global Array<double> as the buffer used by the cuda functions
for minimum and dot product.
and transfers.
The Memory class is now used by some MFEM classes (like Array and
Vector) which can be used on the Device. Such classes now provide
methods to access the underlying Memory object, e.g. GetMemory.
Updated ex1/ex1p and ex6/ex6p to not need to enable/disable the
Device at specific points -- the Device is now enabled just at the
start. Also, the same examples can now run on Device (e.g. -d cuda)
without the partial assembly option (-pa) -- full assembly will
be still done on CPU but the sparse matrix action and vector
operations will be done using the Device.
Reverted changes in class DenseMatrix related to using the Device.
At this point, DenseMatrix operations are only used for small matrices
and using the Device in this case is not a good option.
Tzanio