this fixes some valgrind errors while doing the twophase capability
for flow_ebos: In all previously tested cases, these errors were
probably non-fatal because the memory illegally accessed here is
likely to be allocated (but after this function was finished it
contained garbage).
note that I'm not completely sure if this patch is semantically
correct, so I'd appreciate some input who understands it. (what is
"z"?)
When the group has wells both under individual control and group
control, since the well rates under individual control changes each
iteration, the well targets for this kind of group need to be updated
each iteration.
When we change to use implicit well potentials later, which is supposed
to be more accurate, we probably should always (unless we decided not to)
update the well targets each iteration.
it is for WellCollection, which is logically wrong. It should be done in
the group level, while things will be different for multi-level groups.
The current implementation basically works for current needs, that we
only have one group.
forced and only_group basically mean two opposite things. Having both of
them in the same context will be really confusing and error-prone.
And also, we do not do anything forcedly. We do things base on what
setup tells us to do.
Only_group may not be the final name, while deinitely a better one than
forced.
For the WellModel from the simulator to use. Not decided totally,
well_collection might need to be updated during the simualtion due
to the update the target of wells.
Current understanding. Two ways might prevent to return the guide_rate here
1. preventing the well from group control with keyword WGRUPCON
2. the well violating some limits and working under limits. We do not have strategy
to handle this situation yet.
Very hacky way here. The logic of the code is that only
a well is specified under GRUP control, it is under group
control. Which is not the case observed from the result.
From the result, if we specify group control with GCONPROD
and WCONPROD for a well, it looks like the well will be
under group control. TODO: make the logic correct here
instead of using `false` here.
opm-output's data::Wells interface changed to no longer just accept a
dump of opm-core's WellState object. Update WellState to restore itself
from this new interface rather than reading the dumped vectors as-is.
since the unit code within opm-parser is now a drop-in replacement,
this simplifies things and make them less error-prone.
unfortunately, this requires quite a few PRs. (most are pretty
trivial, though.)
- api changes in newer versions
- do not manually destroy the preconditioner. this is, and has always
been, owned by the ksp object and dies with its destruction.
the purpose of this is to get a more defined behaviour when doing the
gravity correction/upstream cell determination in the flux term.
I consider this to be just a kludge, so if anyone has a better idea of
what the composition for the non-existing gas and oil phases is,
please tell me. (note that generic compositional models do not exhibit
this issue because the composition of all fluids is always fully
defined because each component is assumed to dissolve in every phase.)
For these wells access its well_cells might read of the bounds
an array if they are the last wells in the struct. Therefore
we cannnot initialiue first_cell and the well control is uninitialized,
to.
With this commit theses wells are now detected and theor bhp, thp, and well_rates
are initialized to zero.
This reverts commit 09205dfa074af24b381595d02c15e799523ddb2b.
We cannot use the index as it might change for a well between different
report steps. Unfortunately the only persistent way to identify wells
over all report steps in the schedule seems to be the well name.
Before this commit we tried to compute whether a well is represented on
the processor using the grid information. Due to the overlap region and
possible completion on deactivated cells of the global grid this is not
even possible. E.g. we cannot distinguish whether a completion is just
not represented on the domain of a process or the corresponding cell is
not active in the simulation.
With this commit we refactor to passing the well manager an explicit
list of name of wells that should be completely neglected. This information
can easily by computed after the loadbalancer has computed partitions.
since
f(x) = 1 + 0.5*g(x)*g(x)
the derivative is
f'(x) = 0 + 2*0.5*g(x) * g'(x) = g(x)*g'(x)
note that the previous incorrect values do not affect the quality of
the obtained results (if the tolerance of the non-linear solver is
chosen to be small enough), but it may have deteriorated convergence
rates.
when well is closed due to rate economic limits, based on the auto
shut-in configuration, the well can be STOP or SHUT.
When well is closed due to all the connections are closed, it should be
SHUT.
