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.
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.
