This allows (re)moving of the following files
opm/autodiff/RateConverter.hpp
opm/autodiff/Compat.cpp
opm/autodiff/Compat.hpp
opm/core/props/BlackoilPropertiesInterface.hpp
opm/core/simulator/BlackoilState.cpp
opm/core/simulator/BlackoilState.hpp
opm/core/simulator/BlackoilStateToFluidState.hpp
opm/core/utility/initHydroCarbonState.hpp
opm/polymer/PolymerBlackoilState.cpp
opm/polymer/PolymerBlackoilState.hpp
tests/test_blackoilstate.cpp
A WellSwitchingLogger was created in a local context (meaning not
all processes might be there), but since its destructor does
communication it must be called in a global context (guaranteeing
that all processes create it).
Since computeAverageFormationFactor() involves communication to reduce
values across the whole reservoir, it must be called by all processes,
also those with no wells to reopen.
the key difficulty is that we do not have reliable explicit information
to do the testing.
In this version, we try to obtain the explicit information by finishing
one converged solving.
if a well is banned from cross-flow. When it is under RATE control, its
BHP might be initialized in way causing all the drawdown in the wrong
direction. It will cause singular well equations.
here, we open the croff-flow to fix the singularity and rely on Newton
iteraton to get desired result.
possible alternative approach is to adust the BHP to avoid the situation
that all the drawdown are in the wrong direction.
it turns on the crossflow when all the drawdown in the wrong direction,
then the well get rates in the wrong direction.
flow is not ready to handle this type of situation, then the only result
will be chopped time step.
Looping over all components instead of phases, to handle polymer etc.
correctly. Also slight refactoring of how component names for output
are handled.
Note: the communication and reduction for computing reservoir
convergence is not done by gathering ConvergenceReports, but
as before, using the convergenceReduction() method.
otherwise, it might not be initialized if the well does not exisit in
previous well state, which will result in undefined behavoir.
it causes failure in running some realizations.
and give warning messages when they happen, since they can be the
culprits of the termination of simulation later.
For ADB related, I did not find a good way to do the detection, so there
is no warning message given.
Even the well does not have a THP target/constraint, but if it is
specified with a valid VFP table, we are supposed to update the thp
value for output purposes.
No templates involved, no reason to keep it in header. This also makes
building more robust by only invoking HAVE_MPI in the cpp file, after
including config.h.
When there is some events happen to a well, we use the control mode
from the DECK, and update the WellState based on the new control model.
Otherwise, we can use the control mode from the previous well state,
and keep the values from the previous well state as an intial guess.
* fixed the issue of including ghost cells in preconditioning, by zeroing out ghost rows and setting the diagonal to a large value.
* move altering of matrix to a function
* blockwise modification of matrix
* add findOverlapRowsAndColumns in BlacoilDetail. Add call to findOverlapRowsAndColumns in constructor of BlacoilModelEbos. Change makeOverlapRowsInvalid, by looping over precalculated inddies instead of grid
* Better formatting
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.
This is to preserve current behaviour. Infinity is used in the test
currently, rather than the provided parameter (that is only used for
mass balance/flux equations).
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.)
