the eWoms file naming convention should probably be changed to the one
of the remaining OPM modules, but this is quite a bit of work and IMO
it is more important to be consistent within the module.
instead, let's bit the bullet and add the few lines required for
regula-falsi-Pegasus method whenever the old RegulaFalsi class was
used. note that this leads to slightly different results for the
SPE5CASE1 flow test. I suspect that the old solvers behave in
unexpected ways, though...
Note that because the inverted functions are usually piecewise linear,
inversion can be done in a much smarter way.
this only deals with the easy things, i.e. UgGridHelpers::numCells()
and UgGridHelpers::dimensions(). a more thorough cleanup is needed in
the future to make ebos work with grids other than Dune::CpGrid again.
now, all the beauty of that part of the code can be admired in
initStateEquil.hpp.
During this exercise, I stumbled over some serious code-quality issues
like a different order of the template arguments for the declaration
and the definition, mismatching argument names and no forward
definition of some functions. besides this, some functions were
already defined in the non-_impl.hpp file and EquilibrationHelpers.hpp
used that approach from the outset.
this just moves the hydrostatic equilibrium code from its historc
location at opm/core to ebos/equil and adds minimal changes to make it
compile. this allows to clean up that code without disturbing the
legacy simulators.
since the unit code within opm-parser is now a drop-in replacement,
this simplifies things and make them less error-prone.
unfortunately, this requires quite a few PRs. (most are pretty
trivial, though.)
the purpose of this is to get a more defined behaviour when doing the
gravity correction/upstream cell determination in the flux term.
I consider this to be just a kludge, so if anyone has a better idea of
what the composition for the non-existing gas and oil phases is,
please tell me. (note that generic compositional models do not exhibit
this issue because the composition of all fluids is always fully
defined because each component is assumed to dissolve in every phase.)
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...
the largest change is that all classes below opm/core/props/pvt take
the PVT region index as an argument, the higher-level ones (i.e.,
BlackoilProps*) take cell indices.
depending on the grid implementation, the grid view / grid part object
does not necessarily follow the change. For some reason, the grid part
still does not work in the parallel case (tested with dune-fem 2.4),
but that seems to be an issue on the dune-fem side.
This reverts commit c873e8c92da389bc1d6bc4ed2a5241faddfa7630.
since OPM/opm-simulators#1287 has been merged there are no "in tree"
upstreams which use that mechanism anymore.
this now works with the unmodified master version of flow from
opm-simulators. we take the liberty to emit a deprecation warning,
though. this complicates things quite a bit.
This gets rid of some special-purpose code in generic places (i.e. the
`SimulatorParameter` class) and no special hacks to the property and
parameter system are required anymore.
this reduces the number of direct deck accesses in `EclProblem` in
favour of `EclipseState`-grid properties. as far as i can see,
directly using the deck object cannot fully be avoided because
`EclipseState` does not seem to provide internalized versions of all
these keywords yet.
the NTG value for active cells in the topmost layer was always
1.0. This resulted in some deviations in the transmissibilities of the
Norne deck which lead the init file comparison unit tests from
opm-simulators to fail.
Conceptually this is IMO pretty questionable, since it adds a second
"gas phase" that does not mix with "ordinary" gas. I suppose the
reason why this extension was conceived by E100 is that if all you
have is hammer, everything looks like a nail...
Functionality-wise, this patch is still not fully complete because
miscibility of the solvent "phase" is not yet implemented. As far as I
can see, the API changes required by miscibility are quite limited,
though.
let's use zero instead of 10^-18. This can have a small impact on
performance, but the new version is definitely "more" correct, and
also Norne performance seems to improve slightly on my machine.
this was found using GCC-7's address sanitizer. I suspect that this
did not surface earlier (i.e., with valgrind), because newly allocated
memory gets initialized to zero by the operating system, so the value
of the pointer was zero and the delete operator did what was right by
coincidence. the new asan seems to initialize memory randomly, though.
if the initial solution is explicitly given by the deck using the
PRESSURE, SWAT, etc. keywords, the specified state can be
thermodynamically impossible. To avoid inconsistencies, we use a flash
calculation to find a state that is in thermodynamic equilibrium and
exhibits the same masses as the explicitly specified solution. Since
the flash solver needs to compute quantities for all fluid phases, but
two-phase blackoil simulations usually do not specify the properties
of one phase, the flash solver crashed. This patch works around that
issue by simply not using the flash solver in the twophase case, i.e.,
the explicit initial condition must be thermodynamically consistent in
order to produce the stable results for a different choice of primary
variables.
This only makes these transmissibilities available for parallel
computations. The reason is that in the sequential case, they do not
need to be computed during grid creation and they are are also
accessible via the problem object.
hopefully this makes standalone `ebos` arrive at the same initial
condition as `flow_ebos` if both, SWATINIT and threshold pressures are
enabled. we need to calculate the initial condition twice either
threshold pressures and SWATINIT are enabled. (`ebos` and `flow_ebos`
diverged after OPM/opm-core#1129.)
the proposed patch is a kludge IMO, but in the light that in my
opinion, SWATINIT and threshold pressures are both physically not
justified and given the fact that SWATINIT must not be considered for
the threshold pressues should be considered to be a bug of the
reference simulator, I think the patch is okay.
we now store the maximum oil-water capillary pressure and apply it to
the material parameters later. this simplifies things within the
EquilInitializer somewhat and also allows external code (i.e.,
flow_ebos) to choose when SWATINIT gets applied.
this makes creating the grid a bit slower because the
transmissibilities need to be calculated twice: once for the
sequential grid and once for the distributed one. while corresponds to
the way `flow_legacy` does the load balancing and it should allow
better results, this does not seem to be the case for the Norne deck
if ZOLTAN is not available:
After loadbalancing process 3 has 4413 cells.
After loadbalancing process 2 has 12390 cells.
After loadbalancing process 0 has 13629 cells.
After loadbalancing process 1 has 21253 cells.
i.e., process 1 is responsible for almost 5 as many cells as process
3.
before, they were undefined for phases which exhibited zero mobility
in both directions. since in this case the flux is zero (and thus the
upstream direction does not matter), the correctness is unaffected by
this patch. (still, I consider it to bug and valgrind also complained
about it.)
i.e., using clang 3.8 to compile the test suite with the following
flags:
```
-Weverything
-Wno-documentation
-Wno-documentation-unknown-command
-Wno-c++98-compat
-Wno-c++98-compat-pedantic
-Wno-undef
-Wno-padded
-Wno-global-constructors
-Wno-exit-time-destructors
-Wno-weak-vtables
-Wno-float-equal
```
should not produce any warnings anymore. In my opinion the only flag
which would produce beneficial warnings is -Wdocumentation. This has
not been fixed in this patch because writing documentation is left for
another day (or, more likely, year).
note that this patch consists of a heavy dose of the OPM_UNUSED macro
and plenty of static_casts (to fix signedness issues). Fixing the
singedness issues were quite a nightmare and the fact that the Dune
API is quite inconsistent in that regard was not exactly helpful. :/
Finally this patch includes quite a few formatting changes (e.g., all
occurences of 'T &t' should be changed to `T& t`) and some fixes for
minor issues which I've found during the excercise.
I've made sure that all unit tests the test suite still pass
successfully and I've made sure that flow_ebos still works for Norne
and that it did not regress w.r.t. performance.
(Note that this patch does not fix compiler warnings triggered `ebos`
and `flow_ebos` but only those caused by the basic infrastructure or
the unit tests.)
v2: fix the warnings that occur if the dune-localfunctions module is
not available. thanks to [at]atgeirr for testing.
v3: fix dune 2.3 build issue
the main part of this patch is actually an API change of
Ewoms::ThreadedEntityIterator to faciliate the change (since we should
prefetch the data for the element which is to be linarized after the
current one.) Also, this patch is only an 80% solution: it would be
good if the cached intensive quantities of the model and the stencil
of an element could also be prefetched, but that's currently not
easily possible in a performant way because iterating over the
intersections of an element negates the performance gains obtained by
prefetching.
the class is called "PffGridVector", which is short for "PreFetch
Friendly Grid Vector" ("Vector" in the sense of std::vector). The idea
is to store the data in question for the complete stencil of all
elements which makes the memory access pattern of the simulation much
more localized. this approach has the downsides that much more memory
is required to represent the data (for cartesian 3D grids this means
about factor 8 more), and that data cannot easily be changed for an
individual degree of freedom (because it would require to change the
representations of all stencils which contain the DOF).
also, use this new class to store the transmissbility values of
ebos. it is pretty easy to extent the number of quantities stored this
way, but it seems like the performance of linearization stays flat or
is slightly worse if the PffGridVector is used for more quantities...
Andreas Lauser