OPM
Add Protocol for Populating Saturation Function End Points per Cell
This PR introduces a set of callback functions, packaged in an abstract base class SatfuncCheckPointInterface<Scalar>, for querying and populating the saturation function end-points that get probed by the individual consistency checks. Member function
SatfuncCheckPointInterface::pointID(cellIdx)
translates the active cell index cellIdx into a point ID, assumed to be unique on at least the current MPI rank. This function will return nullopt if the cellIdx is not eligible for this particular end-point. This typically happens for the region based tabulated (unscaled) saturation function checks when the cellIdx happens to be in a region that's already been visited. Member function
SatfuncCheckPointInterface::populateCheckPoint(cellIdx, endPoints)
fills in (assigns) all data members of the endPoints structure with the pertinent values for the active cell cellIdx.
We implement this interface for the tabulated/unscaled end-points in derived class UnscaledSatfuncCheckPoint<Scalar> and for the scaled end-points in derived class ScaledSatfuncCheckPoint<Scalar>. The former keeps track of which saturation regions have been visited and short-circuits its pointID() member function based on that information while the latter uses an instance of the former in order initialise the endPoints structure in its populateCheckPoint() member function.
I'm creating this PR in draft mode because we're missing unit tests for these interfaces. I will keep the PR in a draft state until such time that I'm satisfied we have sufficient test coverage.
I've added a set of unit tests for these unscaled and scaled check points. I now consider this work to be feature complete and I'm marking it as "ready for review". I'll run a build check to make sure that nothing breaks.
except I do not understand why pointers are used in some places.
I'll explain later. This isn't going into the release in any case, so I'll reset it back to a draft state.
With the release branches created, I think this is ready to go into the master branch. I'm therefore marking it as "ready for review". In so doing I'll also address the topic that was raised earlier:
I do not understand why pointers are used in some places.
The primary reason is that data members of reference type make the containing class non-movable, and therefore harder to put into containers like std::vector<>. Pointers do not have this problem. The obvious alternative is std::reference_wrapper<>, but that comes with some ergonomic deficiencies like sometimes having to call reference_wrapper<>::get() to get at the underlying object. In this particular instance that would probably not apply as most uses would go to the conversion function reference_wrapper<>::operator const T&() const at function call sites, but I nevertheless decided against that. In this instance I wanted the additional visual queue that passing the address of an object, usually a data member in a containing class, into the constructor should give pause to think about lifetimes of those objects.
Thanks for the nice explanation for the pointers. I will not require any further changes, merging!
