and give warning messages when they happen, since they can be the
culprits of the termination of simulation later.
For ADB related, I did not find a good way to do the detection, so there
is no warning message given.
Even the well does not have a THP target/constraint, but if it is
specified with a valid VFP table, we are supposed to update the thp
value for output purposes.
When there is some events happen to a well, we use the control mode
from the DECK, and update the WellState based on the new control model.
Otherwise, we can use the control mode from the previous well state,
and keep the values from the previous well state as an intial guess.
* fixed the issue of including ghost cells in preconditioning, by zeroing out ghost rows and setting the diagonal to a large value.
* move altering of matrix to a function
* blockwise modification of matrix
* add findOverlapRowsAndColumns in BlacoilDetail. Add call to findOverlapRowsAndColumns in constructor of BlacoilModelEbos. Change makeOverlapRowsInvalid, by looping over precalculated inddies instead of grid
* Better formatting
it is possible that a dune entity vanishes if its iterator gets out of
scope. Whether this is a problem or not seems to be be highly depend
on the used configuration...
also, clean them up a bit:
- do not use the intensive quantities cache directly anymore. (i.e.,
that code should now work if the IQ cache is disabled)
- do not fiddle with the global Jacobian matrix and residual vector
directly. Instead, implement the water fluxes to the reservoir as a
source term like wells.
one thing that did not become fully clear to me is if each aquifer
ought to be assumed to be in contact with the whole reservoir or just
a few cells on the boundary. The current implementation goes down the
former path, while, without any deeper knowledge, I would rather
suppose that the latter applies. maybe my understanding of this is
just too limited, though.
This is to preserve current behaviour. Infinity is used in the test
currently, rather than the provided parameter (that is only used for
mass balance/flux equations).
also, add a "reading deck" output. The idea is to make `flow`'s
behaviour less surprising by preventing people from thinking that
nothing happens after starting `flow` for a large deck.
The problem was only present if UMFPack was not found and therefore
FLOW_SUPPORT_AMG was defined to true. In that case we experienced compile
errors in a source branch that would never be executed. Therefore we remove
the code there and throw an exception.
i.e., mine (openSuse Tumbleweed). the problem seems to be that the
specialization of `ISTLSolver::constructAMGPrecond()` is ambiguous and
some compilers seem to be more strict about this than others. Simply
removing the problematic method seems to work fine.
That said, for non-legacy `flow` this codepath is not taken at runtime
anyway because the `ISTLSolverEbos` class is used!?
This fixes fallout from the merge of PR #1512. Since then the
ParallelFileMerger was always given the current directory even if
another output directory was requested. This resulted in
CASENAME.<procid>.<ext> files in that directory never being merged and removed.
Now the ParallelFileMerger gets the output directory path again.
It should be --milu-variant and is it now. Maybe the parameter system
could be a bit smart and detect consecutive upper case letters and treat
them correctly.
- Change the brief description slightly
- Do not print anything anymore if there are no unused parameters
- Change the boiler plate text for printing the parameters to the
PRT/DBG files
in part, this has been requested by [at]atgeirr.
bph should be "bhp" and "DWellFractionMax" looks weird as a command
line parameter (-d-well-fraction-max). now, it only looks slightly
weird in the c++ code.
this has been requested by [at]atgeirr.
Note: The FlowLinearSolverVerbosity, FlowNewtonMaxIterations and
FlowNewtonMinIterations parameters are still prefixed because they
clashes with parameters registered deeply within eWoms.
while they do no longer appear in the help message, in the code they
are still there and can be specified and used as normal.
also, this patch makes --print-parameters=1 and --print-properties=1
work.
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.
We introduced two runtime parameters for this: ilu_redblack and
ilu_reorder_spheres. If the last one is false, we try to preserve
the ordering within in the colors. Otherwise we try to achieve a D2
(alternative diagonal) ordering.
These versions are inspired by the ones used in SuperLU and the enums
to choose them have simuilar names, but without leading S (MILU_1-MILU_3).
The following variants are supported (chosen by the enum MILU_VARIANT):
ILU: plain ILU
MILU_1: lump diagonal with dropped row entries.
MILU_2: lump diagonal with the sum of the absolute values of the dropped row
entries.
MILU_3: if diagonal is positive add sum of dropped row entrires. Otherwise substract them.
MILU_4: if diagonal is positive add sum of dropped row entrires. Otherwise do nothing
These versions are inspired by the ones used in SuperLU and the enums
to choose them have simuilar names, but without leading S (MILU_1-MILU_3).
The following variants are supported (chosen by the enum MILU_VARIANT):
ILU: plain ILU
MILU_1: lump diagonal with dropped row entries.
MILU_2: lump diagonal with the sum of the absolute values of the dropped row
entries.
MILU_3: if diagonal is positive add sum of dropped row entrires. Otherwise substract them.
MILU_4: if diagonal is positive add sum of dropped row entrires. Otherwise do nothing
We did add the dropped matrix blocks to the diagonal blocks,
but this is not MILU where oone only modifies the diagonal.
With this patch we fix this behaviour and now only modify the
diagonal of the diagonal block.
Using the parameter ilu_milu=true|false (default=false) the user can now choose
to use the modified ILU0 decomposition. If selected values will
not be dropped for nonzero entries but added to the diagonal of U.
This approach will result in A*e = L*U*e for vector e with all entries
beging 1.
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.
