Implement shutoff valve data structures

[tasseff]

See the Open Water Analytics definition of shutoff valves and EPANET's description of shutoff valves in Section 3.1. Note that shutoff and check valves are not considered to be [VALVES] but are instead parts of [PIPES]. Although this does not appear to be documented, as far as I can tell, pipe objects with empty status flags should be considered shutoff valves. A :shutoff_valve key within ref should be constructed to easily filter links that are pipes with shutoff valves. Since [PIPES] objects are already parsed in src/io/epanet.jl, implementing these data structures should be easy.

[tasseff]

The above assumption that [PIPES] objects with empty status flags contain shutoff valves was incorrect. Instead, pipes with open or closed statuses denote the initial conditions of shutoff valves in the pipe. In the [CONTROLS] section of an EPANET file, there are statements that describe temporal changes to a pipe's status (i.e., from open to closed or vice versa). Thus, if a pipe ID appears in the [CONTROLS] section, for the time being, it will be assumed to contain a shutoff valve. Otherwise, it will be assumed that the pipe does not contain a shutoff valve. Another possibility is that we assume all pipes with initial open or closed statuses contain shutoff valves. However, this could have negative implications for optimization formulations (e.g., the introduction of many, perhaps unnecessary, binary variables).

[tasseff]

Per our meeting, shutoff valves should exist at all pipes connected to tanks and all pipes referenced in the [CONTROLS] section.

[rb004f]

In gas models, the two types of valves we support (so far) are regulator (pressure reducing) valves and on/off valves and we model them as distinct edge objects, mainly so we didn't clutter pipe objects with extra fields that are often unused. Might be something to consider. There are pros and cons to both approaches. I think powermodels supports both... lines can act as simple switches, but can support more exotic separate breaker objects as well.

[tasseff]

That's a good point. Looking at the constraints, there's no reason why they shouldn't be distinct. (Check valves and shutoff valves should also be distinct from pipes, I think.)

[tasseff]

Clarification to my comment above (as per our meeting)! Pipes with valves should be decomposed as pipes and valves.

[tasseff]

Also, per our discussion, perhaps shutoff valves should not be included in all pipes connected to tanks. This could result in more binary variables introduced than necessary. Instead, as @enzoliuyang94 suggested:

1. An artificial node should be added to each tank node. This new node can be thought of as the actual point of water storage.
2. A zero-length pipe should connect the original tank node to the artificial node.
3. A binary variable should be added for each tank that permits or disallows flow into or out of the artificial node.
4. When the binary variable is one, the tank is connected to its adjacanet nodes, and flow can enter/exit.
5. When the binary variable is zero, the tank and its adjacent nodes are decoupled (i.e., the tank is disconnected from the system).

@enzoliuyang94, @jjstickel, is this an accurate summary? As I read over this: (1) I don't understand the purpose of creating an artificial node for a tank. Why not just have a binary variable for each of the original tanks that allows incoming/outgoing flow when equal to one and disallows it otherwise? (2) Should a single binary variable control whether a tank is decoupled from the network?

The more I think about this, I still don't see how this is as flexible as a system that includes shutoff valves for all pipes connected to tanks. Imagine a single tank connected to multiple nodes via pipes with shutoff valves: the ability to control where the tank will (or will not) send water will surely expand the set of feasible solutions, right? If we have just a single control for tanks (i.e., whether or not flow can enter/exit), then once the tank is open, water will be distributed everywhere according to the head loss relationships among connected nodes.

I guess I still don't have clarity as to what's the most realistic or best approach... Discussion is appreciated!

[tasseff]

I also recommend that we develop some interesting edge cases in #93.