it is possible that a dune entity vanishes if its iterator gets out of
scope. Whether this is a problem or not seems to be be highly depend
on the used configuration...
also, clean them up a bit:
- do not use the intensive quantities cache directly anymore. (i.e.,
that code should now work if the IQ cache is disabled)
- do not fiddle with the global Jacobian matrix and residual vector
directly. Instead, implement the water fluxes to the reservoir as a
source term like wells.
one thing that did not become fully clear to me is if each aquifer
ought to be assumed to be in contact with the whole reservoir or just
a few cells on the boundary. The current implementation goes down the
former path, while, without any deeper knowledge, I would rather
suppose that the latter applies. maybe my understanding of this is
just too limited, though.
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.)
i.e., mine (openSuse Tumbleweed). the problem seems to be that the
specialization of `ISTLSolver::constructAMGPrecond()` is ambiguous and
some compilers seem to be more strict about this than others. Simply
removing the problematic method seems to work fine.
That said, for non-legacy `flow` this codepath is not taken at runtime
anyway because the `ISTLSolverEbos` class is used!?
- Change the brief description slightly
- Do not print anything anymore if there are no unused parameters
- Change the boiler plate text for printing the parameters to the
PRT/DBG files
in part, this has been requested by [at]atgeirr.
bph should be "bhp" and "DWellFractionMax" looks weird as a command
line parameter (-d-well-fraction-max). now, it only looks slightly
weird in the c++ code.
this has been requested by [at]atgeirr.
Note: The FlowLinearSolverVerbosity, FlowNewtonMaxIterations and
FlowNewtonMinIterations parameters are still prefixed because they
clashes with parameters registered deeply within eWoms.
while they do no longer appear in the help message, in the code they
are still there and can be specified and used as normal.
also, this patch makes --print-parameters=1 and --print-properties=1
work.
this has several advanges:
- a consistent and complete help message is now printed by passing the
-h or --help command line parameters. most notably this allows to
generically implement tab completion of parameters for bash
- the full list of runtime parameters can now be printed before the simulator
has been run.
- all runtime parameters understood by ebos can be specified
- no hacks to marry the two parameter systems anymore
- command parameters now follow the standard unix convention, i.e.,
`--param-name=value` instead of `param_name=value`
on the negative side, some parameters have been renamed and the syntax
has changed so calls to `flow` that specify parameters must adapted.
this is necessiated by the replacement of `std::shared_ptr` by raw
pointers for the eWoms auxiliary equation infrastructure. Note that by
default `flow` will *not* create an auxiliary equation module because
it modifies the operator that is used by the linear solver instead.
this was forgotten when moving the output writing code into the ebos
core. (this does not really matter for most people because
asynchronous output is wanted anyway and it was unconditionally
enabled.)
these objects are only used by flow_legacy, so not having to deal with
them anymore lets non-legacy flow avoid to jump through a lot of hoops
for the sake of having a common API.
this required a fork of the NonlinearSolver and AdaptiveTimeStepping
classes. this is not a problem because the original classes would get
pruned to look like the new ones once flow_legacy gets moved out of
the opm-simulators module.
an empty string is interpreted as "write the output files into the
same directory as the input". this is the current 'flow' default
behavior, plain ebos uses "." as the default location for output,
i.e., the current directory from which the simulator is run from.
this class is only used by the legacy simulators, `flow` uses the
`EclWriter` class provided by eWoms. In turn, this class uses the
new-and-shiny "tasklet" mechanism.
generally, this is a bad idea because GCC is very good at determining
which optimizations should be enabled or not and also, this may
interfere with some compilers. (e.g., it produces a warning on icc)
these files take the longest to compile. moving them to the beginning
speeds things up forn parallel builds because the remaining compile
can be compiled while dealing with the flow_ebos files while the build
stalls if these files are at the bottom of the list because they are
required for the library.
it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
if PETSc is not available, the .cpp file will compile fine because it
will be reduced to be empty, but trying to include
LinearSolverPetsc.hpp in this case will result in an error.
This is quite a hack: Even though energy is not a "phase" and it is
also not considered in MaxNumPhases and pu.num_phases because this
would break a lot of assumptions in old code, it is nevertheless
assigned an "canonical index" that can be translated "active index"
via PhaseUsage::phase_pos[]. This awkwardness is needed because much
of the legacy OPM code conflates the concepts of "fluid phase" and
"conserved quantity" and fixing that issue would basically mean an
almost complete rewrite of much of the legacy code. That said, the
same statement applies to polymer and solvent, but these are currently
handled as even more second-class citizens because they are not even
given a canonical index and also cannot be translated into an active
one.
this used to provide autotools compatibility, but it has not been working for a while. Thus it is IMO better to remove it in order not to mislead people.
the ThreadManager from ebos was not called which resulted in some
havoc when attempting multi-threaded runs.
v2: use opm_get_max_threads() directly. thanks to [at]akva2 for the heads-up.
it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
The old message was not really accurate anymore because flow also
supports the polymer and solvent extensions. (Also, the parentheses
around the version were removed because they are not necessary.)
v2: use the message proposed by [at]atgeirr
v3: re-add accidentially removed website URL
this needs to merged before the SimulationParameter hack can be
removed from eWoms. the patch will cause spurious deprecation warnings
until then. (i.e., it is best to merge them together.)
The motivation for this PR is that currently the build fails on my
Ubuntu 17.10 laptop with two processes because that machine "only" has
8 GB of RAM (granted, the optimization options may have been a bit too
excessive). under the new scheme, each specialization of the simulator
is put into a separate compile unit which is part of
libopmsimulators. this has the advantages that the specialized
simulators and the main binary automatically stay consistent, the
compilation is faster (2m25s vs 4m16s on my machine) because all
compile units can be built in parallel and that compilation takes up
less RAM because there is no need to instantiate all specializations
in a single compile unit.
on the minus side, all specializations must now always be compiled,
the approach means slightly more work for the maintainers and the
flow_* startup code gets even more complicated.
in particular, this implied some changes to the MPI initialization
code. since dune-fem's GridPart class currently has issues with
CpGrid's implementation of loadBalance(), parallel computations still
do not work if dune-fem is around, but at least sequential ones now
do even if MPI is enabled.
this is needed to avoid linker errors if this class ought to be used
in multiple compile units. IMO the main problem here is the use of an
_impl.hpp file.
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.
i.e. give up after 10 instead of 15 Newton iterations. since this now
also causes the CNV convergence criterion to be ignored after 8
instead of after 13 Newton iterations, and because CNV stagnation
seems to be the cause for the vast majority of the failures, it does
not lead to worse results or more time step chopping on Norne but
causes fewer wasted iterations.
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.
the fact that faces may point into the opposite Cartesian direction
was not considered and these output fields are specified
w.r.t. logically Cartesian cell indices. (not compressed ones!)
the corresponding code was shamelessly lifted from the DerivedGeology
class. it has been substantially modified to adapt it to the flow_ebos
specifics, though.
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.
since flow_ebos is the new silverback simulator of the opm-simulators
clan, it should itself as "flow"(the old silverback announces itself
as "flow_legacy" already).
Also some people seem to have been confused by the eWoms version and
codename. Since this information only exhibits limited value IMI,
let's remove it here.
this prevents GCC-7's address sanitizer from complaining about a
delete for a new of a different type. (i.e., the new is for the
derived class, but if the destructor is non-virtual only the dtor of
the base class is called if a pointer to the base class is deleted.)
finding this was quite some fun, mainly because it took a while what
the issue was.
Andreas Lauser