`NEW_PROP_TAG` is now a definition and not just a declaration.
Eliminate superfluous declarations, include headers with definitions.
Make one necessary forward declaration explicit.
NOTE: this pull request depends on #2555 which should be merged first.
A rewrite of the outdated PR #2543.
Refactors flow_ebos_blackoil.cpp such that we can choose not to execute
the whole simulation using the flowEbosBlackoilMain() function but
instead only initialize by calling flowEbosBlackoilMainInit(). This is
necessary to implement a Python step() method that can advance the
simulator one report step at a time.
Also adds a method initFlowEbosBlackoil() to Main.hpp that can be used
directly from the Python interface's BlackOilSimulator object to gain
access to the FlowMainEbos object before it has initialized the
simulation main loop.
Refactors away flow_tag.hpp by having flow_blackoil_dunecpr.cpp,
flow_onephase.cpp, and flow_onephase_energy.cpp use the updated Main.hpp
from a previous pull request. This will eliminate the previous code
duplication in Main.hpp and flow_tag.hpp discussed in PR #2521.
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.
The previous was "file" which resulted in runtime errors
like
Program threw an exception: No linear-solver-configuration-json-file given for linear-solver-configuration=file
The flow_tag.hpp file is used for simple construction of simulators for
particular models or other compile-time choices. This updates it to
get identical behaviour as that of mainline (multi-model) Flow.
The output code has an unfriendly error mode in which we
unceremoniously crash--without writing any data--if some declared
array dimensions from RUNSPEC aren't big enough to hold all the
dynamic objects (wells, groups, connections &c).
Verify that the declared dimensions are indeed big enough for the
current simulation run before starting the simulator to ensure that we
don't waste a lot of computational effort if, for instance, the first
output is very close to the end of the simulation.
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
Also use it in flow_blackoil_dunecpr.cpp. Adds new command-line parameter,
--linear-solver-configuration-json-file, to read linear solver config from
JSON-format file at runtime.
also, add a "reading deck" output. The idea is to make `flow`'s
behaviour less surprising by preventing people from thinking that
nothing happens after starting `flow` for a large deck.
so far, the actual specializations of the simulator were compiled into
the `libopmsimulators` library and the build of the glue code
(`flow.cpp`) thus needed to be deferred until the library was fully
built. Since the compilation of the glue code requires a full property
hierarchy for handling command line parameters, this arrangement
significantly increases the build time for systems with a sufficient
number of parallel build processes. ("sufficient" here means 8 or more
threads, i.e., a quadcore system with hyperthreading is sufficient
provided that it has enough main memory.)
the new approach is not to include these objects in
`libopmsimulators`, but to directly deal with them in the `flow`
binary. this allows all of them and the glue code to be compiled in
parallel.
compilation time on my machine before this change:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
Scanning dependencies of target opmsimulators
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_gasoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_blackoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_solvent.cpp.o
[ 4%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_polymer.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_energy.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater_polymer.cpp.o
[ 6%] Linking CXX static library lib/libopmsimulators.a
[ 97%] Built target opmsimulators
Scanning dependencies of target flow
[100%] Building CXX object CMakeFiles/flow.dir/examples/flow.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m45.692s
user 8m47.195s
sys 0m11.533s
```
after:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
[ 91%] Built target opmsimulators
Scanning dependencies of target flow
[ 93%] Building CXX object CMakeFiles/flow.dir/flow/flow.cpp.o
[ 95%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_gasoil.cpp.o
[ 97%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_solvent.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_blackoil.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_energy.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m21.597s
user 8m49.476s
sys 0m10.973s
```
(this corresponds to a ~20% reduction of the time spend on waiting for
the compiler.)
