ôQoutö greater than æQinö in ICPR 1

[xghalibx]

Folks:

I am modeling an elliptical pipe which is routing water from only one drainage basin. Both ends of the pipe are defined as nodes (i.e. upstream is a node and downstream is a node). When I run the model, the node min/max output shows that more Q is coming out than going in.

Can someone explain this to me? There’s only one drainage basin going in to this pipe. The difference between Qin and Qout is fairly significant (27 cfs vs. 54; 47 cfs vs. 74 cfs).

Thanks

 

[xghalibx]

BTW, the elliptical pipe is a culvert. Forgot to clarify that in the previous post. Thanks..

 

[cvg]

what kind of model?

 

[xghalibx]

Its a SCS Unit Hydrograph model in ICPR.

 

[lsp01]

Hi,

I have a couple of thoughts....

1. Remember that Q in cfs is a rate not a volume, what is the slope in the pipe?

2. Is the model valid? Have you checked the mass balance? You maybe losing water from your system.

3. Check the peak stage information at the junction nodes, I know that the older versions of ICPR often got unstable for longer pipe runs. The model was not really designed for pipe designs, but its terrific for pond modeling. The older program did not account for water storage in pipes.

If your peak stage in the junction nodes is unreasonable for the system, (e.g. several feet above the grate) change those nodes to stage-area with small areas in the box (say .001 acre) but allow for flooding at the grate (0.5-1.0 acres for 0.5 feet). The high heads can also cause other problems, since the system goes into pressure flow.

4. Check your loss coefficients at the junctions.

As I said earlier, I don't typically model long pipe runs with ICPR, the program was not intended for that use. Usually, I just model the pond for tailwater and use the FDOT (Florida Department of Transportation) Storm Water Tabulations. I know that other states have similar forms. They are usually based on the rational formula rather than unit hydrograph, but they've been used for decades for piped systems. There are also programs out there to model pipe systems, but I'm used to doing them by hand on spreadsheet. (Please don't say dinosaur.....)

Hope this rambling helps...

Let us know how it turns out.

LSP01

 

[TerryScan]

One other tip in troubleshooting any ICPR model is to do a run of only a minute or less. If it is a runoff model, no flow should occur. If there is flow, there is a flaw in the model setup. (wrong starting stage in node, wrong units, bad invert, etc.) This is the source of 90%+ of my errors in ICPR.

 

[xghalibx]

I am not exactly sure what is the function of Mass Balance in ICPR (kinda novice to ICPR program). But i did check the mass balance report. It showed negative percent error (i.e. inflow volume is less than outflow volume), which sometime was high as -52%. What does it exactly mean.

Ohh, TerryScan: Mass Balance showed no flow for the first hour. So the zero flow checks out..

 

[lsp01]

xghalibx,

The mass balance report indicates the model's stability. If you have large fluctuations in the mass balance, the model is unstable. Normally, there may be a small fluctuations in the first few iterations, but it should go to zero % error well before the end of the model run. If there is an error in the mass balance, then the corresponding flows are in error.

Did you check out the peak stages in the model? Whenever I have found a significant mass balance error, its almost always that the peak stage at a node is above the top stage specified. This generally means that you are "losing" water in the system due to flooding, and effecting the overall "mass-balance" for the system. The most common way to correct this is to keep the flooding within the system. See comment #3 of the last message, allow for an overflow area above the junction.

If the peak stages are held within the system and you are still unstable, you may want to adjust the model parameters. The documentation will indicate what ranges are typical for the calculations.

Just another thought..how big is your model? #nodes and/or links?

Good Luck!

LSP01

 

[LHA]

I am not familiar with ICPR, but most software packages use the Modified Puls routing algorithm. Remember that computer models cannot reason, they can only follow instructions.

Here is what HydroCAD says about this problem (I've paraphased), which by the way I have found to be very common in many software packages (TR-20 and VTPSUHM for example).

'The peak outflow of a pond or reach being greater than the peak inflow can occur if the storage is very small in relation to the inflow volume, or if there are abrupt changes in the stage-discharge curve or inflow hydrograph. Examine the hydrograph plot. In some cases this message may be triggered by normal routing conditions. If a visual inspection confirms the presence of routing problems, reduce the time increment (dt) until the situation is corrected. This may require a reduction to the minimum dt of 0.01 hours. If the problem persists, the available storage may be too small to permit an accurate routing.'

And, of course, if you are using a large outlet (say, topping a weir or spillway), the output will correctly read a net increase of outflow. Make sure you are not seeing a combination of pipe and weir flow in your outflow.

 

[xghalibx]

lsp01:

The total model is approx. 203 acres but this particular node models about 66 acres. The other numbers make sense but the differential Q's for this node just made me go bonkers.

I did what you told me about adjusting the time/stage areas and I think it did the trick. The % error is now 0. The flows are also balanced going in and out. The % error spikes to 9999 at the beginning of each rainfall event but I can understand the program getting a bit wacky with no flows.

Thanks alot for the help.

 

[xghalibx]

O.k.. Now there's another problem. The initial question was regarding the model for the pre-dveloped condition. Now as I run the model for the post-developed condition, I am getting mass balance error in the range of -18% (which seem too high).

Model: Part of the drainage area goes to detention pond 1 which is surrounded by residential lots. Other part goes to detention pond 2. Pond 1 & Pond 2 are separated by a road and are thus connected with a 30-inch equalizer pipe. While the equalizer pipe connects to Pond 2, it picks up additional runof from the road through a system of inlets. Pond 2 ultimately outlets to the adjacent stream. Pond 1, Pond 2 are modeld as nodes. The location where the inlets dump water into the equalizer pipe is also modeld as a node (named pond1/2). See Below for a lame diagram

Problem: System shows negative Q for node Pond 2 and node pond1/2. Now this makes sense since water rising in Pond 2 will flow back towards pond 1. But the Neqative Q shown for Pond 1 is significantly less than the negative Q for Pond 2 and Pond1/2. In other words, not all of the water leaving Pond 2 is making it back into Pond 1, though it makes it back to node Pond1/2 (as the nagative Q's match).

Anyone care to shed light on this?!? Should I not model the inlets as nodes the way I have done here?? If no then how would I model the runoff from the street as it dumps into the equalizer pipe. Thanks..




30-inch equalizer Pipe
Basin 1 --> Pond 1 (node) ---------->Inlets (node) ----------->Pond 2 (node)------> Outfall
Basin 2^^

 

[lsp01]

xghalibx,

I believe that you've run into one of ICPR's limitations, the program does not model pipe runs very well, unless they act as equilizers.

You will get more reasonable results if you remove the pipe system from the model and add the pipe system drainage area to the closest pond (Pond 2?). Use stormwater tabulations or a piping program to calculate the HGL in the pipe system using the peak stage in the pond as the tailwater.

Use the storm event appropriate for your area, locally the ponds are sized for a 25-yr/24- hr event and the street piping systems are sized for a mean annual storm event, but that changes with location.

Good luck,

 

[TerryScan]

xghalibx-

What kind of stage/area information do you have at Pond1/2 node? Also the beginning stage at this node? It sounds like there could be a bunch of storage occuring there that would attenuate the flow to Pond1.

Also, I have found it helpful to use much smaller values of Max Delta Z (Routing Simulations)in my area (very flat) than those suggested in the documentation when dealing with interconnected ponds at the same elevation.

 

[xghalibx]

TerryScan:

The stage/area for Pond1/2 node is as follows: Stage-->.001; Stage2-->.001. So Basicaly, the each stage is set to 0.001 acres to simulate inlet size and to "push" water through the inlet and into the pipe to Pond 1. The negative Q is about 36 cfs so it has to push itself into pond 1 to equalize. As for Max Delta Z, I have specified 1. I played with 0.5 but it really didn;t change the numbers at all. On the note, what would be "smaller" to you?

lsp01:

I had modeled the scenario where pond 1 and pond 2 are connected with the equalizer pipe with no inlets between the pipe run. The % error goes down to zero in mas balance but there's was no negative flow from pond 2 to pond 1. The normal pool elevation of pond 1 is 936.5 whereas the normal pool elevation of pond 2 is 935. So now I am wondering whether there should have been a negative Q in the previous model where the inlets were included.

Thanks for the input so far guys...

 

[TerryScan]

xghalibx-

Could you email me the file or the portion of the model in question? I'm rather curious.

tps@dbfinc.com

 

[lsp01]

Xghalibx,

I don't understand your model, if the normal water level (NWL) in Pond 1 is 936.5 and the NWL in pond 2 is 935 ft, why would you expect the water to flow up gradient? Pond 2 would have to stage up 1.5 feet to induce flow back into Pond 1. Could it be just discharging to the outfall?

Is there a control structure on Pond 1 that maintains the higher NWL? And what is the control elevation at the outfall?

If the numbers that you gave are the peak stages it makes more sense. I have some thoughts concerning the model reaction, maybe one will strike a chord...

1. Remember that ICPR is a dynamic model, the PEAK flow through the equilizer may have been towards Pond 2. That doesn't mean that the equilizer can't switch directions. Check out the link graphs, I believe that there is a time vs flow graph available. Sometimes this will identify what is going on.

2. Is your assumption that there should be flow into Pond 1 from Pond 2 valid? What is the ratio of Pond sizes and drainage areas between the two ponds? There are a number of combinations that could result in Pond 1 staging up higher or earlier than Pond 2. Frequently I have found that Tc adjustments can have a large impact on a model. If you adjust the Tc by 10% or 15% of the original calculation, does the model still react in the same way? (You should always check your model for sensitivity.) In larger interconnected systems (20+ ponds) it can have a tremendous impact.


3. Double check that the equilizer pipe allows flow both ways. In ICPR you can model only positive flows, if this accidently gets toggled it can really mess you up. (It is valid to use positive flows on occasion, like when modeling flap gates and stormwater pumping stations.)

4. If you want to email me the model or some of the reports I would be happy to help, email is lsp_pe@yahoo.com. Like Terryscan, now you've got be curious.....

Lsp01

 

[TerryScan]

Ok, here is what I have come up with:

The mass balance errors are occurring on your larger events. The 18% one is the 100yr24h event. So, I am focusing on that.

When I looked at the Node maximum conditions report for the event, I noticed a maximum delta stage of 1.0ft.

Sidebar: when I use another hydro model that is not as refined as ICPR
(in this case incapable of small time increments), it is common to get
oscillations when interconnected ponds are nearly level. This appears to be
due to the fact that in time increment A, the head in Pond 1 is much higher
than Pond 2, so water gushes over to pond 2. In the next time increment (call
it B), the head in Pond 2 is now much higher than Pond 1 so it reverse flows
(erroneous due to too large of a time increment).

If you look at the Graphical 1 Simulation per page report of the nodes in
question, you will notice that there are nasty oscillations in your model.

At this point, I looked at the routing simulation definition. I mentioned in a previous post that I use smaller Max Delta Z values. I commonly use 0.1. In this case, I left it at 1.0. The number that really looks off to me is the Min Calc Time that you have set at 60sec. I reset this value to the suggested value of 0.5secs. There is now 0% Mass Balance error in the model.

I have had models with interconnected ponds in a VERY flat area where it was necessary to use the 0.10 Max Delta Z and a Min Calc Time of 0.05 in order to eliminate oscillations.

 

[xghalibx]

Guys:

Firstly, thanks for discussing the model in so much detail. This has given me alotta insight into ICPR functioning.

Lsp01:

I assumed that water will flow from pond 2 to pond 1 because the initial model, where I had the equalizer pipe modeled with the inlets, showed that water was flowing to Pond 1. After I removed the inlets and modeled the equalizer pipe as simply an equalizer pipe, it showed that no water flows back. Now I am beginning to feel that there's probably isn;t a negative Q for Pond 2. As for the sizes of the ponds, Pond 1 is about 0.6 acres and Pond 2 is about 1.2 acres. I almost always model pipes in ICPR as "Flow both ways" just for this reason. I am always on the lookout for water backflowing.

Terry,

Aa I said before, after I removed the inlets from the equalizer pipe, the %error went down to zero. Which makes me feel a little better about the model. I will, however, play with the Tc as Lsp01 suggested to observe the behavior.

AS you've described the oscillations in ICPR, it sounds more like an unavoidable "by-product" of the interconnected pond models during the very beginning and the very end of an storm event. I haven't opened the model today but are you saying that you noticed oscillations during the peak stages of the storm event??

Thanks...

 

[TerryScan]

Actually, I'm trying to say that oscillations are usually VERY AVOIDABLE in ICPR. One needs to find the source of the oscillations and fix the problem.

In the case of your model with the inlets, stage oscillations are quite evident beginning at hours 9-12 (depending on node)through hour 26 during the 100yr24hr event.

Look at NODE GRAPH reports, "1 Simulation per page".

These oscillations can be eliminated with a smaller minimum calc time.

 

[xghalibx]

ohhh.. o.k. I will play with that a little bit.. Thanks.