Tested with SPE1.
TODO: with the current way, we are not outputting any well residual
information. We need to address what kind of residual information we
want to output with the new well model.
to update well state.
With this way, the BlackoilModelEbos does not need to know the data type
assocated with different well type.
It is not well tested yet.
1) Use the solution variable directly in RelativeChange(...)
2) Add a method in the RateConverter that takes the simulator instead of the state.
3) Pass the reservoir pressure directly to the well initialization.
4) Move convertInput(...) to SimulatorFullyImplicitBlackoilEbos.hpp.
This code is only used to convert the initial reservoir state.
5) Modify updateState(...). The solution variable is updated directly and adaptPrimaryVariable(...)
from ewoms is used to switch primary variables. An epsilon is passed to adaptPrimaryVarible(...) after a switch
of primary variables to make it harder to immediately switch back.
The following code used by flow_ebos still uses the reservoirState
1) the initialization
2) restart
3) output of the initial state
4) the step methods in AdaptiveTimeStepping and NonlinearSolver.
The reservoirState is not used by this methods, so after the initial step, an empty reservoirState is passed around in the code.
We do this by switching to output the global index of the cells.
In a first step the problematic cell indices are gather on process 0.
Then they are logged there.
This should prevent spurious ouput at the end of PRT and DEBUG files after the
simulation time is printed. This happened previously for some parallel
runs of model 2. Unfortunately, it seems these problems do not appear any
more for the current master. At least I could not reproduce them.
No extra equation is added for polymer in the well equation.
Seperate executables are added for polymer: flow_ebos_polymer
and solvent: flow_ebos_solvent
Tested and verified on the test cases in polymer_test_suite
This PR should not effect the performance and results of the blackoil
simulator
the only thing that was used of this class was the phase usage object,
but the phase usage object can be accessed via much leaner interfaces.
The old BlackoilPropsFromDeck (without "Ad") is still required to
compute the initial condition, but the init code should be refactored
soon anyway.
that parameter is called "max_strict_iter". This increases the
flexibility of this slightly and it avoids screwing up the default
value for the "max_iter" parameter in the future. The credits for this
patch go to [at]atgeirr for proposing it.
- add dss to appleyard chopping
- support for bhp injectors with solvent
- copy perfSolventRates between the time steps.
- fix bug in well access indicies when numComponents ~= numPhases
1) Extends the well model to account for solvent surface volumes
2) Add solvent to updateState
3) Add solvent to well and field output
The solvent parts is encapsled in if (has_solvent_) and should not effect
the standard runs.
For flow_legacy the first component a block is used, which is the
oil pressure. As flow_ebos uses different indices this commit
explicitly uses BlackoilIndices::pressureSwitchIdx to tell the AMG
at which index the pressure is stored.
now, the dune APIs are used whereever possible and the data is
computed for the global grid, i.e. for parallel runs it does not need
to be gathered across the processes anymore. Also, the INIT file is
now only written once instead of twice.
I've verified that the sequential and the parallel INIT files stay
identical for the Norne case and that the INIT file does not change
w.r.t. before this patch.
it was already almost unused (except for output). Besides making the
overall flow_ebos code leaner because it reduces redundancies, this
patch also implies a small reduduction of memory consumption and a
minor performance improvement. the latter is due to the fact that the
transmissibilities now do not need to be calculated more often than
necessary anymore.
This is now possible as the values stored for ghost/overlap elements
(minimum where we compute the maxiumum, zero where we sum up)
will not influence the result of the computation any more.
