1) The wellsolution is stored in wellVariables as a vector of DenseAD
objects. The wellVariables is computed from the wellstate in
setWellVariables()
2) BHP and well fluxes are not stored directly but calculated based on
the wellVariables
3) The initial well accumulation term is stored as a vector of doubles.
4) addWellFluxEq() uses DenseAd flux and accumulation terms
5) computePropertiesForWellConnectionPressures() no longer uses state as
input. The wellstate is used to get the bhp pressure.
6) The current wellcontrol is set when updated in updateWellControls()
in order to use well_controls_get_current_type(wc) insted of
well_controls_iget_type(wc, currentIdx)
Tested on SPE1, SPE9 and Norne.
Effects the convergence but the results are identical.
Start using the well model desribed in SPE 12259 "Enhancements to the
Strongly Coupled, Fully Implicit Well Model: Wellbore CrossFlow Modeling
and Collective Well Control"
The new well model uses three well primary variables: (the old one had
4)
1) bhp for rate controlled wells or total_rate for bhp controlled wells
2) flowing fraction of water Fw = g_w * Q_w / (g_w * Q_w + q_o * Q_o +
q_g + Q_g)
3) flowing fraction of gas Fg = g_g * Q_g / (g_w * Q_w + q_o * Q_o +
q_g + Q_g)
where g_g = 0.01 and q_w = q_o = 1;
Note 1:
This is the starting point of implementing a well model using denseAD
The plan is to gradually remove Eigen from the well model and instead
use the fluidState object provided by the Ebos simulator
Note 2:
This is still work in progress and substantial cleaning and testing is
still needed.
Note 3: Runs SPE1, SPE9 and norne until 950 days.
there was a screw-up with the output directory (to set it you need to
modify the EclipseState by means of the IOConfig object? WTF?) and it
seems like the FlowMain.hpp was modified since FlowMainEbos.hpp was
added so there was some terminal output missing.
for the gas-only case with vaporized oil enabled, the oil pressure was
used, but ebos uses the gas pressure as a primary variable in that
case. (the reason is that it is faster to check if oil appears if the
gas pressure is available in that case.) This patch corrects that and
does no longer use the PrimaryVariables::set$FOO_PV() methods because
these methods are hard to keep in sync with the indices for the
primary-variables-as-a-Dune::FieldVector feature (which is actually
quite important for the linear solver).
it uses ebos for linearization of the mass balance equations and the
current flow code from opm-simulators for all the rest. currently, the
results match the ones from plain `flow` for SPE1, SPE9 and Norne, but
performance is not optimal: on SPE9, converting from and to the legacy
data structures takes about a third of the time to do the actual mass
balance assembly. nevertheless `flow_ebos` is almost as fast as plain
`flow` for SPE9. (for Norne `flow_ebos` is about 15% slower, even
though the results match quite closely. the reason for this is that it
requires more iterations for some reason.)
i.e., the contents of the Opm::details namespace, the IterationReport
and the DefaultBlackoilSolutionState classes. the purpose of this is
to share the code between the existing flow variants and flow_ebos.
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.
