Value-View Interface

[mdavis36]

Summary

• This PR introduces the foundational features necessary for refactoring our current classes & objects in a way that is not too obstructive to the codebase.
  • A working ManagedVector (MV) implementation.
    • MV unit testing.
    • This currently lives within the Spheral headers. It will need to be refactored in the future and moved into CHAI with a better implementation.
  • The Value-View Interface Pattern (VVI) that is based around the experimental chai::ManagedSharedPtr.
    • Documentation on VVI in Spheral RTD. Preview here.
    • Example class patterns for:
      • Basic class w/ MV member.
      • CRTP pattern.
      • Abstract interface iheritance w/ MV member.
    • Implementation of VVI for Spheral::QuadraticInterpolator.
  • ctest c++ unit testing for ensuring semantic behavior of classes is working as expected with VVI.
    • Unit testing for Spheral::QuadraticInterpolator w/ and w/o VVI.
    • The start of unit tests for Spheral::Field. Incomplete
  • Gitlab CI:
    • make test at the end of the build stage.
    • SPHERAL_ENABLE_VVI=On for +cuda builds.

---

ToDo :

• Annotate RELEASE_NOTES.md with notable changes.
• Create LLNLSpheral PR pointing at this branch. (PR#105)
• LLNLSpheral PR has passed all tests.

[mdavis36]

@jmikeowen These are the changes I needed to revert. NVCC isn't happy with the local variable kernel in the lambda captures when compiling for the device.

[jmikeowen]

Ah I see, so you have to go back to externally defined functors. This is harmless enough, but kind of a bummer since I like the compact (and I think clearer) lambda function version. Do we think this is something that newer versions of nvcc can/will correct? Seems like they're not supporting standard C++ things here.

Also, since RAJA relies on lamda functions for it's trickery as well, what's teh salient difference here? Is it the reference capturing [&] version?

[mdavis36]

RAJA requires capturing by value [=] so a copy of the object must be taken into a host-device lambda.

In this specific case the lambda is used for construction of the Interpreter. When VVI + Cuda are enabled the underlying ManagedSharedPtr tries to invoke the constructor on both the host and device. Meaning kernel isn't available to the lambda invoked on the device, we need a copy of it to be passed over to the device in order to be able to call it correctly.

There are a couple of ways of getting back to an interface where we provide a lambda:

1. Construct interpreters from factory functions that are able to construct w/ appropriate size on Host + Device, then fill the interpreter on the host and copy the contents to the device.
2. Have the interprter take a handle to the kernel object then define the lambda as [=](const double, const kernel) { return kernel ... } so the interpreter can pass the kernel internally in it's constructor.