Pump controls based on tank levels

[rb004f]

After reviewing the implementation of pump controls which are based on tank levels, there are a few corner cases that we are not capturing. Essentially, there are three constraints

1. If tank level is above threshold "a", turn pump off
2. If tank level is below threshold "b" turn pump on
3. If tank level is between a and b, keep pump in the same state as the previous time step.

Generally this is fine except in the corner case where the turning the pump on or off causes the tank level to cross a threshold. For example.

At time step t-1, the pump is off. In time step t, if the pump is off, then the tank is below "b". If the the pump is on, then the tank is between "a" and "b". This will create an in-feasibility, where constraint 3 is violated when the pump is on and constraint 2 is violated when the pump is off.

I think the only way to support this type of control is to introduce an intermediate "half step" to compute the controls, i.e. between time steps t-1 and t, we have a model of the flows at time step t when the controls of time step t-1 are used. These flows are used to set the the pump controls for which the actual flows of time step t are computed. This is not precisely what EPAnet does (i.e if the resulting controls result in tank levels which should change the pump state, EPAnet will change the state, and recompute the flows--which could ultimately failure to converge). However, what is proposed here is pretty close to the semantics of tank level controls.

I also believe this is the source of many of the discrepancies between simulation solutions (EPAnet) and the optimization solution. This should fix most of them, but I can still identify multiple feasible solutions, so I would not expect 100% matching when these controls are present in the models.

At the end of the day, we probably don't want to spend too much time on this feature... the pump optimization models will be controlling the pumps directly, and these tank level "policies" will largely be ignored.

@ccoffrin any thoughts?

[jjstickel]

@enzoliuyang94 brought up this point (or something similar) to me last week. He says that EPANET anticipates when tank limits will be crossed and then switches pumps (and/or pipe valves) between time steps.

[ccoffrin]

@rb004f, I am in agreement that correctness of the optimization model is the first priority.

In terms of encoding this constraint, I am not seeing why we would need a half-step in this case. Because the rules 1,2,3 break the tank level into 3 disjoint intervals the constraint just needs to identify which interval is active and then activate only the correct constraint in the following time step (pump-stat_{t+1}=0, pump-stat_{t+1}=1, pump-stat_{t+1}=pump-stat_{t}). This should work if the state at time t is a constant or a variable or did I miss something?

[ccoffrin]

After an in person discussion it was clarified that the semantics are more complex than items 1,2,3 and we concluded that this behavior is only of interest to replicating EPANET and can be implemented as a heuristic in the util at a later time.

[tasseff]

I'm currently revisiting this. What are everyone's thoughts on dropping this modeling capability completely from the wf formulation? That is, instead of trying to mimic the complex logic EPANET uses to control pumps based on tank levels, we don't support tank level-based control at all. Instead, the wf formulation will try only find a feasible pump schedule while ignoring all tank-based constraints that the EPANET file might imply.

[ccoffrin]

I agree and think your proposal is more consistent with the approach we are taking in WaterModels, which is an optimization first framework, rather than a simulation tool.

Given that, I would expect the the wf to be a feasibility problem that focuses on solving the system of nonlinear flow equations for an instant in time, that is too fast to consider discrete control actions.

In contrast, for the owf, we will assume all local control actions are optimization variables.

We could also consider emulating EPANET's behavior via a script that solves a sequence of wf problems and applys control actions based on whatever rules that EPANET uses.

[tasseff]

@ccoffrin, when you say wf assumes fast-enough time scales to neglect discrete control actions, is the implication that component indicator variables should be treated as continuous (i.e., between zero and one instead of binary)?

[ccoffrin]

is the implication that component indicator variables should be treated as continuous (i.e., between zero and one instead of binary)?

I was thinking the other extreme, these should be fixed.

For example, if you have a valve that changes state when some threshold is crossed, you would fix the state of the valve at the value from some previous time point, run the wf to understand the state of the flow from the physics equations. If you were doing a simulation you would observe those values, apply the control system actions based on some rules and then resolve.

Does that help?

[tasseff]

Yes, this makes more sense in the context of sequentially solving a problem.