Mostly for looking at TemperatureModel performance.
No hooks in inner loops (cell or connection loops), so runtime with tracy
active should be very close to without.
Decorates inline helpers in blackoil*modules.hh, blackoilprimaryvariables.hh,
directionalmobility.hh, tpfalinearizer.hh, NewTranFluxModule.hpp,
TemperatureModel.hpp and BlackOilEnergyIntensiveQuantitiesGlobalIndex.hpp
with OPM_HOST_DEVICE, replaces a few raw `throw`s with OPM_THROW, and
switches static `FluidSystem::` accesses to instance-based
`fluidState.fluidSystem()` / `getFluidSystem()` so the same code works
when the fluid system lives on the device. Test
test_gpu_linear_two_phase_material.cu picks up the matching template
adjustments.
When a reservoir-coupling master group's guide-rate-distributed
production target exceeds the slave's reported potential, the slave
cannot deliver the requested rate and the shortfall is lost from the
parent group's total. Cap each capacity-limited group's target at
the slave's potential and redistribute the surplus to sibling master
groups via the standard FractionCalculator / localReduction
machinery, so the parent (typically FIELD) can still meet its
overall target.
The redistribution is implemented in
RescoupConstraintsCalculator::calculateMasterGroupConstraintsAndSendToSlaves
and is structured as four phases:
Pre-phase: restore master-group control modes from the Schedule
(restoreMasterGroupControlsFromSchedule_); switch master groups
of inactive slaves to individual control so they do not consume
a share of the parent's target
(excludeInactiveSlaveMasterGroupsFromDistribution_); recompute
GCW and FIELD target reduction (updateGCWAndTargetReductions_).
Phase 1: compute initial guide-rate-distributed targets per
master group via GroupConstraintCalculator.
Phase 2: cap-and-redistribute. Groups whose target exceeds the
slave-reported potential are capped, switched to individual
control, and the FIELD reduction is recomputed. Uncapped
groups are then re-evaluated and absorb the surplus. Finally
all master groups are switched to individual control with their
final allocated targets.
Phase 3: send the (target, cmode, per-rate-type limits) triples
to each activated slave.
The driver runs on every rank of the master communicator: its
helpers call collective MPI operations
(updateGroupControlledWells does comm_.sum, GroupConstraintCalculator
and updateGroupTargetReduction walk GroupStateHelper which is
collective). The slave-facing MPI sends in
sendSlaveGroupConstraintsToSlave_ are rank-0-only inside the
underlying helpers, so the Phase-3 loop is safe to enter from every
rank. A trailing GroupState::communicate_rates(comm) aggregates any
per-rank-partial reduction rates so the post-redistribution state is
consistent across master ranks.
Supporting changes:
* GroupStateHelper::updateGroupControlledWells -- conditional GCW
for master groups: GCW=1 under FLD/NONE control, GCW=0 under
individual control. Without this the calculator cannot
distinguish between capped groups (excluded from distribution)
and uncapped groups (absorbing the surplus).
* BlackoilWellModel::updateGroupControls -- guard at the top that
skips master groups, plus a new isReservoirCouplingMasterGroup
forwarding method on the RescoupProxy facade. Master-group
controls and targets must be read-only outside the constraint
calculator; the guard prevents checkGroupHigherConstraints and
updateGroupIndividualControl from modifying them during the
assemble() Newton iteration.
Known limitations, deferred to follow-up work:
* A master group with GCONPROD CONTROL_MODE set to a
rate mode (ORAT, WRAT, ...) AND RESPOND_TO_PARENT = YES has both
an own rate limit and parent control available. The current GCW
logic returns 0 in this case and excludes the group from the
FractionCalculator guide-rate sum, so Phase 1's localFraction
yields a wrong target. Typical RC setups have master groups
acting as pure routing nodes (CONTROL_MODE = FLD or NONE) and are
unaffected.
* Injection -- the cap-and-redistribute pass currently applies only
to production master groups. Per-phase injection extension
requires a slave-reported injection potential on
SlaveGroupInjectionData (currently absent) plus the parallel set
of helpers.
* Finished slaves -- the inactive-slave handling covers only the
not-yet-activated case. A slave run can finish before the master;
detecting that finish is a separate PR with its own MPI-protocol
changes.
Adds host-side allocator helpers, host/device-decorated raw-pointer
accessors and small additions to MiniVector that the rest of the GPU
intensive-quantities work depends on. Updates test_gpu_smart_pointers.cu
to cover the new behaviour.
and make sure that we always search for ParMETIS in the *prereq.cmake file
This file gets processed when running CMake for opm-simulators and
during a find_package(opm-simulators) call.
Previously this was done via config.h, but due to the recent build
system refactoring these defines became MIA and some code is never
activated even if it would be supported by the hardware.
We now set the necessary compile definitois as properties for the relevant
source files to fix this.
Arne Morten Kvarving
Bård Skaflestad
Kai Bao
Atgeirr Flø Rasmussen
Tobias Meyer Andersen
Atgeirr Flø Rasmussen
Tobias Meyer Andersen
Kjetil Olsen Lye
Tor Harald Sandve
Håkon Hægland
Markus Blatt