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.
this basically means using Opm::EclipseState instead of the raw deck
for these keywords.
with this, property modifiers like ADD, MULT, COPY and friends are
supported for at least the PERM* keywords. If additional keywords are
required these can be added relatively easily as well.
no ctest regressions have been observed with this patch on my machine.
this restores the ability to build opm-autodiff and all dependencies
using `dunecontrol`. Except for opm-common adding these dependencies
is not really required because they were inherited from other modules,
but stating them explicitly is good style IMO.
the typo was caused the surface density of the oil phase to be used
instead of the one of gas. This caused the density to be off by a
factor of typically about 900.
using saturated FVFs does not change much, but it does not hurt
because it is also done that way in the simulator.
This makes the defaults for the threshold pressures reasonable again,
but for some reason they are not exactly the same as in the old
implementation. (although the differences are very tolerable.)
On the question why only "Model 2" is affected by this: the other
decks don't use threshold pressures (SPE-X) or do not default any
values (Norne).
the opm-material classes are the ones which are now used by
opm-autodiff and this patch makes it much easier to keep the opm-core
and opm-autodiff results consistent. Also, the opm-material classes
seem to be a bit faster than the opm-core ones (see
https://github.com/OPM/opm-autodiff/pull/576)
I ran the usual array of tests with `flow`: SPE1, SPE3, SPE9 and Norne
all produce the same results at the identical runtime (modulo noise)
and also "Model 2" seems to work.
i.e. it now supports stuff like MULTFLT in the schedule
section. Possibly, the MPI-parallel code paths need some fixes. (but
if the geology is not changed during the simulation, the parallel code
will do the same as before.)
the most fundamental change of this patch is that the
reference/pointer to the DerivedGeology object is made
non-constant. IMO that's okay, though, becase the geology can no
longer assumed to be constant over the whole simulation run.
to be able to determine the threshold pressure from the initial
condition it needs to be able to access the initial condition, i.e.,
the initial simulator state, material properties object and gravity
constant need to be passed to the thresholdPressure() function.
to be able to determine the threshold pressure from the initial
condition it needs to be able to access the initial condition, i.e.,
the initial simulator state, material properties object and gravity
constant need to be passed to the thresholdPressure() function.
I have doubts if this will change anything in the binaries (and in my
personal opinion, these 'const's look quite ugly and are sometimes a
(small) annoyance when debugging), but I don't mind using the coding
style used by most of the rest of opm-core here.
we're correcting the pressure at the cell center depths to get the
pressure at the face depth, not the other way around. This is
confusing...
thanks to [at]totto82 for discovering this.
This needs to be done if a equilibration region transition is
mentioned by the THPRES keyword, but no value is given for this record
in the third item. (it seems that this is used quite frequently.)
Also, the approach taken by this patch also does not collide with the
restart machinery as far as I can see. This is because the initial
condition is applied by the simulator before the state at the restart
time is loaded. (I interpreted the code that way, but I could be
wrong, could anyone verify this?)
since it is pretty elaborate to calculate initial condition, this
patch is pretty messy. I also do not know if Eclipse does include
capillary pressure in this calculation or not (this patch does). Huge
kudos go to [at]totto82 for reviewing, testing and debugging this.
these are mostly stylistic: the function bodies of most new methods
have been moved to the _impl.hpp file and the Simulator classes are
now templated on the grid type, so it should be not too hard to switch
them to Dune::CpGrid.
in particular, where to put empty lines and spaces. Also added a
copyright statement for myself to a few files and added a comment. the
new comment was requested by [at]bska, the rest was requested by
[at]atgeirr.
With this the simulator is basically done, but since
FullyImplicitCompressiblePolymerSolver has not yet been converted to
the NewtonSolver plus Model approach, the solver cannot be removed and
thus still contains quite a bit of copy-and-pasted code.
since SimulatorFullyImplicitCompressiblePolymer is now a template, the
opaque pointer stuff is also removed and the contents of the .cpp file
basically became _impl.hpp. for SimulatorFullyImplicitBlackoilPolymer,
the opaque pointer stuff was removed for the same reasons as for
SimulatorFullyImplicitBlackoil.
the actual unification of code is not yet done, but this patch points
out the direction of where this will go.
Also note that some synchronization with the ordinary blackoil
simulator (FLOW) was necessary to make it compile.
Finnally, the parser currently likes to throw an exception (also for
the opm-polymer master) when eating the opm-data polymer test
case. This prevented me from properly testing this patch:
```
and@heuristix:~/src/opm-polymer|simplify_simulator > ./bin/flow_polymer deck_filename=/home/and/src/opm-data/polymer_test_suit/simple2D/2D_THREEPHASE_POLY_HETER.DATA
================ Test program for fully implicit three-phase black-oil flow ===============
--------------- Reading parameters ---------------
deck_filename found at /, value is /home/and/src/opm-data/polymer_test_suit/simple2D/2D_THREEPHASE_POLY_HETER.DATA
output not found. Using default value 'true'.
output_dir not found. Using default value 'output'.
Program threw an exception: IOConfig: Reading GRIDFILE keyword from GRID section: Output of GRID file is not supported
terminate called after throwing an instance of 'std::runtime_error'
what(): IOConfig: Reading GRIDFILE keyword from GRID section: Output of GRID file is not supported
Aborted
```
this is necessary because some older simulations only provide the
full-fledged solver class but no physical model.
(also, this allows to use something else than the standard newton
solver.)
so, far it is just a copy of the old "SimulatorFullyImplicitBlackoil"
class (which became a simple forward to the base class). The intention
is to unify the common simulator code in this class to avoid excessive
copy-and-pasting.
as far as I can see, it provided M4 macros for autotools based
projects which wanted to use OPM. I have severe doubts that this was
used by anyone because it most likely does not even work. (e.g. the M4
macros does not seem to specify the ERT and opm-parser prerequisites.)
Note that I'm not 100% sure of the above, so if I'm wrong, state so
loudly and I'll close the PR...
-O3 is sometimes declared "unsafe"
(cf. https://wiki.gentoo.org/wiki/GCC_optimization ) and it seems like
it bit us in https://github.com/OPM/opm-material/issues/23 if GCC 4.8
was used. so let's play safe and use -O2 for now...
the reason is that the tools for profiling and for coverage analysis
(i.e., gprof and gcov) have trouble with this and crash. if you want
this to be enabled for whatever reason, use the cmake flag
-DSTRIP_DEBUGGING_SYMBOLS=ON or pass configure the
--enable-strip-debug option.
first this makes the test very slow, second (and more importantly) it
makes the test fail on dune master as the header relies on the
presence of the DUNE_GRID_VERSION* macros which are not present at the
configure stage of the build...
as far as I can see, it provided M4 macros for autotools based
projects which wanted to use OPM. I have severe doubts that this was
used by anyone because it most likely does not even work. (e.g. the M4
macros does not seem to specify the ERT and opm-parser prerequisites.)
Note that I'm not 100% sure of the above, so if I'm wrong, state so
loudly and I'll close the PR...
this is now done by a config.h macro. The reason is that quite a bit
of code depends on boundary IDs which are only available as an
"experimental" grid extension in recent Dune releases...
this is required for GCC >= 4.8 to support the 'Q' suffix for floating
point literals (which are used in the quadmath.h header)
In order to prevent compilers which eat the flag but do not support it
from complaining constantly, it is tested for with "-Werror" enabled...
this is required to make the opm-core build succeed if ERT was build
with -DBUILD_SHARED_LIBS=OFF . (without it, I get errors like
/home/and/src/ert/devel/libert_util/src/thread_pool_posix.c:328: error: undefined reference to 'pthread_create'
this is basically the dune-grid grid manager for ALUGrid properly
out-sourced into an own module. (it does not require an external
library anymore, so it simplifies the build quite a bit.) Also, the
DUNE-ALUGrid module has quite a few new features and performance
improvements compared to the old code from dune-grid. For details, see
http://users.dune-project.org/projects/dune-alugrid
de facto, this does not change anything because opm-parser is required
and it has a hard dependency on ERT. It is good style to declare all
prerequisites explicitly in each module, though. Thanks to [at]bska
for the catch.
this is required for regex-matching keywords. Once GCC 4.9 is the
minimum compiler version to be supported, this can be dropped in favor
of std::regex ...
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
missing: the simulator using dune-cornerpoint. Once again, this is
because there is no good way to convert an intersection to a unique
global index (yet).
Andreas Lauser