Ct int solver

[gbalduzz]

With this PR, the CT-INT solver will finally be usable.
This PR includes:

• The solver itself.
• several statistic and no-change tests. This is the bulk of the line count.
• changes to the const-ness and minor interface changes to other solvers' walker and accumulator.
• added template parameter for the accumulator scalar type
• measurements and sweeps-per-measurement can be initialized with a vector to have a different number at each iteration. Input files with a scalar parameter are still supported.

[gbalduzz]

retest this please.

[gbalduzz]

retest this, please.

[gbalduzz]

retest this, please

[gbalduzz]

fixed weight initialization in 2d6f92c

[gbalduzz]

Test pass, only failure is the distributed G4 test.

[PDoakORNL]

Outside of the semantics of CudaStream and MagmaQueue this looks good. I will also do some testing with it on non summit systems while I wait for your responses and changes.

[PDoakORNL]

I think a MagmaQueue has a CudaStream I don't think it is a CudaStream.

[gbalduzz]

We could argue if a MagmaQueue is a CudaStream with extra resources. But according to the Liskov Substitution Principle, inheritance is appropriate: everywhere you can use a CudaStream you can also use a MagmaQueue. I set the destructor of the base class to virtual for safety reasons.

[PDoakORNL]

I think its pretty clear a CudaStream is a resource a MagmaQueue owns or has a reference to. When Magma is build on top of AMD's libraries it clearly won't have a CudaStream or be a cudastream. I don't like to see inheritance used as a way to get simplified access to class members.

[efdazedo]

AMD HIP tries to follow CUDA. I think there is still "HIP stream" that works like a cuda stream.

[gbalduzz]

you just need to change the implementation of CudaStream (and possibly rename it), this is completely orthogonal from the decision of using composition vs inheritance.
The inheritance has no access to the private members, but it exposes the interface, which I want, and has a well defined downcast that I also need. Of course it could be implemented as composition, but then I need to forward the methods, and use a getter to the stream in the rest of the code. While we don't need runtime polymorphism, I am pretty sure this is a well defined inheritance, and the added 64 bits of storage for the (unused) vtable pointer is a non issue.

[gbalduzz]

I still don't understand the crusade against inheritance to represent a simple instance of subtyping, especially given our PR backlog, but I fixed and merged @PDoakORNL PR removing inheritance.