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.
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
If output=false is requested we created an empty file.
Now that file will only be created if output was requested
and it will only be opened on one rank in a parallel run.
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.
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.
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.
the performance summary at the end of a Norne run which are printed by
`flow_ebos` now looks like this on my machine:
```
Total time (seconds): 773.757
Solver time (seconds): 753.349
Assembly time (seconds): 377.218 (Failed: 23.537; 6.23965%)
Linear solve time (seconds): 352.022 (Failed: 23.2757; 6.61201%)
Update time (seconds): 16.3658 (Failed: 1.13149; 6.91375%)
Output write time (seconds): 22.5991
Overall Well Iterations: 870 (Failed: 35; 4.02299%)
Overall Linearizations: 2098 (Failed: 136; 6.48236%)
Overall Newton Iterations: 1756 (Failed: 136; 7.74487%)
Overall Linear Iterations: 26572 (Failed: 1786; 6.72136%)
```
for the flow_legacy family, nothing changes.
First, the stepReport variable was not used with adaptive timestepping.
Second, even when properly updating stepReport, solver_time is still 0.
It just happens that lots of other timing variables are updated, but not
solver_time (nor total_time, pressure_time and transport_time). Simplest
way to handle is to just report the solver_timer seconds (which are still added
to the "full sim report"'s solver_time).
Previously, we kind of hard coded the problem using the TypeTag system.
Instead of this we now simply pass the only additional thing needed, the
ElementContext, as an additional template parameter.
Removes the include of removed header BlackoilModelEbosTypeTags.hpp.
this unifies the code paths of the code that calculates the FIP field
totals for the parallel and the sequential cases and makes the code
more robust because it does not hard-code the presence of an intensive
quantities cache anymore. also, rock compressibility is now also
included in the field totals instead of just the FIP regions. this was
forgotten in the last FIP PR because the region values are calculated
in a different class using completely different code. (i.e., regions
are done by the model, field totals by the simulator. that design
should win an award, IMO.)
with this patch, the field totals for Norne and SPE1 seem to match
those produced by E100 _very_ closely and also parallel and sequential
runs for Norne and SPE1 of flow_ebos produce exactly the same
numbers. (This is probably the case for all decks, but I haven't
tested anything else.)
for Norne the numbers are now very close to those of the ECL
reference. ("very close" means < 0.01 % deviation of pressure and
initial fluid volume for the field totals.)
All simulators now use SimulationDataContainer to store intermediate data that
is passed to the output Solution container. This is in cases not the most
efficient way, but it's unified to avoid errors from code duplication.
this information is already part of the EclipseState. The reason why
this should IMO be avoided is that this enforces an implementation
detail (ordering of the permeability matrices) of the simulator on the
well model. If this needs to be done for performance reasons, IMO it
would be smarter to pass an array of matrices instead of passing a raw
array of doubles. I doubt that this is necessary, though: completing
the full Norne deck takes about 0.25 seconds longer on my machine,
that's substantially less than 0.1% of the total runtime.
The initial solution in ebos and in flowebos are different in cases where
swatinit is present. Pass the initial solution and recalculate the
intensive quantities make sure that the flowEbos initial solution is
used.
this is has become necessary by the recent SWATINIT changes and is
needed to calculate the fluid-in-place consistently as well as for
ebos to use the correct initial solution for the initial
linearization.
