Closed samhatchett closed 5 years ago
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.
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.
A careful read through the code shows the following additional thoughts regarding Rules and Controls:
That being said, here are my thoughts:
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.
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.
I think the evolution could look something like this:
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. ??
@accumodel for two rules with the same priority value, the rule that appears first is given the higher priority - see remark 3 here.
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:
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:
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.
closing as stale. also rules are not the same as controls. who knew!!
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".