at the early stage of computeWellRatesWithBhpIterations. The perforation rates are not updated,
and it is not sensible to update based on the inconsistent well rates and perforation rates.
Better to keep the original explicit quantities for better consistency.
Furthermore, it can be dangerous to update the explicit quantities based on the
irrelevant perforation rates, since the ratios can be very undesirable due to crossflow.
Using bool here is at least frowned upon. To be honest, I have no idea
what happens underneath here if we pass a bool. In contrast to other
pod types we do not associate it with a builtin type of MPI (not even
sure what to use). Hence we probably create a custom type for sending
and receiving. That should work. But I have no idea what will be used
for summation.
BTW: I am debugging a case that previously crashed and now suddenly
works and this seems to be the only relevant change I made in the
meantime.
The well dfactor is scaled by the well index
If postive the connection dfactor is threated as a well factor
and also scaled. If negative the connection dfactor is not scaled
This should replace OPM_DEFLOG_THROW in places where the problem
category is more appropriate than the error category.
In this commit, uses of OPM_DEFLOG_THROW have been replaced whenever
the exception class used was NumericalProblem.
This commit adds a new flag data member,
wellStructureChangedDynamically_
to the generic black-oil well model. This flag captures the
well_structure_changed
value from the 'SimulatorUpdate' structure in the updateEclWells()
member function. Then, in BlackoilWellModel::beginTimeStep(), we
key a well structure update off this flag when set. This, in turn,
enables creating or opening wells as a result of an ACTIONX block
updating the structure in the middle of a report step.
to get more outputting information and also avoid harsh termination due
to assert.
They are technically numerical problem instead of programming mistakes.
checking LIFTOPT active before gliftBeginTimeStepWellTestUpdateALQ and before attempting to optimize alq in gliftBeginTimeStepWellTestIterateWellEquations
in gliftBeginTimeStepWellTestIterateWellEquations.
otherwise, if the increment is 0 (inactive), the function
gliftBeginTimeStepWellTestIterateWellEquations
might return undesired results or enter endless loop.
we set the thp to be zero in the WellState. The previous logic related
this to THP constraints does not hold in multiple situations:
1. VFP table is specified, we need the THP value for output purpose
2. network is involved, we need the THP value for constraint check.
We did only break in the loop for rank 0 and not the other ones. Hence
all other processes kept iterating beyond the maximum number of
allowed iterations. This lead to hard to find crashes because of
non-matching MPI communication.
when local_well_solver_control_switching_ is off
and incoporating commenst regarding resetting wellStatus_ in StandardWell within
the function iterateWellEqWithSwitching.
when we do the local solve for well equations, control/status will be
updated during the iteration process, such that the converged well gets
correct control/status regarding to the current reservoir state.
various change in the other parts of the code were made to make the
function work as intended.
Previously, we did a global summation of the size of the
well_perf_data vector to determine the number of perforations
of a well. In the case of distributed wells this will try to access
more perforations than stored for the well in well_perf_data and hence
might use data from cells that actually are not perforated by this
cell. Note that for well not distributed the code worked as the
summation has no effect.
This commit changes this to only query peforations on the
local process. This should be enough to fix this problem.
In addition it removes the computation of connpos which is never used.
it was introduced back then for some purpose. The purpose might not
apply anymore due to other development. And also, some issues were
reported for some situtation with the approach.
In preparation of adding support for opening/creating wells or
groups in the middle of a report step. This is needed if an
ACTIONX block runs something like WELOPEN or WELSPECS/COMPDAT.
This commit activates the support for calculating WBPn summary
result values per well in parallel. To affect the calculation we
add two new data members in BlackoilWellModelGeneric:
- conn_idx_map_:
Maps well's connection index (0..getConnections().size() - 1) to
connections on current rank. Its local() connections are
negative 1 (-1) if the connection is not on current rank, and a
non-negative value otherwise. The global() function maps well
connections on current rank to global connection ID for each
well. Effectively the reverse of local(). Finally, the open()
function maps well connections on current rank to open/flowing
connections on current rank. Negative 1 if connection is not
flowing.
- wbpCalculationService:
Parallel collection of WBPn calculation objects that knows how
to exchange source and result information between all ranks in a
communicator. Also handles distributed wells.
We furthermore need a way to compute connection-level fluid mixture
density values. For the standard well class we add a way to access
the StandardWellConnection's 'perf_densities_' values. However,
since these are defined for open/flowing connections only, this
means we're not able to fully meet the requirements of the
WELL/ALL
WPAVE depth correction procedure for standard wells. The
multi-segmented well type, on the other hand, uses the fluid mixture
density in the associated well segment and is therefore well defined
for ALL connections. OPEN well connections are supported for both
well types.
This commit adds a parallel calculation object derived from the serial
PAvgCalculator class. This parallel version is aware of MPI
communicators and knows how to aggregate contributions from wells that
might be distributed across ranks.
We also add a wrapper class, ParallelWBPCalculation, which knows how to
exchange information from PAvgCalculatorCollection objects on different
ranks and, especially, how to properly prune inactive cells/connections.
for filter cake calculation. The main reason is that the injection
concentration may vary during the simulation, which makes the tracking
of water injection volume is not very helpful when used for filter cake
calculation.
This commit adds logic and backing storage in the SegmentState to
provide the segment level summary vectors
- SDENx -- Phase density of phase 'x' (O, G, W)
- SDENM -- Mixture density without flowing fraction exponents
- SMDEN -- Mixture density with flowing fraction exponents
We defer the calculation of SDENM and, especially, SMDEN, to the
MultisegmentWellSegments class since this class maintains the
current flowing fractions.
