this has several advanges:
- a consistent and complete help message is now printed by passing the
-h or --help command line parameters. most notably this allows to
generically implement tab completion of parameters for bash
- the full list of runtime parameters can now be printed before the simulator
has been run.
- all runtime parameters understood by ebos can be specified
- no hacks to marry the two parameter systems anymore
- command parameters now follow the standard unix convention, i.e.,
`--param-name=value` instead of `param_name=value`
on the negative side, some parameters have been renamed and the syntax
has changed so calls to `flow` that specify parameters must adapted.
this is necessiated by the replacement of `std::shared_ptr` by raw
pointers for the eWoms auxiliary equation infrastructure. Note that by
default `flow` will *not* create an auxiliary equation module because
it modifies the operator that is used by the linear solver instead.
this was forgotten when moving the output writing code into the ebos
core. (this does not really matter for most people because
asynchronous output is wanted anyway and it was unconditionally
enabled.)
these objects are only used by flow_legacy, so not having to deal with
them anymore lets non-legacy flow avoid to jump through a lot of hoops
for the sake of having a common API.
this required a fork of the NonlinearSolver and AdaptiveTimeStepping
classes. this is not a problem because the original classes would get
pruned to look like the new ones once flow_legacy gets moved out of
the opm-simulators module.
an empty string is interpreted as "write the output files into the
same directory as the input". this is the current 'flow' default
behavior, plain ebos uses "." as the default location for output,
i.e., the current directory from which the simulator is run from.
this class is only used by the legacy simulators, `flow` uses the
`EclWriter` class provided by eWoms. In turn, this class uses the
new-and-shiny "tasklet" mechanism.
generally, this is a bad idea because GCC is very good at determining
which optimizations should be enabled or not and also, this may
interfere with some compilers. (e.g., it produces a warning on icc)
these files take the longest to compile. moving them to the beginning
speeds things up forn parallel builds because the remaining compile
can be compiled while dealing with the flow_ebos files while the build
stalls if these files are at the bottom of the list because they are
required for the library.
it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
if PETSc is not available, the .cpp file will compile fine because it
will be reduced to be empty, but trying to include
LinearSolverPetsc.hpp in this case will result in an error.
This is quite a hack: Even though energy is not a "phase" and it is
also not considered in MaxNumPhases and pu.num_phases because this
would break a lot of assumptions in old code, it is nevertheless
assigned an "canonical index" that can be translated "active index"
via PhaseUsage::phase_pos[]. This awkwardness is needed because much
of the legacy OPM code conflates the concepts of "fluid phase" and
"conserved quantity" and fixing that issue would basically mean an
almost complete rewrite of much of the legacy code. That said, the
same statement applies to polymer and solvent, but these are currently
handled as even more second-class citizens because they are not even
given a canonical index and also cannot be translated into an active
one.
this used to provide autotools compatibility, but it has not been working for a while. Thus it is IMO better to remove it in order not to mislead people.
the ThreadManager from ebos was not called which resulted in some
havoc when attempting multi-threaded runs.
v2: use opm_get_max_threads() directly. thanks to [at]akva2 for the heads-up.
it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
The old message was not really accurate anymore because flow also
supports the polymer and solvent extensions. (Also, the parentheses
around the version were removed because they are not necessary.)
v2: use the message proposed by [at]atgeirr
v3: re-add accidentially removed website URL
this needs to merged before the SimulationParameter hack can be
removed from eWoms. the patch will cause spurious deprecation warnings
until then. (i.e., it is best to merge them together.)
The motivation for this PR is that currently the build fails on my
Ubuntu 17.10 laptop with two processes because that machine "only" has
8 GB of RAM (granted, the optimization options may have been a bit too
excessive). under the new scheme, each specialization of the simulator
is put into a separate compile unit which is part of
libopmsimulators. this has the advantages that the specialized
simulators and the main binary automatically stay consistent, the
compilation is faster (2m25s vs 4m16s on my machine) because all
compile units can be built in parallel and that compilation takes up
less RAM because there is no need to instantiate all specializations
in a single compile unit.
on the minus side, all specializations must now always be compiled,
the approach means slightly more work for the maintainers and the
flow_* startup code gets even more complicated.
in particular, this implied some changes to the MPI initialization
code. since dune-fem's GridPart class currently has issues with
CpGrid's implementation of loadBalance(), parallel computations still
do not work if dune-fem is around, but at least sequential ones now
do even if MPI is enabled.
this is needed to avoid linker errors if this class ought to be used
in multiple compile units. IMO the main problem here is the use of an
_impl.hpp file.
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.
that parameter is called "max_strict_iter". This increases the
flexibility of this slightly and it avoids screwing up the default
value for the "max_iter" parameter in the future. The credits for this
patch go to [at]atgeirr for proposing it.
i.e. give up after 10 instead of 15 Newton iterations. since this now
also causes the CNV convergence criterion to be ignored after 8
instead of after 13 Newton iterations, and because CNV stagnation
seems to be the cause for the vast majority of the failures, it does
not lead to worse results or more time step chopping on Norne but
causes fewer wasted iterations.
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.
this prevents GCC-7's address sanitizer from complaining about a
delete for a new of a different type. (i.e., the new is for the
derived class, but if the destructor is non-virtual only the dtor of
the base class is called if a pointer to the base class is deleted.)
finding this was quite some fun, mainly because it took a while what
the issue was.
`flow_ebos` should be now capable of doing everything that
`flow_legacy` can and recently all testing seems to have been centered
on `flow_ebos`. note that `flow_ebos` does not yet support some more
advanced/exotic features like MPI, solvents, polymer, etc., but
neither does the plain `flow_legacy` binary. until `flow_ebos`
supports these features, the specialized simulators thus continue to
use the legacy code paths.
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.
or are these called integration tests? anyway, these are the tests
which use the decks from opm-data. This should put flow_ebos testing
on the same level as flow_legacy.
the results of `flow_legacy` and `flow_ebos` are not bit-wise
identical. The same tests using `flow_ebos` should to be added when
re-organizing the unit tests the next time.
This used to be done in solveJacobianSystem(), but this method is only
supposed to solve the linearized system of equations, not to modify it
IMO.
I tested this patch with Norne: It did not change anything.
this unifies the code paths of the code that calculates the FIP field
totals for the parallel and the sequential cases and makes the code
more robust because it does not hard-code the presence of an intensive
quantities cache anymore. also, rock compressibility is now also
included in the field totals instead of just the FIP regions. this was
forgotten in the last FIP PR because the region values are calculated
in a different class using completely different code. (i.e., regions
are done by the model, field totals by the simulator. that design
should win an award, IMO.)
with this patch, the field totals for Norne and SPE1 seem to match
those produced by E100 _very_ closely and also parallel and sequential
runs for Norne and SPE1 of flow_ebos produce exactly the same
numbers. (This is probably the case for all decks, but I haven't
tested anything else.)
mainly this should now work properly in parallel, because non-interior
cells are not counted multiple times anymore. also, the number of
loops over the global arrays has been reduced, some variables have
been renamed and some comments were added.
finally this fixes the average pressure for regions that do not
contain hydrocarbons (or at least it unifies it with the approach for
regions that contain hydrocarbons).
for now "all pore volume multipliers" means compressibility. the
storage term of the simulator includes them, so they need to be
considered when calculating the fluid in place as well.
for Norne the numbers are now very close to those of the ECL
reference. ("very close" means < 0.01 % deviation of pressure and
initial fluid volume for the field totals.)
in particular, the rock compressibility effects are not considered in
the FIP numbers anymore. While I'm not sure if this is correct or not,
it at least makes the results consistent with those produced by
'flow_legacy'.
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.
this information is already part of the EclipseState. The reason why
this should IMO be avoided is that this enforces an implementation
(ordering of the permeability matrices) 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.
in order to avoid code duplication, the permeability extraction
function of the RockFromDeck class is now made a public static
function and used as an implementation detail of the WellsManager.
finally, the permfield_valid_ attribute is removed from the
RockFromDeck class because this data was unused and not accessible via
the class' public API.
this information is already part of the EclipseState. The reason why
this should IMO be avoided is that this enforces an implementation
(ordering of the permeability matrices) 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.
in order to avoid code duplication, the permeability extraction
function of the RockFromDeck class is now made a public static
function and used as an implementation detail of the WellsManager.
finally, the permfield_valid_ attribute is removed from the
RockFromDeck class because this data was unused and not accessible via
the class' public API.
this is has become necessary by the recent SWATINIT changes and is
needed to calculate the fluid-in-place consistently as well as for
ebos to use the correct initial solution for the initial
linearization.
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.
Andreas Lauser