Open SouthEndMusic opened 10 months ago
Also make sure that there are no conflicts between 'normal' control and control coming from allocation. This is probably a validation issue.
Let's try whether allocation can update the setpoints for control instead of setting the control actions itself.
For a subnetwork with an inlet to the main network, we want to:
Flow over an inlet (Outlet or Pump) can be set by either allocation or control, but not both. Initially this can be up to the user to avoid conflicts, though perhaps we can add validation for this later.
@visr this issue is not about connections between the main network and subnetworks, I propose moving that discussion to https://github.com/Deltares/Ribasim/issues/768.
It came out of a discussion with @SnippenE @visr that a good way to approach this is to actually expand the capabilities of DiscreteControl
, in the sense that conditions can be placed on allocation flows.
For an downstream demand driven Outlet or Pump, we can support setting a special control state "allocation"
, which will set the flow_rate
to the cumulative allocation flows over all priorities on the outcoming (or ingoing) edge.
We can add a validation rule that the control_state
in DiscreteControl / logic is not allowed to be "allocation"
. If need be we could support that in the future.
After discussing this together, I have the following proposal:
controlled_by
column to static. We can track this internally as a ControlType
enum. The network and our logic determines the ControlType
. This helps to avoid specifying things in two places.ControlType
is PID
.ControlType
by deactivating the PID controller.ControlType
to allocation
by setting ribasim.allocation
to be the control_state, irrespective of if that exists in the static table.ribasim.allocation
but no incoming control edge, ControlType
is allocation
.
What After a refinement session, we (@SouthEndMusic, @gijsber, @visr) came to the conclusion that it would be nice to have a special control state "allocation", which is not defined via the
static
tables but means that the flow of aPump
orOutlet
is set by allocation. However, when working out this issue so that @Jingru923 can collaborate on it, I came to some slightly different ideas on how to mark a node as being controlled by allocation, see below.How
static
tables ofPump
andOutlet
namedcontrolled_by
, with allowed values "nothing" (default), "allocation" and "PID". We could set PID controllable nodes to PID by default to avoid a breaking change.Pump
andOutlet
nodes to indicate if and how they are controlled: The allocation algorithm must know which nodes are allocation controlled so that theirflow_rate
can be set. These nodes already have a boolean flagis_pid_controlled
, so instead of adding a new flag, let's modify this one to an enumeratorControlType
with values of thecontrolled_by
options above.flow_rate
_: after a run of the allocation algorithm, the flow through nodes that are allocation controlled must be computed and assigned. The assigned flow must be the sum over the priorities of the flow through the inflow edge of allocation controlled nodes. This sum can be computed during the allocation algorithm in pre-allocated memory, or be computed afterwards using the data in theflow_record
(@visr let me know whether you think the latter is a good idea).water_balance!
.Validation
Reasons why I prefer this over the original idea
DiscreteControl
getting involved;DiscreteControl
can change the control type during simulation (for PID control it must be checked whether it is available for the node, preferably during initialization). Note that this means thatDiscreteControl
overarches the other control types, which is also why it is not one of theControlType
options.