Instead of the WellsManager guessing which wells are handled by other
processes we now use tha ouput of the load balancer to compute wells
that are handled by other processes.
With the previous approach it was not possible to calculate this information
correctly. Wells with only one completion next to the border of the
processes' partition were represented on multiple processes. In additition
wells that the eclipse schedule section defined with completions on non-active
cells in sequential runs were not at all calculated in parallel runs.
With the new approach the CpGrid::loaBalance routine returns the set names of
wells that are not handled by this process when setting up the simulation. This
information is then used throughout the simulation.
while the printed number of "Non linear iterations" was correct in a
strict sense, it was very confusing if one was working on the
linearization code because the last Newton iteration of each time step
was linearized but not solved for (and the solution was thus not
updated hence it does not count as a "non linear iteration"). This
makes sense for large problems were the total runtime is completely
dominated by the performance of the linear solver, but smaller
problems exhibit the opposite behavior (i.e., for them, runtime is
typically dominated by the linearization proceedure), so one is more
interested in the number of linearizations, not the number of linear
solves.
models may need a more detailed picture of where they are in the
simulation. Note that since the timer objects are available at every
call site, this is also not a very deep change.
As for each well only one process is responsible, the output process
does not see all wells. Ergo some well switching information was never
printed in a parallel run.
Therefore with this commit the well switching
message is printed regardless on which process it appears.
Changes to BlackoilOutputWriter as mandated by the split and rewrite of
opm-output. Notable changes:
* BlackoilOutputWriter is no longer a child class of OutputWriter.
* Minor interface changes; writeTimeStep requires a Wells pointer
* restore requires a Wells* pointer
* VTK/Matlab support rewrites; no longer inherits OutputWriter
* WellStateFullyImplicitBlackoil::report added, to write its data to a
opm-output understood format
Relies on utility/Compat.hpp for quick conversion to the opm-output
defined formats.
updateWellControls()
updateWellState()
addWellControlEq()
The change of function computeWellConnectionPressures() is not done
completely. Should find a solution later.
the hydrocarbonstate is stored in the reservoir state and
used instead of the primalvariable_
The initial hydrocarbonstate is computed using
initHydroCarbonState(...);
the results look okay, while the running for flow_solvent needs further
investigation even the results with flow_solvent actually look okay.
With two different version of
computePropertiesForWellConnectionPressures, flow_solvent produces the
same results. This is something needs further investigation.
The current implementation requires a copy of
computeWellConnectionPressure in StandardWells and StandardWellsSolvent.
That means probably we need to introduce the asImpl() for the Wells.
- The PolymerState class will derive from SimulatorState, instead of
containing a TwoPhaseState instance.
- The Polymer calculation methods take PolymerState& input argument
instead of TwoPhaseState&
opm-parser#677 changes the return types for the Deck family of classes.
This patch fixes all broken code from that patch set.
https://github.com/OPM/opm-parser/pull/677
Density and viscosity are given as input instead of calculated inside
computeMassFlux. This allow for modifying the properties prior to
calling computeMassFlux which avoids code duplication in the solvent
implementation.
Several files stopped compiling due to relying on opm-parser headers doing
includes. From opm-parser PR-656 https://github.com/OPM/opm-parser/pull/656
this assumption is no longer valid.