No extra equation is added for polymer in the well equation.
Seperate executables are added for polymer: flow_ebos_polymer
and solvent: flow_ebos_solvent
Tested and verified on the test cases in polymer_test_suite
This PR should not effect the performance and results of the blackoil
simulator
Possible values are none, log, and all. The first does not do any logging
to files. The second does log to files but does not create and log to
the DEBUG file. The latter uses all possible files.
Adds two switches no_prt_log, and no_debug_log that deactivate
writing to PRT and DEBUG file.
One can now run flow_ebos without creating any output by
passing "output=false no_prt_log=true no_debug_log=true"
on the command line.
the only thing that was used of this class was the phase usage object,
but the phase usage object can be accessed via much leaner interfaces.
The old BlackoilPropsFromDeck (without "Ad") is still required to
compute the initial condition, but the init code should be refactored
soon anyway.
now, the dune APIs are used whereever possible and the data is
computed for the global grid, i.e. for parallel runs it does not need
to be gathered across the processes anymore. Also, the INIT file is
now only written once instead of twice.
I've verified that the sequential and the parallel INIT files stay
identical for the Norne case and that the INIT file does not change
w.r.t. before this patch.
the fact that faces may point into the opposite Cartesian direction
was not considered and these output fields are specified
w.r.t. logically Cartesian cell indices. (not compressed ones!)
the corresponding code was shamelessly lifted from the DerivedGeology
class. it has been substantially modified to adapt it to the flow_ebos
specifics, though.
it was already almost unused (except for output). Besides making the
overall flow_ebos code leaner because it reduces redundancies, this
patch also implies a small reduduction of memory consumption and a
minor performance improvement. the latter is due to the fact that the
transmissibilities now do not need to be calculated more often than
necessary anymore.
since flow_ebos is the new silverback simulator of the opm-simulators
clan, it should itself as "flow"(the old silverback announces itself
as "flow_legacy" already).
Also some people seem to have been confused by the eWoms version and
codename. Since this information only exhibits limited value IMI,
let's remove it here.
the performance summary at the end of a Norne run which are printed by
`flow_ebos` now looks like this on my machine:
```
Total time (seconds): 773.757
Solver time (seconds): 753.349
Assembly time (seconds): 377.218 (Failed: 23.537; 6.23965%)
Linear solve time (seconds): 352.022 (Failed: 23.2757; 6.61201%)
Update time (seconds): 16.3658 (Failed: 1.13149; 6.91375%)
Output write time (seconds): 22.5991
Overall Well Iterations: 870 (Failed: 35; 4.02299%)
Overall Linearizations: 2098 (Failed: 136; 6.48236%)
Overall Newton Iterations: 1756 (Failed: 136; 7.74487%)
Overall Linear Iterations: 26572 (Failed: 1786; 6.72136%)
```
for the flow_legacy family, nothing changes.
Motivated by
- proliferation of identical code
- need to avoid strange behaviour with "." directory on some boost versions
- potenial for further refactoring to avoid boost entirely
The cat must have dragged that in during some of the various rebases of this branch.
This introduced a segmentation fault as for the second setup eclIO was already null.
Before this commit only the solution of process 0 was written.
To fix this we make the equilGrid of Ebos available. It is used
for the output writer. The properties written initially are gathered from
all processes first using the new gather/scatter utility.
All simulators now use SimulationDataContainer to store intermediate data that
is passed to the output Solution container. This is in cases not the most
efficient way, but it's unified to avoid errors from code duplication.
this information is already part of the EclipseState. The reason why
this should IMO be avoided is that this enforces an implementation
detail (ordering of the permeability matrices) of the simulator on the
well model. If this needs to be done for performance reasons, IMO it
would be smarter to pass an array of matrices instead of passing a raw
array of doubles. I doubt that this is necessary, though: completing
the full Norne deck takes about 0.25 seconds longer on my machine,
that's substantially less than 0.1% of the total runtime.
the canonical source is now the EclProblem object.
v2: don't change the API of the DerivedGeology class. thanks to
[at]atgeirr for noticing that this can be avoided.
I probably did not see this warning when testing f7910af7d7 because
I'm currently flooded by deprecation warnings stemming from
Eigen. (these warnings are caused because I use Ubuntu 16.04 and an
old version of Eigen is cloned by the build system that is not system
installed.)
* https://github.com/OPM/opm-simulators:
[bugfix] add defunct_well_names to BlackoilModelEbos.
[bugfix] fix ownerMask for parallel FIP code.
flow_ebos: tell the ebos in ourselves to not handle SWATINIT
[bugfix] Make initialization work in parallel for flow_ebos.
[bugfix] make flow_ebos work when no wells are present.
flow_ebos: only instantiate the grid once
this patch also includes code to make FlowMainEbos more autonomous
(i.e. it does not derive from FlowMainBase anymore). this allows more
flexibility how and what stuff gets created.
it now uses the grid object which gets created by ebos for everything
which should make the parallelization efforts easier. I also tried to
cut back the use of the legacy property objects (i.e., for the fluid,
geologic and rock properties), but this effort ran aground because of
the initialization and output code. (also, if those two were fixed,
there would probably be issues with the Newton update.)
I ran Norne with this and there did not seem to be any notable
performance regressions or benefits.
