Removed message in amgclbackend was:
warning: catching polymorphic type ‘class
boost::property_tree::json_parser::json_parser_error’ by value
[-Wcatch-value=]
The reduction rate is computed differently for cases without wells under GRUP
For a well to check whether to switch to GRUP it needed to use the reduction rate
that would have been computed if this particular well was under GRUP control
and thus recompute the reduction rate without entering the no-grup path
This commit extends the guide rate reporting to always extracting
and reporting pertinent production guide rates at the well level
(i.e., WxPGR) if at least one of the groups in the well's upline has
an entry in GCONPROD. This is for increased compatibility with
ECLIPSE.
This commit uses the new GroupTreeWalker helper class to ensure that
we always extract and report pertinent injection guide rates at the
well level (i.e., WxIGR) if at least one of the groups in the well's
upline has an entry for the corresponding phase in GCONINJE. This
is for increased compatibility with ECLIPSE.
Prior to this change we would report zero-valued WWIGR vectors on a
real field case which made analysing simulation results needlessly
difficult.
This commit extracts a helper class, GroupTreeWalker, from the
current implementation of 'calculateAllGroupGuiderates()'. This is
in preparation of adding a similar approach to extracting WxIGR for
all wells for which at least one group in the upline has an entry in
GCONINJE.
The user can add visitor operations for wells and groups, typically
with side effects, and then choose whether to run a pre-order walk
(visit groups before their children) or a post-order walk (visit
children-i.e., wells, before their parents).
The class ISTLSolverEbos has all features of the removed class, and
is not much more complex. The flow_blackoil_dunecpr is the only
program using it, and is redundant.
This guarantees, under the assumption that the group tree does not
have cycles, that we do not accumulate group-level guide rate values
until all of its children are fully evaluated. We use an iterative
depth-first post-order tree traversal with an explicit stack instead
of a recursive implementation.
The previous implementation, which tried to do the same kind of
child-to-parent accumulation, might visit a parent group multiple
times which in turn might lead to losing updates. This is a more
formalised approach to the value accumulation than was originally
employed.
