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.
Copy host directory files from opm-simulators/python and
opm-common/python to container to avoid conflict with
opm-simulators/python/opm/ and opm-common/python/opm/ folders when
running "python -m unittest discover" from the python directories.
An alternative would be to rename the opm directories in the host.
1) A slave may run independently until it is activated by a GRUPSLAV keyword in the schedule. Before that point it determines its own timestepping strategy. After activation, its timestepping is controlled and synced by the master. 2) If the slave activates later (schedule DATE) than the master, it will have to wait until the master reaches that point of time, before it synchronizes with the master. 3) The master may run independently until it is activated by a SLAVES keyword in the schedule. Before that point it determines its own timestepping strategy. After activation, it tries to synchronize with activated slaves and adjust its time stepping to their report steps.
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.
Håkon Hægland
Arne Morten Kvarving
Atgeirr Flø Rasmussen
jakobtorben
Bård Skaflestad
Stein Krogstad
David Landa Marban
Tobias Meyer Andersen
Markus Blatt
Tor Harald Sandve
Atgeirr Flø Rasmussen
Kai Bao
Tor Harald Sandve
Erik Hide Saeternes