Valve statuses (and how they're set)

[jamesuber]

This may be larger than TCVs but it's easier to limit comments to that case, so I'll do that.

Say you have a TCV that is, say, 25% open, and you give it a loss coefficient to reflect that of, say, 200. That's in the valve section.

Now you give that same valve an initial status of OPEN or CLOSED in the [STATUS] data section. That overrides the valve setting in the [VALVES] section. I have found this to be confusing. It seems more secure to have one and only one place where something important like a valve setting is specified.

Maybe the problem is more basic and related to how things are parameterized. Does it make sense for something like a TCV with a relationship between fraction open and loss coefficient, to be assigned a setting of OPEN or CLOSED?

Bottom line is that valve settings are really important and it should be intuitive how they are parameterized and how their behavior is specified.

[samhatchett]

This should probably be filed under "works as advertised but should be changed anyway".

Stated in the holy scriptures, Remarks on the [STATUS] model file section:

1. Links not listed in this section have a default status of OPEN (for pipes and pumps) or ACTIVE (for valves).
2. The status value can be OPEN or CLOSED. For control valves (e.g., PRVs, FCVs, etc.) this means that the valve is either fully opened or closed, not active at its control setting.
3. The setting value can be a speed setting for pumps or valve setting for valves.
4. The initial status of pipes can also be set in the [PIPES] section.
5. Check valves cannot have their status be preset.
6. Use [CONTROLS] or [RULES] to change status or setting at some future point in the simulation.
7. If a CLOSED or OPEN control valve is to become ACTIVE again, then its pressure or flow setting must be specified in the control or rule that re-activates it.

... from this we are to conclude that yes, if you give a valve a default setting where the valve is defined, and then give that same valve an OPEN setting in the [STATUS] section, then it will be forevermore fully open with no memory of the original setting, unless there's a rule or control that says otherwise. Furthermore, if any rule or control modifies a valve's setting, then the old value will not be remembered.

Now, having understood that this behavior is documented in a roundabout way, one could rightly say that this is not intuitive. Would you ever want a valve to be fully open by saying "OPEN", or would you be expected to adjust the setting of the valve to be functionally open (as in for an FCV, reallyreallybignumber)? Or on the other hand, if a valve has 2 mutually exclusive settings (one in [VALVES] and one in [STATUS], then maybe a console warning would suffice?

[jamesuber]

Me too.

I’ve interacted with folks from GCWW on this particular issue. I think it’s useful to document the following snippets from that discussion here.

—

from me to Haishan Piao:

...It has seemed to us that the way Epanet does this is confusing. Even ignoring controls and rules, you can set a valve initial setting in the VALVES data section as well as in the STATUS section. Then you can also set the initial open/closed status in the STATUS section, which then adjusts the setting. And then normal pipes can have their status set in the PIPES section, but also in the STATUS section. All of this ends up generating questions about what the real setting or status really is. Unfortunately it seems that instead of rectifying this problem, other software makers have tended to mimic the Epanet approach when they designed their databases and UIs.

This is a peripheral to our work together, but some point I’d be interested in your take on a suggestion for how to manage this valve setting/status business a little better. We may eventually translate this sort of recommendation into the Epanet software, but it might also help us to work more efficiently with utilities. It would boil down to two rules for internal model building:

1. Initial valve operation is specified using only the settings attribute table; no valve is assigned an open/closed status or a setting elsewhere.
2. All pipes are initially open in the pipes table; any pipes that are closed are marked as such in the separate status section.

The rationale for both of these is to make it more straightforward and reliable to figure out what is going on. We could look only to the valve attributes to know the settings, and only to the status attributes to know all the pipes that are closed. It’s a little inconvenient to not be able to mark a valve as open/closed, but in reality the software translates that into a setting anyway. And, nobody really “closes” a PRV, they set its downstream pressure accordingly.

partial response:

… Sometimes the way the modeling software handles controls/settings is very confusing, and the users cannot confirm it until they actually try it and see the results. So, if you can make improvement in the software for this aspects, it will be great, and we can definitely provide some suggestions from the user’s perspective.

http://www.citilogics.com/ JIM UBER mailto:jim@citilogics.com • 513.368.6303 tel:513-368-6303 • CITILOGICS.COM http://www.citilogics.com/

On Jan 2, 2015, at 11:18 AM, Michael Tryby notifications@github.com wrote:

I agree with Sam. Issuing a warning while processing the input file is a good place to start while we search for a more general solution to the problem.

—
Reply to this email directly or view it on GitHub #1 (comment).

[eladsal]

Only 10 years have gone by; what about this ticket? Got lost with all these mentions
@jamesuber @samhatchett @LRossman

[LRossman]

I say keep it open for future consideration. No one has suggested a concrete way to make the distinction between Status and Setting less confusing. And if one was adopted it would likely break backwards compatibility.