Extend the Python blackoil simulator to support two-phase gas-water
simulations by extracting common functionality into a template base
class and implementing proper module separation.
- Extract PyBaseSimulator<TypeTag> template base class containing all
common simulator functionality (20+ methods including advance, run,
step, property access, and MPI handling)
- Add PyGasWaterSimulator for two-phase gas-water simulations using
FlowGasWaterProblem TypeTag with oil phase disabled
- Split Python modules to avoid ODR violations:
- BlackOil.so for PyBlackOilSimulator (FlowProblemTPFA)
- GasWater.so for PyGasWaterSimulator (FlowGasWaterProblem)
- Implement proper template instantiation control with explicit
instantiations per module
- Eliminate ~400 lines of code duplication between simulators
- Clean inheritance hierarchy: derived classes contain only constructors
- Type-safe specialization through OPM's TypeTag property system
- Separate docstring generation for each simulator type
- Independent build targets with shared infrastructure
- Update CMakeLists.txt to support multiple pybind11 modules
- Add docstrings_gw_simulators.json for gas-water simulator documentation
- Remove centralized Pybind11Exporter.cpp in favor of distributed exports
- Implement proper build dependencies and custom targets
This establishes a scalable foundation for extending OPM's Python
bindings to support additional simulator types (thermal, polymer,
solvent) while maintaining type safety and avoiding symbol conflicts.
Files changed: 21 files, 915 insertions, 428 deletions
Commit 6295bd08c (PR #6238) restricted RFT data reporting to only
those wells that are owned by the current rank. In so doing,
however, we failed to properly account for distributed wells. Such
wells will typically have RFT contributions from multiple MPI ranks
in a parallel run and we did not allow for this situation.
Moreover, as the simulator by default will distribute "inactive"
wells--wells that are never opened, but which exist primarily to
collect RFT-style data--the problem becomes more pronounced for
these wells.
We solve the problem by splitting the RFTContainer's "wellQuery_"
into two responsibilities. One for determining if a particular
named well is owned by the current rank and another for determining
if the well is intersected on the current rank. The latter will be
true for all ranks that have local well connections for the named
well. This, in turn, means that the constructor now takes two
predicate functions instead of the one we originally used.
Furthermore, member function RFTContainer::allocate() will create
internal data structures for all potential connections on all ranks
that share a well, but RFTContainer::addToWells() will still collect
the RFT data only on the rank that owns the well.
Finally, we implement the owning vs. intersecting distinction for
the black-oil output module through a new member function
bool BlackoilWellModelGeneric<>::hasLocalCells(name) const
while the compositional output module retains the original
owning-is-intersecting behaviour. We do not support distributed
wells in compositional runs at the time of writing.
replacing it with a new PhaseUsageInfo and FluidSystem, both of which
are using the same implementation of PhaseUsageInfo, and only one set of
indices is used. Currently, it is the BlackOilDefaultFluidSystemIndices.