Adds a conservation equation for polymer.
Polymer concentration in the water phase is used as primary variable
The polymer influences the viscosity of the water, and leaves gas and oil
uneffected.
A shear multiplier is computed if PLYSHLOG and/or SHRATE is specified
based on either velocity or shrate.
The shear multiplier effects the water and polymer viscosity.
Tested and verified on the test cases in polymer_test_suite
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.
- initialization only via Ecl Deck
- adds modification of relperms and cap-pressures for miscible runs
- adds TL mixing model for effective viscosity and density calculations
Tested on SPE1CASE2_SOLVENT_MISC_TL, SPE9_CP_CO2_MISC_TL, SPE5CASE1-3
and SPE3CASE1_SOLVENT_MISC
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.
Face centers are computed using the cell corners. With this
implementation the face center seen from a cell may be different from the
face center seen from its neighbour.
Face normals with area lenghts are calculated using the face corners
directly not using a triangulation point in the center of the face.
This gives transmissibility almost equal to eclipse.
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.
Judging from ParallelDebugOutput.hh this is what is should be.
Before this commit it was empty as it had space reserved but never
any entries pushed (they were inserted with operator[]).
This reverts commit dde79daf4ec2004148a58250c4c8af5390251689.
Judging from ParallelDebugOutput.hh this should not be a map from element
index to interior element index, but an a list of indices of all interior
elements. Therefore we need to reserve and later on push_back.
This reverts commit 09db2fd412abe4b8a2f52274bcc0041e4b20a94d.
Judging from ParallelDebugOutput.hh this should not be a map from element
index to interior element index, but an a list of indices of all interior
elements
Previously distributedCartesianIndex was resized and afterwards all
entries were added with push_back. Therefore the array was twice as
big as expected and contained wrong values in the front.
With this commit we insert the values using random access. Thus the
size is as expeceted and the index of the entries do not depend on the
order of the grid traversal.
While it may not produce memory errors it is semantically wrong to insert
entries with random acces into a vector that has reserved enough memory to
hold the values but still has size 0.
