Hi,
I am using Hammer for sizing appropriate air/vacuum breaker valves along a gravity water transmission pipeline to protect against downsurge events.
There are a number of scenarios I plan to confirm that our design provides adequate surge/downsurge (primarily downsurge) protection for, but want to get model working properly before delving into more scenarios.
Here's some baseline information about the scenario I'm trying to design (down)surge protection for:
Hopefully it will post well enough to see, but below is a snapshot of profile created from this 'sudden valve opening' scenario. :
The above shows negative pressure reaching vapor pressure (-11.4psi) and cavitating occurring (as expected) in the initial portion of the pipeline, closer in elevation to the upstream tank. It makes sense to me that this would be the case with a 1 second valve open at end of line, and no other protections in place. FYI, upsurge is not a concern on this one based on all scenarios run so far, as the upsurge reliably remains under even the regular working pressure rating of the DR18 PVC pipe (235psi).
Scenario with double acting air valves as surge protection:
Besides controlling valve open/close speed wherever possible, the obvious solution seems to be to add vacuum breakers along the line - most importantly at the start of the line. For simplicity, I simply applied a 3" diameter Outlet Orifice and 0.25" Inlet Orifice to all of the air valves designed along the line. We designed pipeline with air valves at all high points and at least every +/- 1/4 mile. Results are as follows:
Actually providing an orifice diameter for the air valves did have an effect, as the min. pressure was brought up to zero at all of the air valves (when I look at results node by node). I also see that the volume of air in line spikes higher (intuitively seems right to me for when a vacuum breaker opens). What doesn't seem appropriate to me is that the pipeline still gets to -11.4psi vapor pressure at many of the nodes between air valves. This is despite there being 5 air valves in first mile of pipe, and typically 3-4 per mile thereafter.
Questions:
Is there some other setting I should look to adjust that may be preventing the benefits of the vacuum breakers from extending to neighboring nodes realistically?
Or, do these results even with air valve protection seem reasonable? (We've designed plenty of other pipelines, but are just getting into doing own transients work, but from experience, we expect that appropriately sized vacuum breakers should be adequate for this project. )
Another possibility is that assuming 1-second fail to open for a control valve is extreme - and not worth designing for.
I can send or upload model to Bentley if it helps.
Thanks in advance for feedback.
-Ryan
Hello Ryan,
Air valves will only offer protection right at the location of the air valve, so it is not unusual to see vapor formation in other locations where there is no air valve. The following wiki goes into detail on the assumptions involved with tracking air or vapor pockets in HAMMER: Assumptions and limitations of tracking air or vapor pockets in HAMMER. The Extended CAV option you are using for the air valves will allow limited tracking of the air pockets, but only if the air valves are in line with the rest of the pipe network and if the air valve elevation is higher than the nodes on either side of it. The link above has further information on this feature.
You can find additional information on air valves at this link: Modeling reference - Air Valves. Details on using vacuum breakers can be found here as well.
Regards,
Scott
Thanks for this answer. I came to more or less same conclusion before reading your reply. It makes sense that a vacuum breaker can't help unless downsurge wave intercepts the vacuum breaker. In my model, the wave was intercepting pipe/ground elevation in multiple places before getting to the air valves at high points.
This said, below is a screenshot of an adjusted version of the model. Note a large difference is that I assumed a higher water level/HGL at the storage tank in end of line. Unrestricted flow to ground elevation as I showed in initial post is possible but very unlikely for this system. The below is a more plausible scenario.
I still am concerned that the model may be overestimating the downsurge, and therefore and am looking for other issues in my setup.
I've noticed that even when allowed time to equilibrate after the TCV is opened, the HGL seems to settle on the black line below. This makes no sense to me, as the pipe diameter and C-factor are constant and there are no demands or branch inflows, outflows along this profile (constant flow at this point), yet, the HGL shows clear breaks in slope - with no headloss as water flows through the middle portion of the line.
Is this just a display issue, or might it be indicative of an actual issue with the model that could be affecting the min/max pressure envelope?
Thanks in advance for the feedback. I believe I've seen this before for different projects, but in WaterCAD (possibly EPS, not running hammer). I
This may be a combination of a few things. First, your initial conditions calculation has a "Network unbalanced" message. Because of this, your starting point for the transient run may not be accurate. This link has information on this. I noticed that setting the Steady State/EPS calculation options property fields Trials to 4000 and Accuracy to 0.01 gave some better results.
The other thing that may be impacting this is that most of the TCVs in the system have a headloss coefficients of zero. This may yield discharge coefficients that are inaccurate and could impact the results. Notice that the calculated discharge coefficient is infinity when the headloss coefficient is zero. So setting an accurate value for the initial headloss coefficient or the initial discharge coefficient may improve the results as well.
Thanks Scott for the recommendations and for taking a look at the model I uploaded. I've made a number of changes and am feeling more confident in the results. For the benefit of others who are rookies at this like me, despite being terrible at the nomenclature, I'll attempt to describe what I've done. Please correct if any of these are clearly bad ideas/solutions.
1) Increased trials to 4000, accuracy to 0.01. For me, this did not allow initial conditions to balance, but in first transients run, the HGL did appear more plausible once reaching what should have been steady state (but definitely not correct yet).
2) Added 0.39 initial headloss coefficients (from library) for fully open Gate Valves to the TCVs in question. This actually made the transients results really wild (which it should not - these shouldn't have even been noticeable as minor losses relative to the overall profile during steady state flow). However, it made it even more clear to me that the transients solver obviously wasn't able to calculate steady state hydraulics effectively after the transients event correctly because of something else I had wrong.
3) I decided to take the time to set up a scenario with the Operating Rule for the TCV (in real life will be an altitude valve at end of line) I've been focusing on as follows:
a) Intial condition - flowing
b) Fast close (2 second failure close)
c) wait 80 seconds for steady state to get past transients and approach stead state static conditions
d) Fast open (2 second failure open)
The result was that I got to start with a balanced model for initial conditions. The initial conditions also showed a nice (realistic) linear HGL slope for flowing conditions. When I Computed/Ran the transients solver, it all looked reasonable. The scenario animation ran through the valve closing, approach to steady state (static), valve reopening, and approach to steady state (flowing) conditions without displaying any clearly impossible steady state hydraulics. Below is a screenshot. NOTE - the air valves are not in operation in the (unprotected) scenario below, so the more extensive vacuum ocurring on the left side of alignment is to be expected (in my opinion).
In the screenshot below is taken just before the second transient event (fast valve open) occurs, so you can see the angled black line (initial conditions) makes sense for steady state flow. The nearly horizontal (there is still a small transients wave bouncing back and forth) makes sense for the system nearing conditions before the subsequent valve opening that produces downsurge.
The only downside of the solution above, is that it takes much longer to compute the results for both closing and opening a valve, and time to approach steady state in between.
I also found the Flow Tolerance setting in the Transient solver calculation options. As this adjustment seemed like it might make it easier to get meaningful solutions when dealing with scenarios considering Static (No Flow) conditions, I adjusted this value from the default 0gpm to 0.5 GPM. (It's a transmission line, I have no interest in anything happening at 1gpm flowrates - no residential demands, etc.).
I reran the above scenario to close and open the valve, confirming it didn't wildy change results.
Then, I reran my previous scenario that starts from Static as the initial condition. The below is the result:
This scenario DOES have air valves, so the fact that the downsurge is improved compared to the above is impertinent.
However, despite starting with Static (and 'Unbalanced') initial conditions, at the time I pulled this screenshot, you can see that the steady state flow has come to a plausible and realistic slope.
I seem to have greatly improved the quality of results, unfortunately, I didn't re compute after every adjustment, so I can't be sure what change or changes really made the difference.
I realize none of these changes guarantees that my model is providing accurate results, but I'm getting more comfortable with it, and plan to do some sensitivity analysis next regarding my inputs and assumptions for things like wave speed and C-factor.
I also need to address the warning that "wavespeed or length approximations deviate excessively from the entered values".
On the wavespeed / length issue, this seems consistently tough to deal with, given that we design our projects with isolation valves, air valves, and control valves all within 20 ft of another. My plan is to compute with some varying (mostly shorter) timesteps to see if issue is eliminated (or results even affected). If that doesn't work, I can strip down the model to eliminate short pipe lengths, just to confirm the results of my more complicated version of the model (which I still need to evaluate operation of valves along the line in specific scenarios).
Thanks again for the help. Further feedback welcome, but I realize I don't have a specific question in here.
Ryan
Hi Ryan,
It sounds like you are on the right track. Here are a few general comments and tips based on your previous reply:
WaterRMB said:However, despite starting with Static (and 'Unbalanced') initial conditions, at the time I pulled this screenshot, you can see that the steady state flow has come to a plausible and realistic slope.
In some cases, the initial conditions results may be "OK-enough" even when you see "network unbalanced", but at other times, unbalanced initial conditions can produce greatly skewed results and greatly impact the transient simulation. I think the take-away is that unbalanced models can be very sensitive and results should not be trusted. The article Scott linked to in his previous reply, as well as the article in this link can help you determine the root cause of the unstable model results, to help give you confidence that when you have resolved those issues the transient results will not be negatively influenced.
WaterRMB said:I also need to address the warning that "wavespeed or length approximations deviate excessively from the entered values".
This is indeed a common concern, as many models tend to include very short pipes. I agree with your plan to eliminate them where possible - you can use Skelebrator for example to help with this, but make sure you do not remove nodes at critical elevation changes such as high points. Doing so may skew the results if the pressure would have otherwise fallen below the vapor pressure limit at that node elevation, causing a vapor pocket to form. Using a smaller timestep will indeed help, though there is often a balance between accuracy and performance (run time). You may want to do a test run with a transient event using a very small timestep, then compare to another scenario with the original timestep. If the transient results of interest are not significantly different, then you could consider accepting the length or wavespeed adjustments. You can read more about this along with other tips in the following article: Understanding length/wave speed adjustments and their impact on results
Jesse DringoliTechnical Support Manager, OpenFlowsBentley Communities Site AdministratorBentley Systems, Inc.
Thanks for the additional feedback.
Static (and 'Unbalanced') initial conditions
I'll try to find the cause of the unbalanced conditions based on your and Scott's comments. Thank you for the extra info. I
wavespeed or length approximations deviate excessively from the entered values".
On this second one, just reporting back that my sensitivity analysis worked out pretty well. Despite adjusting length of some very short pipes (17ft) by 100% (in scenarios where the error messsage pops up), halving the timestep (which in some scenarios also got rid of the error message) did not have any significant impact on the results.
I also did sensitivity analysis with C factor and wavespeed, as I could make the case to vary these a bit depending on assumptions about the pipeline, etc. Results were similar, in that the overall outcome didn't change given my range of values, however, I was able to identify what combination was most conservative with regards to where negative pressures begin to occur along the pipeline for a given transient event.
sincerely,
Jesse or Scott,
So I've looked into what is triggering and what can eliminate my 'unbalanced' initial conditions further.
As my initial conditions are intended to be Static/No Flow, the symptom seems appears to be minimal trace flowrates (+/-0.027 GPM for example) that should not really be present, that 'dissapear' as moving along the pipeline.
I've seen this before often enough. I found two ways to eliminate it:
1) Decrease Accuracy (increase value) in Steady State/EPS Solver / Hydraulics settings even further, from 0.01 to 0.07. (I gradually increased the Accuracy value until the model balanced). I noted that once the model balances, the trace flows no longer show up, I would guess because the solver treats those same flows as Zero once the accuracy tolerance is adequately increased.
2) Increase minimum water level in upstream tank (I already had a few feet of water in tank) from 3ft of water depth within tank to 11ft of depth. This decreased those 'trace' flowrates from +/--.027GPM down to +/-0.005GPM.
a. After getting the 'trace' flowrate lower, the model was still imbalanced, however, then I was able to make it balance by only increasing the Accuracy value from 0.01 to 0.02.
Questions/concerns:
1) Am I correct that using an Accuracy setting of 0.07 is similar to allowing +/- 7% error? This seems like a lot.
2) Since this is for Hammer analysis though, is the Steady State solver used for anything other than initial conditions?
If only used for initial conditions, I'm guessing the 0.07 of what is really 0 GPM is OK, as my settings fro the Transient solver take over after that.
3) I don't really consider adding 8ft more of water within a 32 ft tall tank a good solution just to get model to balance (we're evaluating worst case scenarios, so assuming tanks start close to empty in this case (resulting in lower starting pressures along line) may be more important than simply forcing the model to balance.
Here again, I'm guessing some simple sensitivity analysis would be adequate: Are Hammer HGL envelopes essentially the same but moved 'up' or 'down' +/-8ft of HGL depending on the initial water level assumed? IF YES, I could probably 'rely' on the results that start with unbalanced initial conditions, rather than use the slightly better looking results that started 'balanced' but assumed too high of a water level.
Thoughts on this?
1. Accuracy is the convergence criterion used to signal that a solution has been found to the nonlinear equations that govern the network hydraulics. The trials end when the sum of all the flow changes divided by the sum of all link flows is less than this number. A value of 0.07 is relatively large. A smaller value would mean the results are more accurate.
2. The Steady State solver is only used for the initial conditions calculation. However, it is important the results are accurate as this is the starting point for the transient analysis.
3. It is a good idea to try a sensitivity analysis if there is question about the input, and the initial conditions could count as that for a transient run.
However, another option may be start with the TCV open, close it, then reopen it. This is a similar workflow to pump operations found in this link. The reason for suggesting this is that you are less likely to need to worry about bad data in the initial conditions.
Answer Verified By: WaterRMB
Thanks Scott,
Your and Jesse's feedback has been very helpful.
As you suggest in this last comment, I have done some runs with valve starting open, then closed, then open again - to eliminate the initially unbalanced conditions without having to really reduce accuracy requirements. The transients results were consistent with my other runs that started from a closed valve position, so I'll go that route where needed to obtain (or at least confirm) the results of transients events that need to have a valve close.
Thanks for allowing me to ask multiple questions through this thread. I have another question on the same model/project, but I'll start a new thread as I'd consider it a separate topic.