these parameters where introduced with support for the TUNIING keyword
in `ebos`. since `flow` implements its own time stepping these
parameters are unused and should thus be hidden from view in it.
the former is caught by `ebos`, while the latter isn't. Alternatively,
this can be fixed by deriving `LinearSolverProblem` from
`NumericalIssue`, if preferred.
the original purpose of those is to provide a checkpoint/restart
mechanism using an ad-hoc file format. They might also be useful for
implementing the adjoint functionality, though.
using the eWoms API for wells, the Schur compliment was not applied at
all. If `BlackOilWellModel::linearize()` was made non-trivial, the
Schur complement was applied twice in `flow`. With this patch, we only
apply this using the eWoms API (in
`BlackOilWellModel::linearize()`). I could not observe a signficant
effect on the convergence behaviour of `flow` for the cases which I
tested (Norne and realization 5 of Model 2).
Somehow some standard output when running MILU () is still there and
it really clutters the output and and makes it unusable. This commit
removes it from flow.
I tested #1712 without deriving the `EclFlowProblem` type tag from
`FlowIstlSolver`, and it worked because the linear solver was still
`Opm::ISTLSolverEbos` because the linear solver is set via the
`LinearSolverSplice` a few lines down.
This time, I verified that the
`Ewoms::Linear::ParallelBiCGStabSolverBackend` was used if the
offending line was commented out. also, Norne worked fine with the
default solver as long as the Schur complement for the wells was done
explicitly.
Finally, the naming of the eWoms API is a bit inconsistent
(`setMatrix()` vs. `setResidual()`). any opinions here? I'm fine with
whatever.
Previously, this method did not take parallelism into account but just
checked the local wells for the constraints. Depending on the load balancing
of the wells this sometimes led to different return values of the function on different
processors. As the output is used to limit the time step size, different processors
were sometimes using different time steps in their local computations. This screwed
up convergence checks int the nonlinear operator such that only some processor thought
convergence was already achieved while others wanted to do more iterations.
With this commit the method now returns whether there is any well on any processor
with the constraint being true.
This commit adds an option that allows to enable detecting parallel
logging fallout (option --enable-logging-fallout-warning). It is now
false by default (previous behavior was as if the option was true).
If option is true a warning will be printed for any process with nonzero
rank that does try to log to *.PRT or *.DBG and the logged output will be appended
to these files at the end.
Previously runs of flow started with 'flow base.' Would result in base..DBG
files; note the double dot and the case sensitivity. Now the file will be
BASE.DBG in this case. Note that any extension will be stipped (not only
.DATA as before).
