Results 1 to 4 of 4

Thread: Unidentified pressure and flow source

  1. #1

    Join Date
    Apr 2016
    Posts
    10

    Unidentified pressure and flow source

    Dear Infowater Experts,

    I am recently baffled with yet another “model run result” I’ve been experimenting on.

    Here is the situation;

    I have an area with some nodes with preloaded demands. These demands have “zero” multiplier for their consumption pattern for 0:00hr to 24:00hr. For the succeeding hours however, they will have the usual varying consumption pattern (meaning non zero multiplier). I have also put controls on the pipes that supplies the area, which is closed during 0:00hr and open on 25:00 hr.

    This consumption pattern and controls were intentionally imposed to show an alternating/intermittent/cycling (or whatever you call it) supply on my hydraulic network.

    My question is; how come some of the nodes on this area have negative pressure while others have positive pressure. I was expecting that the entire area would have either “zero or negative pressure” but not positive pressure.

    I’ve checked all possible entry points for water to supply the area, but all of them are closed. I even have the initial status of the “controlled supply pipes” with “closed initially” instead of the “none” status. What’s even weirder is when I displayed the flow arrows to check if there’s really flow, it shows that some pipes don’t have the flow arrows(which was what I have expected) and some have flow(which shouldn’t be). Below is a snapshot.

    sample.jpg

    To check if there's no real possible source, I've made a sample and replaced the consumption pattern of a node with a positive consumption multiplier to check if it will disconnect, and as expected as I run it, it showed disconnection because it doesn't have any source.


    Please shed me some light.

    Regards,
    Felipe

  2. #2
    Forum Moderator

    Innovyze Employee



    Innovyze Employee



    Join Date
    May 2015
    Posts
    419
    Felipe,

    Without the actual model, it is difficult to say 100% exactly, what is occurring, but we can speculate and you can check a few things.

    When the hydraulic equations are solved by our EPANET hydraulic engine, it is solving for the pipe flows that satisfy demands and Hydraulic Grade Line or Head values that are calculated based on locations of known head in the system (primarily from the tanks and reservoirs).

    Pressure is a value based on the numerically calculated head values and the elevations of the nodes of the converged solution. Since Hydraulic Grade line (or head) = Elevation + pressure (in ft.) if the elevation of any node is higher than the hydraulic grade line, then the calculated pressure will be negative. This is why certain areas can be positive and certain areas have negative pressures. It is all dependent on the head values calculated.

    If we understand your post correctly this is an isolated area for certain periods without demands. If that is occurring the area in question could have anomalous head values when isolated as there would be know "known" head value within the isolated area. Generally this causes a model to crash when there are demands in the isolated area and the model will issue a "disconnected node" warning, but if there are no demands, it may allow it but the head values could be inaccurate in that area it just depends on what may have occurred before the last iteration. To accurately calculate the head every node needs to have a clear path back to a tank or reservoir in order for the model to accurately resolve the head values. Without a path to a known head value, the solution EPANET calculates may not be completely accurate, as it does not have a know head reference to base the results on. Generally if you get very high or very low pressures (value in the millions) this is how EPANET conveys this uncertainty. If the software reached maximum trials and the run report notes "system may be unstable" this is essentially it noting the results presented are uncertain and potentially could be inaccurate for that trial as it did not reach the desired convergence accuracy.

    One of the key things that EPANET has to do is to satisfy demands with flows, so if an area has demands is closed, the software can sometimes "temporarily" open certain pipes trying to get a solution that were initially closed. In addition since this is a numerical solution, you could have flow in pipes due to either 1) a non converged solution or 2) due to very tiny flows that are visible but are below the convergence accuracy. For instance, when EPANET closes certain elements in the solution method it essentially simply sets the flow to a very small number like 10^-6 rather than zero. For most accuracy values used that would result in essentially zero flow at two decimal places.

    Can you check the following?

    1) Is your run report set to the following? The full status report with warning messages are key in troubleshooting anything unusual in the model run results. Once set, rerun the model open the run report and search for warnings or for iterations that exceed max trials as those results may not be 100% accurate as the solution did not fully converge.
    (click for larger image if necessary)
    Full Report with Warning Messages.png
    2) Are there any negative demands in the region that is closed? These will act like water sources. I would also verify the total demand within the "closed" region
    3) What is the total flow for all pipes in the closed region that show flow arrows? If they are very small it is likely just numerical error. In the first iteration of the software EPANET assumes all pipes have a flow of 1 ft/s at the start and then adjusts them as needed. It is possible that the flows are non-zero because of that and that there are still slight non zero flows due to the convergence accuracy either not being met at max trials or because the accuracy is too high. If there are zero demands inside the region and no negative demands, it is likely that it is just numerical error.
    4) Convergence accuracy: Generally an accuracy of 0.01 to 0.001 is the considered reasonable. Any accuracy higher than 0.1 has a high chance of having inaccuracies in the flow results. This is found in the simulation options. Verify your current settings are using a reasonable accuracy.
    (click for larger image if necessary)
    Simulation Options-Accuracy.jpg


    If you find you need more in depth assistance, please feel free to contact us at technical support at our support@innovyze.com email address and refer to this forum when posting.

    Thank you.

    Patrick Moore
    Last edited by Patrick Moore; October 17, 2016 at 09:21 AM.

  3. #3

    Join Date
    Apr 2016
    Posts
    10
    Hi Patrick,


    Thanks for the prompt response as usual. I've set my reply to your quote in red font.


    ================================================== ==========
    Felipe,


    Without the actual model, it is difficult to say 100% exactly, what is occurring, but we can speculate and you can check a few things.


    When the hydraulic equations are solved by our EPANET hydraulic engine, it is solving for the pipe flows that satisfy demands and Hydraulic Grade Line or Head values that are calculated based on locations of known head in the system (primarily from the tanks and reservoirs).


    Pressure is a value based on the numerically calculated head values and the elevations of the nodes of the converged solution. Since Hydraulic Grade line (or head) = Elevation + pressure (in ft.) if the elevation of any node is higher than the hydraulic grade line, then the calculated pressure will be negative. This is why certain areas can be positive and certain areas have negative pressures. It is all dependent on the head values calculated.


    (I perfectly agree with what is above)


    If we understand your post correctly this is an isolated area for certain periods without demands. If that is occurring the area in question could have anomalous head values when isolated as there would be know "known" head value within the isolated area. Generally this causes a model to crash when there are demands in the isolated area and the model will issue a "disconnected node" warning, but if there are no demands, it may allow it but the head values could be inaccurate in that area it just depends on what may have occurred before the last iteration. To accurately calculate the head every node needs to have a clear path back to a tank or reservoir in order for the model to accurately resolve the head values. Without a path to a known head value, the solution EPANET calculates may not be completely accurate, as it does not have a know head reference to base the results on. Generally if you get very high or very low pressures (value in the millions) this is how EPANET conveys this uncertainty. If the software reached maximum trials and the run report notes "system may be unstable" this is essentially it noting the results presented are uncertain and potentially could be inaccurate for that trial as it did not reach the desired convergence accuracy.


    (Your understanding is correct, that this area is isolated on certain periods, particularly the start of the EPS. Like I said on my previous post, I've made an experiment by putting a demand on a node, knowing that it would crash if the area isolated would be "run". I've done this to check if the area is indeed isolated. Indeed it did crash when I've done so resulting to the "disconnected node" warning. With regards to pressure, I would have accepted it if the values were very high and very low pressures, in the millions like you said because indeed, this could be the uncertainty of the EPANET's calculation. However on my case the negative values are in hundreds only and positive values were of the normal range. I’m attaching some snapshots to give you more clues on what I might be possibly having. The run report also did not mention a “system may be unstable” message or have reached maximum trialsnegative and positive pressure nodes.jpgpostive ave pressure nodes.jpgNegative Average Pressure nodes.jpg)


    One of the key things that EPANET has to do is to satisfy demands with flows, so if an area has demands is closed, the software can sometimes "temporarily" open certain pipes trying to get a solution that were initially closed. In addition since this is a numerical solution, you could have flow in pipes due to either 1) a non converged solution or 2) due to very tiny flows that are visible but are below the convergence accuracy. For instance, when EPANET closes certain elements in the solution method it essentially simply sets the flow to a very small number like 10^-6 rather than zero. For most accuracy values used that would result in essentially zero flow at two decimal places.


    Can you check the following?


    1) Is your run report set to the following? The full status report with warning messages are key in troubleshooting anything unusual in the model run results. Once set, rerun the model open the run report and search for warnings or for iterations that exceed max trials as those results may not be 100% accurate as the solution did not fully converge.


    (As suggested I’ve set the model for full status report and made a model re-run. No warnings were apparent neither exceeding the maximum trials message)

    2) Are there any negative demands in the region that is closed? These will act like water sources. I would also verify the total demand within the "closed" region


    (No negative demands all nodes in the subject area. Total demand is of around 40 cmd.)


    3) What is the total flow for all pipes in the closed region that show flow arrows? If they are very small it is likely just numerical error. In the first iteration of the software EPANET assumes all pipes have a flow of 1 ft/s at the start and then adjusts them as needed. It is possible that the flows are non-zero because of that and that there are still slight non zero flows due to the convergence accuracy either not being met at max trials or because the accuracy is too high. If there are zero demands inside the region and no negative demands, it is likely that it is just numerical error.


    (total flow is around 32cmd. Flow and flow arrows are actually only apparent on the 0:00hr meaning the initial value that EPANET is using, as you have mentioned, explains this item. I consider the flow issue resolved, I am more concerned however with the pressure as I have been mentioning above.)


    4) Convergence accuracy: Generally an accuracy of 0.01 to 0.001 is the considered reasonable. Any accuracy higher than 0.1 has a high chance of having inaccuracies in the flow results. This is found in the simulation options. Verify your current settings are using a reasonable accuracy.


    (My accuracy setting is at 0.001)









    If you find you need more in depth assistance, please feel free to contact us at technical support at our support@innovyze.com email address and refer to this forum when posting.


    Thank you.


    Patrick Moore[/QUOTE]
    ================================================== ============================


    I’d probably need a more in depth assistance regarding the “pressure” part and will do as you have advised.


    Thanks as always Patrick.


    Regards,
    Felipe

  4. #4
    Forum Moderator

    Innovyze Employee



    Innovyze Employee



    Join Date
    May 2015
    Posts
    419
    Felipe,

    I will keep an eye out for your email. Looking at your model is the best way to answer the remaining questions you may have.

    If I do understand the EPANET solution method it will use the previous period results as the initial guesses except for the initial trials which assume that all pipes have a velocity of 1 ft/s in them. If your region is opening and closing, it may be that the periods where they are close but still odd are due to the influence of the previous round results. But since there is no known head in the isolated region, but no demand, EPANET may be allowing for partial solutions, but since the accuracy is based on the flow balance , may create some differences in the head values that are misleading. What you can do to make sure the head values are good is to simply leave one pipe open to the system so that the head values will reflect the actual system conditions when there is no demand.

    Patrick Moore

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •