History mode reservoir coupling only synchronizes time steps between
master and slaves. No rate allocation occurs, so GRUPSLAV (which maps
slave groups to master groups for rate constraints) is not needed.
Changes:
- Reorder master-slave initial communication so slaves receive master
group names before determining activation date
- Handle zero master groups case in getMasterGroupNamesForSlave_(),
sendMasterGroupNamesToSlaves_(), and receiveMasterGroupNamesFromMasterProcess_()
- Add numMasterGroups_() method to ReservoirCouplingSlave to detect
history mode (no GRUPMAST on master means no master groups)
- When no GRUPSLAV found and numMasterGroups is zero, assume slave
activation at simulation start (history mode)
History mode reservoir coupling only requires time synchronization, not
rate allocation. GRUPMAST is only needed for prediction mode where the
master allocates rates to slaves.
for reason unknown, cmake sometimes choose to pad/escape test names with a
=[ ... ]= in the CTestTestFile. Due to changes lately, this has somehow
triggered. Since we rely on extrating information
from this file, update_data and failure_report triggers broke.
this makes the re's more resilient by allowing the existence of the separators
Master groups in reservoir coupling have no wells in the master
reservoir (they represent slave groups), so their GCW (Group Controlled
Wells) count was 0. This caused them to be incorrectly excluded from:
- Guide rate distribution (FractionCalculator)
- Local reduction level calculations
- Target constraint checking
Fix: Set GCW = 1 for RC master groups by convention. This is consistent
with how GCW is used throughout the code - only the condition GCW > 0
matters, not the actual count.
Update GCONSUMP.DATA and GCONSUMP_COMPLEX.DATA to be valid input for
full simulation runs while preserving their unit test functionality:
- Fix EQUIL datum depth to match gas-oil contact (7020 → 7000)
- Fix PVTO bubble point relationship (Rs/Pbub must be monotonic)
- Extend PVDG pressure range to cover reservoir pressure (→ 300 bar)
- Adjust SGOF Sg_max to avoid floating-point SOGCR precision issue
The GCONSUMP efficiency factor calculation was incorrectly applying group
efficiency factors to the groups themselves, rather than following the
the pattern used elsewhere in the code base:
- Groups are NOT affected by their own efficiency factors
- Parent groups apply child efficiency factors when accumulating contributions
Changes:
- Fix GroupState::update_gconsump() to implement correct efficiency pattern
- Add test suite with simple and complex hierarchy scenarios
Kai Bao
Bård Skaflestad
Arne Morten Kvarving
Håkon Hægland
Markus Blatt
Atgeirr Flø Rasmussen
David Landa Marban
Tor Harald Sandve
Svenn Tveit