Support conditional evaluation by time/clocktime of high / low level triggered controls

[cegonse]

Currently simple controls can only evaluate a single condition of either time or pressure/level, though it is common for both variables used in tank inlet controls.

This can be solved using a rule instead of a simple control in EPANET, however, we are interested in seeing if there is interest in extending simple controls to also consider a starting and finishing time.

For example, a tank may change its set point at nighttime to ensure it is near full before the morning peak and then lowering it during the day.

The INP control syntax would be modified as below

LINK <id> <status/setting> IF NODE <id> ABOVE <threshold> FROM <TIME/CLOCKTIME> <t0> UNTIL <TIME/CLOCKTIME> <t1>

And for the time based control set point described above could be applied below:

LINK valve CLOSED IF NODE tank ABOVE 3.5
LINK valve OPEN IF NODE tank BELOW 3.0 FROM TIME 23.0 UNTIL TIME 6.0
LINK valve OPEN IF NODE tank BELOW 2.0 FROM TIME 6.0 UNTIL TIME 23.0

In addition, the FROM and UNTIL parameters could be optional, as shown below:

LINK Pipe1 CLOSED IF NODE Tank2 BELOW 0.1 FROM CLOCKTIME 12:30
LINK Pump3 1.25 IF NODE Tank10 ABOVE 12 UNTIL CLOCKTIME 6 AM
LINK Valve1 OPEN IF NODE Tank1 BELOW 9 FROM TIME 8.25 UNTIL TIME 23.5

We have done a partial implementation of this feature, supporting only TIME conditions to understand the scope of the change (check this diff for details Comparing OpenWaterAnalytics:v2.2...qatium:wip/APP-8260 · OpenWaterAnalytics/EPANET ).

Introducing these changes would imply modifying the control struct to store the information in runtime, conditionally evaluating controls depending on Htime and Tstart, handling the new parameters during INP save and parsing the new fields when loading INP files.

One of the main challenges we faced during our test was allowing setting these new fields through the toolkit through EN_addcontrol and EN_setcontrol without breaking backwards compatibility with the ABI. We would really appreciate feedback regarding how could this be tackled

[LRossman]

Couldn't you add new API functions, EN_addcontrolex, EN_setcontrolex, and EN_getcontrolex to accommodate the extended simple control syntax.

But to be honest, since these types of conditions can already be expressed using rules I don't understand what the benefit is to extend the simple control syntax in this fashion.