Position valves - Githubissues

jamesuber commented 9 years ago

I think it's pretty common to have valves that have their degree of opening remotely controlled. This seems to be hard to do in Epanet.

This calls for a TCV where the minor loss coefficient can change. You can do that through controlling the valve setting, but that requires you to deal directly with the minor loss which is a hassle and is going to be error prone and hard to maintain.

A first requirement seems like the ability to associate the minor loss versus percent open curve with a valve. Note the GPV associates a flow versus head loss curve which itself would be a function of the valve degree of opening, so that's not really an option.

then it would be useful to have the setting be the percent opening, which is easy to interpret and how the operation of these valves are described.

Finally, the percent opening could be used in a control/rule action clause.

eladsal commented 9 years ago

This is needed among other things. Currently we can simulate this with a TCV and control rules but it would be better to have it as a separate kind of valve. Patterns for valves (and pipes) are also much needed.

lbutler commented 2 years ago

I'm interested in seeing this functionality in EPANET and it is a feature that Qatium has identified as one it could provide development funding if required.

My thoughts are you could achieve this with a TCV with a curve associated which represents the percentage open vs headloss coefficient.

I would suggest one way to add this functionality would be to use a similar format as pumps with keyword & value combinations - this would allow for the later addition of patterns.

For example, the below would have an associated curve called plugvalve with a setting of 15% open and the headloss coefficient would be found by looking up its value. The pattern parameter would change the setting depending on time but is outside the scope of this issue.

[VALVES]
;ID Node1   Node2   Dia Type    Setting M/loss  Parameters
VALVE1  J001    J002    350 TCV 15  0   CURVE plugvalve PATTERN tankinlet

Some open questions I still see on this issue:

Do we create a new valve type, or do we use the TCV?
How do we associate the curve, is it required or optional, or do we use parameters like pumps?
When a value is set between those in the curve, do we use linear or logarithmic interpolation?
If you use a rule or control to set a value past the curve, do we throw an error or a warning?

eladsal commented 2 years ago

Thank you, @lbutler . Let me see if I understand. If we go with the TCV option, to keep backward compatibility, if no curve keyword is present, the setting will be the regular loss coefficient. If there is a curve keyword, then the setting is degree open. In both cases, the pattern will be a multiplier for the setting value. Is that right? and pattern will be allowed for all valves (maybe not GPV where the setting is a curve).

@LRossman, was there a reason for not including patterns for valves?

LRossman commented 2 years ago

@eladsal I don't think there was any particular reason for not adding patterns for valve settings other than it didn't seem to be of high priority. I question how common it is to adjust valves with a constant time interval time pattern. As mentioned above, intermittent valve adjustment can always be done using controls.

I'm also not sure why we need to add a valve setting curve to the code. Since users would have to enter the curve's x-y values into their model, wouldn't it be just as efficient for them to enter only the valve loss coefficients just for the specific set of percent openings they need. By analogy, should we be adding tables of roughness coefficients based on pipe material as well? It seems such model building aids are better left for GUI's.

But having said that, I went ahead and implemented degree of opening curves for TCVs in a new dev-tcv-curvebranch. It uses the following format for TCVs in the input file:

[VALVES]
;ID Node1   Node2   Dia Type    Setting M/loss  Curve
VALVE1  J001    J002    350 TCV 0.15    0   plugvalve

where the setting is the fraction that the valve is open (less prone to getting unexpected results if a user mixes up percent open with fraction open). If no Curve name is entered then the setting is interpreted as the loss coefficient. A Valve Curve has x-values of fraction opened and y-values of valve loss coefficient. The API functions EN_getlinkvalueand EN_setlinkvaluecan get and set the Valve Curve assigned to a TCV by using the new EN_TCV_CURVEproperty. We can discuss if it's worthwhile or not to merge this new feature into the devbranch.

eladsal commented 2 years ago

Thank you @LRossman!

A valve open curve is a property of the valve (provided by the manufacturer) similar to a pump curve, and the degree is an operational decision. I don't think it is the same as the roughness coefficients, which is a static property. Furthermore, the open degree is much more intuitive for the user than the loss coefficient. I think your new branch would be very welcome!

You are right that valve setting changes at predefined time intervals are less common, and their setting can be changed by control rules. However, I think patterns are more convenient for users. I have seen many implementations in which all data is aligned to relatively short time intervals (e.g., 5 minutes), and patterns are used where possible. Preparing data for patterns is simple by using spreadsheets and importing them to EPANET. Also, patterns are more componential efficient than control rules, right?

lbutler commented 2 years ago

Thanks as well @LRossman

I'm seconding the comments by @eladsal and @jamesuber - having the percent open is much more intuitive and Elad makes a good point on the comparison between the curve being a property of the valve while the setting is an operational decision.

Assuming you have the correct curve, or one that has been calibrated, it would be much simpler to represent an automated mechanical valve with either controls or maybe eventually a pattern inside EPANET. You could take the values of percent open from SCADA and apply them directly into EPANET, without having to do the lookup manually. When looking at alternative scenarios, such as changing the operations of the valve, the opposite would be true and taking the learnings from the model could be applied to the control system.

As for patterns on valves, the most common scenario I see is PRVs where they have multiple set points depending on the time of day, usually lower overnight to reduce background leakage. The other use case I see is during calibration, some engineers will force all control assets to run on time based controls to force boundary conditions, if you had patterns it would be much simple to set certain values as as mechanical valves or PRV to operate exactly as there were and swap out multiple calibration days before setting up dynamic controls.

It is true that these either of these scenarios could be done with controls instead of patterns, so I don't see it as high of a priority but could be helpful under certain use cases.

LRossman commented 2 years ago

Thanks for the feedback. It seems that the consensus is to proceed with adding the use of positional valve curves to the program. However, after coding this addition I now have a concern that by allowing the TCV "setting" to mean two different things, depending on whether a valve curve is used or not, could cause confusion and probably violates good programming practice.

As an alternative I propose we keep the original TCV valve as is and instead add a new type of valve called a Positional Control Valve (PCV). It's input format would be the same as the TCV except that the "setting" would always be a fraction open and the name of a positional curve would always be required as the last item on the line. For the toolkit, setting and retrieving a PCV's curve would be done using the EN_PCV_CURVE property. Implementing this approach would only require modest changes to the code I posted. Can I get a thumbs up on this?

jamesuber commented 2 years ago

I like it; think it’s a useful addition primarily cause it lets the modeler incorporate these common valve characteristics into the model db, and not have to maintain those separately outside of it. Thanks! Jim

Jim Uber, Ph.D. Drinking Water Network Optimization

Xylem - Digital Solutions

@.**@.>

M: 513.368.6303

From: Lew Rossman @.> Sent: Thursday, July 28, 2022 10:58:25 AM To: OpenWaterAnalytics/EPANET @.> Cc: Uber, James - Xylem @.>; Mention @.> Subject: Re: [OpenWaterAnalytics/EPANET] Position valves (#18)

Thanks for the feedback. It seems that the consensus is to proceed with adding the use of positional valve curves to the program. However, after coding this addition I now have a concern that by allowing the TCV "setting" to mean two different things, depending on whether a valve curve is used or not, could cause confusion and probably violates good programming practice.

As an alternative I propose we keep the original TCV valve as is and instead add a new type of valve called a Positional Control Valve (PCV). It's input format would be the same as the TCV except that the "setting" would always be a fraction open and the name of a positional curve would always be required as the last item on the line. For the toolkit, setting and retrieving a PCV's curve would be done using the EN_PCV_CURVE property. Implementing this approach would only require modest changes to the code I posted. Can I get a thumbs up on this?

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/OpenWaterAnalytics/EPANET/issues/18*issuecomment-1198264665__;Iw!!OKzgfr8!boVZTE2O9LKTu-xgMX2olPRHesKQqG4A_HceLmWFssLEzSiTMjrq6sMgGtCkGfLW1U_0ByO5HUbE9fRFl9krPB83m8o$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AASMACLI42S3YHQRX4QS5CDVWKNZDANCNFSM4BISHX6Q__;!!OKzgfr8!boVZTE2O9LKTu-xgMX2olPRHesKQqG4A_HceLmWFssLEzSiTMjrq6sMgGtCkGfLW1U_0ByO5HUbE9fRFl9kr5ucHcsU$. You are receiving this because you were mentioned.Message ID: @.***>

samhatchett commented 2 years ago

i like it too. 👍

LRossman commented 2 years ago

The dev-tcv-curve branch has been replaced by the dev-Positional-Control-Valve branch that implements a PCV type valve. The input file format for this new type of valve is:

[VALVES]
;ID Node1   Node2   Dia Type    Setting M/loss  Curve
VALVE1  J001    J002    350 PCV 0.15    0   plugvalve

where Setting is valve's fraction open and Curve is a positional curve (valve loss coefficient versus fraction open). Regarding the API, EN_PCVis the constant for its link type and EN_PCV_CURVEis the constant for its curve property. EN_VALVE_CURVE denotes a positional curve's type. If one fails to specify a positional curve for a PCV, either in the input file or using the API, then the valve defaults to behaving as being completely open regardless of what value was used for its setting.

An example of using the API with a PCV appears in the _testvalve.cpp unit test file (in the project's testsfolder).

Please review the code if you have the time -- all comments are welcome.

fmartine commented 2 years ago

The possibility of relating the dimensionless loss coefficient k of a valve to its position represents an important advance in relation to the types of components currently offered by the EPANET Toolkit for modelling reality. The Valencia (Spain) network has more than 40 valves operated by remote control, and in the construction of its Digital Twin, one of the pioneers in the world and operational for 15 years, we have always missed being able to impose the k of the valve from the position recorded by the SCADA.

However, if we want EPANET to evolve to come closer to engineering practice, working with the k coefficient is not the most appropriate. Its value ranges from 0 (or better ko) to infinity, and when plotting k versus the opening degree, it is observed in segments with very little sensitivity and others with great sensitivity. This is not good for calibration processes. Nor k is a parameter whose values can be easily intuited by any user.

Therefore, valve manufacturers do not usually give the value of k versus opening degree, but the value of the coefficient Cv versus opening degree. The valve coefficient Cv is defined as Cv = Q/ sqrt(hv), where Q is the flow rate and hv is the pressure drop. But Cv is unit-dependent, so when SI units are used it becomes Kv, being Kv (x) = 3.24 d^2/sqrt(k (x)), where k is the current EPANET dimensionless coefficient, d is the valve diameter and x is the degree of opening (0 closed, 1 open).

To avoid unit dependency, since all valves have losses when open, represented by the coefficients ko or Cv,o, valve manufacturers provide in their catalogues the value of Cv/Cv,o = Kv/Kvo as a function of the opening degree x (see figure). Note that Cv/Cv,o represents the fraction of flow that passes through the valve with respect to the maximum flow that would pass through in the open position, for a fixed pressure drop. These curves are smoother, have no singularities like the k (x) curve, and are easily interpretable. They are also much more suitable for calibration. Furthermore, Cv/Cv,o = Kv/Kvo = sqrt (ko/k).

Following L. Rossman's proposal, for the new PCV valves, the value of ko (mandatory) and the Cv/Cv,o curve could be requested, which users would read directly from the catalogue. By default, the ko value could be 1 (a loss equal to the kinetic energy), and the default curve could be a straight line at 45° (proportional valve), which in practice corresponds approximately to a globe valve. The calculation of the value of k for each position would be immediate since k = ko (Cv/Cv,o)^2. Requesting the value of Cv,o instead of ko is more complex, because it depends on units and other factors, and would be more complicated for users. Another option is to allow the user to enter the two types of curves Cv/Cv,o (x), smoother and taken from the catalogue, or k(x) more difficult to determine and with very abrupt value changes.

At the recent WDSA-CCWI 2022 conference, I proposed many improvements that could be introduced in the EPANET Toolkit, to gradually bring the simulation capabilities of a model born 25 years ago closer to reality, now that Digital Twins are booming. In the meantime, this approach has to be done from the GUI, considering the limitations of the current Toolkit. In this sense, at the IIAMA of the Polytechnic University of Valencia we are developing the QGISRed application as a QGIS plugin where, besides reproducing all the features of EPANET 2.2, we are introducing new components and properties (for now without modifying the Toolkit 2.2), that someday could be part of a more advanced version of the EPANET Toolkit.

LRossman commented 2 years ago

Hi Fernando. I agree with your suggestions and will modify the code for the PCV valve to use a Cv/Cvo curve from which a loss coefficient k can be computed as k = ko / (Cv/Cvo)^2 (note the correction to your formula). So the input format will now be:

[VALVES]
;ID Node1   Node2   Dia Type    Setting M/loss  Curve
VALVE1  J001    J002    350 PCV 0.15    0.35    plugvalve

where the M/loss entry is the minor loss value ko for a fully open valve and the Curve entry is the name of the valve's Cv/Cvo curve. If ko is 0 then the valve is treated in the same manner as a completely open TCV with a 0 minor loss coefficient (to maintain consistency with the current code) and the fraction open setting has no effect. If no curve name is entered then a default linear Cv/Cvo curve is used. When a very small setting (such as 0) is used, the k value is limited to the value the program currently uses to model a completely closed link.

Thanks for improving the way that the new PCV will be modeled.

eladsal commented 2 years ago

Good idea @fmartine, can you please give some examples of these curves and ko values? I think different manufacturers have different versions of these curves. Here are a few: WW_700-Large-Sizes_Engineering_English.pdf 872-00-004_19_10_21_AVKCMS_EN.pdf 870-0001-001_AVKCMS_EN 2223.pdf

eladsal commented 2 years ago

There were some errors with my attachments on the previous comment. I have fixed them now.

LRossman commented 2 years ago

@eladsal the first two examples provide the Cv/Cvo curves directly (although the first one has the axes reversed). The third one is an example plotting the partially opened k-value directly (like we originally wanted to do), and a user would have to convert points off the curve to the Cv/Cvo format using the formula listed previously to provide the proper input to EPANET.

The literature is full of values for ko, just Google "minor loss coefficient table". If the valve manufacturer provides a value for Cvo then the following formula will convert it to a ko:

ko = Cf *(D^4) / (Cvo)^2

where D is valve diameter in inches and Cf = 880 for Cvo in US units or 1.22 if it's in SI units.

jamesuber commented 2 years ago

I could be misremembering but I think that most manufacturers provide the Cv data, but I’ve had to sometimes hunt for the k value curves. In other words I believe the user will usually find either just Cv, or both.

BTW I’ve found this to be confusing in the past, and frankly didn’t have a huge appetite to dig in and really understand the relationships. So I think it’s nice that Epanet points me in a particular direction.

From: Lew Rossman @.> Date: Monday, August 1, 2022 at 12:51 PM To: OpenWaterAnalytics/EPANET @.> Cc: Uber, James - Xylem @.>, Mention @.> Subject: Re: [OpenWaterAnalytics/EPANET] Position valves (#18)

@eladsalhttps://urldefense.com/v3/__https:/github.com/eladsal__;!!OKzgfr8!bZZ3aT01f3Mq3fGaSytYEMDkA_fbmi1YgPWpXmXkL9QIjn3Q3d_e8qObjT5NM8e--iok4xMEyTcuk4WRautWkFYRJJ4$ the first two examples provide the Cv/Cvo curves directly (although the first one has the axes reversed). The third one is an example plotting the partially opened k-value directly (like we originally wanted to do), and a user would have to convert points off the curve to the Cv/Cvo format using the formula listed previously to provide the proper input to EPANET.

The literature is full of values for ko, just Google "minor loss coefficient table". If the valve manufacturer provides a value for Cvo then the following formula will convert it to a ko:

ko = Cf *(D^4) / (Cvo)^2

where D is valve diameter in inches and Cf = 880 for Cvo in US units or 1.22 if it's in SI units.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/OpenWaterAnalytics/EPANET/issues/18*issuecomment-1201459661__;Iw!!OKzgfr8!bZZ3aT01f3Mq3fGaSytYEMDkA_fbmi1YgPWpXmXkL9QIjn3Q3d_e8qObjT5NM8e--iok4xMEyTcuk4WRautW3Mci8RY$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AASMACJ66PITVOLG3PYA5JTVW7573ANCNFSM4BISHX6Q__;!!OKzgfr8!bZZ3aT01f3Mq3fGaSytYEMDkA_fbmi1YgPWpXmXkL9QIjn3Q3d_e8qObjT5NM8e--iok4xMEyTcuk4WRautWg7Cj_gA$. You are receiving this because you were mentioned.Message ID: @.***>

eladsal commented 2 years ago

Thank you @LRossman . Just to make sure, will we have the opening fraction on the x-axis of the curve or as on Fernando's sample figure?

LRossman commented 2 years ago

@eladsal since fraction open is the independent variable I think it should be on the X-axis.

To illustrate how a valve characteristic curve can be generated from a table of minor loss coefficients, consider the following table for a Gate Valve taken from "Analysis of Flow in Water Distribution Networks" by P.R. Bhave:

Fraction Open	Loss Coeff.	Cv / Cvo
1.0	0.19	1.0
0.75	1.15	0.41
0.5	5.6	0.18
0.25	24	0.09

The Cv/Cvo column was derived using the formula Cv/Cvo = 1 / sqrt(k / ko) and the resulting characteristic curve is:

Here's another representation of conceptual valve characteristic curves I pulled off the web:

eladsal commented 2 years ago

And in this example, ko=0.19 corresponds to a fully opened valve. Such examples should go into the documentation.

fmartine commented 2 years ago

Thank you @LRossman for accepting my proposal, in order to bring EPANET little by little closer to the real world of engineering. There was indeed a small error in expressing k/ko versus Cv/Cv,o, but the ratio indicated in the first place was correct.

The advantage of requesting a dimensionless ko value is the non-dependence of the units, and as @LRossman says, many ko values can be found in the literature, ranging between 1 and 5.0. But if the user wants to take values from the manufacturers, he can get all the necessary information from the data offered in the catalogues, which are consistent with the different manufacturers provided by @eladsal, as I will justify.

Let's go first to maths, and for that, I will use SI units because I am not familiar with US units. The academic model used to express losses in a valve is hv (m) = k v^2/2g = k 8/pi^2/g /d(m)^4 * Q(m3/s)^2, with g = 9.81 m/s2, and k dimensionless. However, the model used by manufacturers is Q(m3/h) = Kv sqrt (hv (bar)), where the value of Kv depends in this case on the units.

Solving the first expression for Q, converting units (1 bar = 10 m) and comparing we obtain: Kv = 3600 pi sqrt(10 g/9.81) d(m)^2 /sqrt(k) = 39604.2 d(m)^2/ sqrt(k) = 0.0396 d(mm)^2/sqrt(k). Or conversely, k = 39604'2^2 d(m) ^4 / Kv^2 = 0.00157 d(mm)^4 /Kv^2.

On the other hand, both k and Kv depend on the degree of valve opening, with ko and Kv,o being the values corresponding to valve open (the minimum for k and the maximum for Kv, since they vary inversely). Therefore ko = Cf d^4 /Kv,o^2 as indicated by @LRossman, only that I disagree with the value of coefficient Cf given for SI units.

Let us now turn to the catalogues. Let's start with Bermad's 700 sigma series, initially proposed by Elad. On page 6 we have the Cv/Cvo (x) curve that EPANET would request (sometimes the axes are inverted). In the case of a flat disk, we would have an almost linear curve. Let's take the EN series and on page 6 at the end we have the values of Kv,o and ko (dimensionless) for different sizes. It can be seen that both fulfil the above relationships. In EPANET just the value of ko would be entered. If the manufacturer has not given us the value of ko, a plot of losses as a function of flow rate, for different sizes, is given on page 10 in a double logarithmic plot: log Q = log Kv,o + 0.5 log (hv). This diagram is provided by almost all manufacturers. For SI units, and the valve of d= 100 mm, we can read any point, e.g. hv = 1 bar, Q= 200 m3/h, so that Kv,o = 200 (flat disc) and ko = 3.9, in accordance with the values given on page 9 and with the above formulas.

The values of Cv and the losses in US units are given on the same pages, so @LRossman can check here the proposed formulas for these units

Let us now take the AVK catalogue for needle valves. Page 5 upper side gives the Cv/Cv,o (x) curve to be entered into EPANET. The graph on page 4 is the ratio k/ko (x) and you can check that Cv/Cvo = sqrt (ko/k), so this graph is redundant. Note also that a logarithmic scale has been used for the vertical axis, which greatly reduces the accuracy, so it is better to use the Cv/Cv,o plot. In this case, the manufacturer does not give us the value of Cv,o, but the graph of losses as a function of flow rate at open valve for different sizes. In the graph for DN100 we can read the passing point hv = 1 bar, Q = 200 m3/h, where Kv,o = 200 and ko = 3,9, the same values as for the Bermad valve.

Let us now consider the plunger valve from the same manufacturer. On page 3 it only gives us the k(x) curve, with a logarithmic scale on the vertical axis. From this curve, it reads directly ko = 1.6 for 100% opening. In this case, the manufacturer is offering the curve initially proposed by @jamesuber, but it is really very imprecise and difficult to take values from it because of the logarithmic scale. To get the new proposed curve it would be necessary to refer the values of k (x) to ko, and make the transformation Cv/Cvo = sqrt (ko/k). But this case is not very common.

Finally, let us consider the large Bermad valves. In this case the manufacturer gives the curve Cv/Cv,o (x), but does not give the values of Cv,o, nor of ko, although both can be easily deduced from the head loss versus flow curves. For example, for the MS valve, in SI units, we read the passing point hv =1 bar and Q = 5000 m3/h, so Kv,o = 5000. But the MS valve is manufactured in 5 sizes, and in the loss-flow graphs, the valve size is not indicated. This is an omission of the manufacturer, and in principle, the value of ko could not be calculated. If d = 500 mm, according to the formula it would be ko = 3.92; however if d = 800 mm it would be k = 25.70, a very high value. It is reasonable to think that it has represented the losses for the DN500 valve, and therefore ko = 3.92, a value that is repeated for this type of valve.

Remote control valves, for large diameters, are normally butterfly valves (or more modern plunger valves if they can be afforded). To complete the list of valves provided by @eladsal go to this link for butterfly valves where head loss vs flow curves and typical values of Cv,o and Kv,o for different sizes are given. For example, for 500 mm Kv,o = 11159 and ko = 0.79 , while for 1000 mm Kv,o = 53911 and ko = 0.54. As can be seen, the values of ko are quite stable for all types of valves, reducing their value as the valve size increases. A valve with a very high ko value would not be accepted in the market, because it dissipates too much energy in the open state, especially if the flow rate is high. As the flow rate increases, the ko values are reduced to limit the energy dissipated. The stability of ko and the ease of intuiting its values reinforce the proposal formulated to characterize the behaviour of PCVs.

fmartine commented 2 years ago

And regarding the calibration of valve behaviour from SCADA data, which @jamesuber is so concerned about, the use of Kv is simpler than using k, and its values are more stable. If you have measured the pressures upstream and downstream of the valve (be careful to make sure that the elevation of the two gauges is the same), and the flow rate passing through it, you will have Kv = Q / (Pup - Pdw). When calculating Kv, be careful to express Q in m3/h and hv = (Pup - Pdw) in bar. If the valve position is also measured, we already have a value of Kv(x).

In WDN pressures are not usually expressed in bar, but in mwc. However, the main research on the behaviour of valves comes from the world of Chemical Engineering, where they work with fluids of all kinds, mainly gases and steam, whose densities can vary greatly. They prefer to use the bar because it does not depend on the density of the fluid. It is also the unit mainly used by gauges. Hence we have to make a unit conversion first.

Once Kv(x) has been obtained for various valve positions, to reproduce its behaviour in EPANET, Kv,o must first be determined and the Kv (x)/Kv,o curve entered. But this measurement is the most inaccurate to obtain with SCADA data (manufacturers use test benches). In practice, it does not matter, as Kvo can have any value as long as it is consistent. Just enter in EPANET the value ko = 1 as it is the simplest, and calculate Kv,o = 0.0396 d(mm)^2, where d is the valve diameter in mm. When EPANET internally will calculate the Kv values using the value of ko = 1 and the Kv(x)/Kv,o curve thus dimensioned, the Kv(x) values obtained with the field measurements will be reproduced.

OpenWaterAnalytics / EPANET

Position valves #18