CONTROLS and RULES are redundant

[samhatchett]

I can't seem to come up with a case where a "control" cannot be expressed as an equivalent "rule". Besides being curious about how these two concepts evolved separately, I wonder if it would be better to cut out the "controls" functions and just have the input file parser interpret the [CONTROLS] section of the input file into "rules".

[samhatchett]

actually, it looks like RULES evaluate on time steps, whereas CONTROLS can shorten a time step based on a grade change. I still think it's worth considering combining the two.

[PatrickMoore-INV]

Sam,
From what I understand, there is a very big difference between Rule based controls and simple controls. While any simple control should easily be converted to a Rule based control as you noted, the rule based controls are not evaluated at the same time. Simple controls (what are usually stored in the control section) are evaluated at time = zero for any simulation while rule based controls are only evaluated after the first Rule timestep is passed. I recall asking Lou Rossman about this many years ago and he confirmed the delay in evaluating Rule based controls. In fact, form what I have seen it also seems like Rule based controls require a rule timestep in duration to pass between when a condition is met and when the rule is implemented. Since this is often 6 minutes or less ( based on 1/10th the default of 1 hour hydraulic timesteps, it is not often too noticeable, except that rules based on a specific time are often slightly delayed.

This is one of the primary disadvantages of rule based vs. simple controls in many cases in my opinion, but certain rules requiring two or more conditions require the use of rule based controls and the modeler (who knows how rule based controls and simple controls are evaluated) has to make the best of the differences. Simple controls are often much more intuitive and seem to be much more responsive in EPANET, but the notation in the full report of when they are implemented is not always as clear as rule based controls are in a full status report.

However, since many separate modeling packages that use EPANET as its hydraulic engine make rely on the current setup that any change could be problematic. I know of multiple modeling packages using EPANET runs a series of steady state runs to complete particular tasks and in those runs, any rule based control is ignored. This often leads to confusion with users because simple controls get evaluated, but rule based controls are skipped. If anything was changed it would be nice to have rule based controls and simple controls evaluate at the same time to avoid user confusion. If a change was eventually made to do this, I would suspect that most users would prefer how simple controls are evaluated over how rule based controls are evaluated rather than vice versa.

Just a thought. I'd be more than willing to discuss this with you further via a phone call if it would help.

[accumodel]

A careful read through the code shows the following additional thoughts regarding Rules and Controls:

1. The timestep can be shortened by a Control or a Rule
2. Controls are evaluated before the iterations start (see controls() in runhyd()) and between iterations if initial convergence is reached (links controlled by Junction pressure (see pswitch())).
3. Rules are evaluated after convergence in netsolve() when determining what the next timestep should be (see timestep()).
4. Rules can change the last action of a Control since they are evaluated at separate stages of the simulation, also vice-versa. There is not conflict checking between Rues and Controls in EPANET that I can find. Maybe conflict checking could throw a Warning in future versions of EPANET.

That being said, here are my thoughts:

1. Controls are more rigorous since they directly affect convergence of the solution. On the downside, sometimes they may make convergence more difficult.
2. I always try to use Controls over Rules whenever possible and I encourage others to do the same.
3. There may be circumstances where a Control is causing problems with convergence and the modeler may try converting the Control to a Rule so it is not evaluated during the iterations but between timesteps. I would only recommend this to advanced users that have the skill to evaluate the affects this may have on the output and accuracy of the model.

Therefore, both Controls and Rules have their place in the world. I do believe that these things could be documented better and that some logic could be added to the engine to detect where the model is having problems and spit out more Warnings in the text report.

[samhatchett]

Thanks Mark, it's interesting to know a little more about the nuances when it comes to application. I get the impression that both are useful for different scenarios, and agree that all this could be better documented. However, Rules and Controls could still be coalesced (even just internally to the code) if you tell the Rule/Control whether it should be evaluated during or upon completion of the solver iterations. In that case, the two evaluators would likely share more logic than they do currently. They are just so similar that I want to think that they are both special cases of a more general implementation.

not a big deal either way, just outlining some possible development paths.

[accumodel]

I think the evolution could look something like this:

1. More comprehensive documentation and use cases to educate users
2. Generate more warnings from the engine in cases where Rules and Controls have conflicts and warnings when specific Controls or Rules are making convergence difficult.
3. Deprecate Controls. Write all Controls as Rules. Attempt to evaluate all Rules at the point that Controls were previously evaluated. If any of the Rules give trouble, smartly push their evaluation to between timesteps (i.e. between timesteps). Provide a way for the user to force a new style Rule to be evaluated between timesteps and not during the solution.

One other thing that has also given me fits regarding Rules is the Priority setting. I always have to stare at it for a while and think it through to determine if I should set a priority. Most of the time I end up setting all Rules to the same Priority. Maybe there is a way to help users wrap their brains around Priority better in the future, or maybe that is just something that could/should be handled better in GUIs. ??

[eladsal]

@accumodel for two rules with the same priority value, the rule that appears first is given the higher priority - see remark 3 here.

[dickinsonre]

I was going to say that the way the priority is used is clear from the help file, it is also similar or the same in SWMM 5

""Rule-Based Controls are applied after an initial hydraulic state of the network is computed (i.e., after time zero). They are evaluated over the course of a hydraulic simulation as follows:

1. The rules are evaluated at a sub-hydraulic time step equal to 1/10 of the normal hydraulic time step (e.g., if hydraulics are updated every hour, then rules are evaluated every 6 minutes).
2. Over this sub-hydraulic time step, clock time is updated as are the water levels in storage tanks (based on the last set of pipe flows computed).
3. If a rule's conditions are satisfied, then its actions are added to a list. If an action conflicts with one for the same link already on the list then the action from the rule with the higher priority stays on the list and the other is removed. If the priorities are the same then the original action stays on the list.
   1. If the list is not empty, then the new actions are taken. If this causes the status of one or more links to change then a new hydraulic solution is computed.
4. The action list is cleared and the next sub-hydraulic time step is checked.

[accumodel]

Bob and Elad. You are both experts in the field and probably have been for quite a while. You also have been through the code. Think about the beginning or intermediate EPANET or EPASWMM user though.

There are alt least these many things to think about when constructing controls and rules for a model:

1. Controls
2. Rules
3. Priority
4. Order

All I am saying is that I have been using both packages for ten years and I still have to stare at it and re-read the documentation to keep it all straight. At the very least, removing one or two levels of complexity would be a good thing. A good place to start could be what @samhatchett and I commented on OR an even better place to start would be to make the order in which Rules appear (and thus read) the only Priority and not assign an additional Priority property.

[samhatchett]

closing as stale. also rules are not the same as controls. who knew!!