There is a problem compiling upstream
Hierarchy::recalculateGalerkin() without MPI. Therefore we
reimplement that method in our AMG version. Fixes will travel
upstream.
Apart from that we made sure that all types have a meaning even
if there is no MPI found and that we at least have redistribute method
to call even if using SequentialInformation. In that case the method
does nothing but prevents compilation errors complaining about missing
parallel functionality.
As the AMG hierarchy is kept and uses the initial OwnerOverlopCommunication object
we need to make sure that this object lives as long as the hierarchy. We assure
this by storing a shared_ptr to it in ISTLSolverEbosCpr and reuse it to construct
the WellModelMatrixAdapter.
Previously the OwnerOverlapCommunication object was owned by the adapter as a
unique_ptr was used. The change to shared_ptr makes it possible to to extract
it and reuse even if OwnerOverlapCommunication is thrown away.
Moving out of a matrix in the same function argument list as the matrix is passed
to another function is wrong. Simplified by avoiding the unwieldy tuple.
it is just a temporary approach to recover the prediction case. In the
case, there is no group control, while there is some requirements of
well potential output
some details to come to make it complete.
We are not handling it for injectors and also we are not considering the
upwinding when handle the frictional pressure loss and acceleration
pressure loss.
Then Wells struct and well from parser hold different numbers of
connections.
The current approach is a temporary solution. The final approach should
be done through parser side.
Things can be difficult is because that connections can be removed due
to multiple different causes after parsing. How to keep information
always updated is not trivial.
When multisegment wells are involved for RESTART, based on the recovered
segment-related quantities as Opm::data::Segment objects, the segment
phase rates and segment pressure are recovered as part of the
WellStateFullyImplicitBlackoil.
Forgotten in previous commit. This restores our ability to run
flow-legacy with the new WellStateFullyImplicitBlackoil::report().
Thanks to Kai Bao for alerting me to the issue.
This commit adds a new data member, seg_number_, that maps a linear
segment index (0 .. #segments - 1) to the appropriate segment number
(segment ID). This ensures that member function report() is able to
produce segment results in terms of user-assigned segment numbers
rather than linear indices internal to the simulator and its state
variables. This, in turn, decouples the well state object from the
output (summary/restart) code and makes the restart facility more
self contained.
Rewrite the unit test for WellStateFullyImplicitBlackoil to account
for the new indexing scheme when assigning the synthetic segment
results.
While here, also abide by the file's naming convention for data
members and locals.
This commit extends class WellStateFullyImplictBlackoil to report
segment-related quantities as Opm::data::Segment objects (included
in Opm::data::WellRates objects). All wells have at least a top
segment in the context of WellState FIBO, so there is a meaningful
value to report for each well.
We put the extraction of segment-related quantities into a new
helper function
WellStateFullyImplicitBlackoil::reportSegmentResults()
to avoid cluttering up the body of report() more than absolutely
needed.
The primary use-case for this is assigning appropriate values to
items 8 through 11 of restart vector RSEG. In turn, this will
enable restoring these quantities from a restart file.
Concretely this avoids having to patch eWoms by adding a generic
`Opm::transposeDenseMatrix()` template function instead of relying on
the dense matrix class to provide a `transpose()` method.
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).
