For the Python interface's usage (as opposed to the usage by e.g.
flow.cpp), we do not neccessarily want to run the whole simulation by
calling run(), it is also useful to just run one report step at a time.
According to these different usage scenarios, main_() is refactored into
initialize_() and dispatch_() as a preparatory step for implementing the
Python interface (to be presented in a later PR).
Fixup usage of Deck, EclipseState, Schedule, and SummaryConfig to take
into account the class variables deck_, eclipseState_, schedule_, and
summaryConfig_. These variables might initially be empty (nullptr) when
the object is constructed by calling Main(argc, argv) from flow.cpp,
flow_blackoil_dunecpr.cpp, flow_onephase.cpp, or
flow_onephase_energy.cpp. However, when Opm::Main is constructed from the
Python interface code (to be implemented in a later PR) by using the
constructor Main(argc, argv, deck, eclispeState, schedule, summaryConfig)
the variables will not be intially empty.
Adapting Main.hpp to be called from Python interface, Part 1.
Building on PR #2521 and PR #2535, we gradually adapt Main.hpp for
being called from the Python interface (to be committed in a later PR)
to the flow executable. This PR introduces a new constructor for class
Opm::Main that takes a Deck, EclipseState, Schedule, and SummaryConfig
as arguments. It also introduces some new class variables that will be
useful when the main_() method is split up (in a later commit).
Some of the functions in Main.hpp do not need to be guarded by a
\#ifndef OPM_FLOW_MAIN
Since they are template functions, they will not be included in the
code unless explicitly instantiated.
Addresses the comments in PR #2521 regarding code duplication in
Main.hpp and flow_tag.hpp. This PR merges the code in flow_tag.hpp
into Main.hpp such that flow_tag.hpp can be eliminated (will be done
in the next PR).
According to private discussion with @joakim-hove PR #2516 is splitted into
smaller parts to facilitate review and a quicker merge into master.
As mentioned in PR #2516, main() in flow.cpp is refactored to address
the comments on PR #2127 and as preparation for implementing the Python
bindings described in PR #2403.
- Communicate all well rates.
- When changing controls, modify rates to satisfy failed constraint.
- Ensure targets are positive.
- Always solve for potentials for MSW (temporary fix).
If no LinearSolverConfiguration is specified but UseCpr is true we
use cpr_quasiimpess. If the user does not specify the maximum
iteration number we use 20 for cpr.
to prevent throwing. The get methods will throw if called without a
default value. This quite unfortunate and not very user friendly, as
there are many properties and the throwing will happen during the
linear solve and result in time step chopping.
This commit should prevent such throws and allow users to provide
jsdon files omitting some options.
These were a bit hidden, but found. They add a few more customization
options and kamg as a sequential solver. The latter will be broken if
we use update, though.
Previously, it got passed the weights only needed for CPR.
Additionally those were passed with the parameter tree to the
update method and constructor.
Now the CPR constructor gets a function to use for recalculating
the weights and the property is not changed. Unfortunately this
means that the preconditioner creators of the factory get another
parameter.
It gives overhead in constructor when linear system is created. No overhead if reuse is used.
This commit 141903a26 cherry-picked, cleaned and made compilable with
recent changes
