* origin/master:
Bugfix: use correct object in sequential model.
Bugfix: properly handle two-phase cases.
Bugfix: pass both normal and extra data to output.
Update well data output integration.
Adapt to API change in opm-parser.
Ensure logging only on first rank.
Add isIORank_ member to avoid repeated calls.
Rename isRankZero() -> isIORank() for consistency.
Ensure only first-rank logging.
Add isRankZero() utility.
Bugfix: missing return.
do not set limits for prt log and set correct value for Note.
correct function call order and add whitespace.
supprot MESSAGES default vaule.
wellToState reads new opm-output data exchange
Write control to data::Wells. Missing ability to restore.
Avoid using buggy wellstate api
Stop report early if there are no wells
Update to interface change in opm-output
the 'tempV' object currently only contains garbagee but the condition
is needed and will thus be fixed in a different PR.
thanks goes to @totto82 for the clarifications.
note that I don't know if these changes are semantically correct (I
doubt it), but this patch fixes the valgrind complaints I saw for
SPE9_CP and on Norne.
Also, this makes the timing of flow_ebos for SPE9 determinisic between
runs: without this, I got some random time steps fail in a given run
and in the next run a completely different set of timesteps
failed. Since this was on the same same machine, without any
recompiles and no changes to the deck or any other input parameters, I
initially attributed the behavior to cosmic rays ;)
@totto82: could you have a thorough look on this?
once again, the culprit was an API change in opm-output. I suppose
this means that the frankenstein branch should be merged soon after
the release in order to avoid to continue breaking the flow_ebos build
twice a week.
* master: (42 commits)
Let only one rank write to step_timing.txt
Do not refer users to issue tracker if multiple procs log.
Remove unused variable.
Use vector instead of VLA, also add missing includes.
changed: bundle eigen3 in the original tarball for debian
update redhat6 packaging
Bugfix parallel computation of weighted pressure etc.
Fixed uninitialized bug, and added logging/comment
Removed superfluous std::move
Refactoring
Initial version of summary data
Do not store collective communication in the wells object.
Make sure that updateWellControls is called on each process.
Make WellSwitchingLogger work with DUNE 2.3
Schedule::getGroup returns reference, not pointer
Removed warning in WellSwitchLogger::calculateMessageSize
Correctly initialize MPI for multisegment wells test
Changed some names in WellSwitchingLogger
Use speaking name for bool in getCellData
Whitespace and other formatting changes
...
this should not change the value of the result at all (because the
total delta which is added to the phase pressures stays identical),
but it should be less confusing when comparing this with the code that
calculates the gravity correction term in the flux calculation.
maybe it worked as-is, or maybe decks which lead to illegal accesses
to the map are incorrect (i.e., they specify threshold pressures for
EQUIL-regions that do not touch), but let's play save here...
... to calculate phase densities for the threshold pressure
defaults. I don't know if the reference simulator does this, but this
makes it consistent with what's done in the flux calculation of flow.
* remotes/totto82/frankenstein_mod:
Fix seg-fault for cases without wells
Some micro performance improvments and cleaning
Add THP support in the denseAD well model
Only solve the linear system when it is not converged.
Revert changes to NewtonIterationBlackoilInterleaved.cpp
add and use class wellModelMatrixAdapter
Remove unused code and remove Eigen vectors
New updateState
Some cleaning and small changes
almost all of them were caused by recent changes in the master
branch:
- there were methods added which depend on the types `V` and
`DataBlock`. these do not make much sense in the context of the
frankenstein simulator. Also, these types are defined globally for the
whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be
prosecuted as a fellony IMO)! Besides this, their names are useless;
'V' is the letter which comes after `U` in the alphabet and when it
comes to computers basically everything can be seen as a chunk of data
(i.e., a `DataBlock`).
- it seems like the new and shiny dense-AD based well model was never
compiled with assertations enabled, at least some asserts referenced
non-existing variables.
- the recent output-related API changes were pretty unfortunate
because they had the effect of tying the (sub-optimal, IMO) internal
structure of the model even closer to the output code: as far as I can
see, `rq` does only make sense if the model works *exactly* like
BlackoilModelBase and friends. (for flow_ebos, this could be
replicated, but first it would be another unnecessary conversion step
and second, most of the quantities in `rq` are of type `ADB` and much
of the "frankenstein" excercise is devoted to getting rid of these.) I
thus reverted back to an old version of the output code and created a
`frankenstein` branch in my personal `opm-output` github fork.
this simplifies handling the pore volume by centralising the code,
i.e., moving it into opm-parser. (in particular, it makes the MINPV
handling consistent with the active cells which get removed by the
grid.) If eclipse turns out to be inconsistent here, we need to deal
with atrocities like the MULTREGP keyword on a case-by-case basis,
i.e., it would considerably uglify the code and be an additional
maintainance burden.
note that besides supporting of MULTREGP, the code should now also
handle explicitly setting the pore volume via the PORV keyword
correctly....
remove the now unnecessary inclusion of
"NewtonIterationBlackoilInterleaved.cpp" (mind the .cpp extension!)
and include "dune/istl/solvers.hh" instead.
there was a screw-up with the output directory (to set it you need to
modify the EclipseState by means of the IOConfig object? WTF?) and it
seems like the FlowMain.hpp was modified since FlowMainEbos.hpp was
added so there was some terminal output missing.
for the gas-only case with vaporized oil enabled, the oil pressure was
used, but ebos uses the gas pressure as a primary variable in that
case. (the reason is that it is faster to check if oil appears if the
gas pressure is available in that case.) This patch corrects that and
does no longer use the PrimaryVariables::set$FOO_PV() methods because
these methods are hard to keep in sync with the indices for the
primary-variables-as-a-Dune::FieldVector feature (which is actually
quite important for the linear solver).
i.e., the contents of the Opm::details namespace, the IterationReport
and the DefaultBlackoilSolutionState classes. the purpose of this is
to share the code between the existing flow variants and flow_ebos.
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.
Andreas Lauser