This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Hammer: Surge Tank Initial Level

When modelling a surge tank it is necessary to dictate the initial level. When the steady state conditions are calculated, this seems to not affect the surge tank initial level, even if it does not match the head at the point on the line where it is installed. This causes a problem when the transient is run, as the tank level is 'released', which can create it's own transient if you have slightly miss-calculated the level because of the affect of friction.

It is difficult to know exactly what the head should be at a surge tank on a long waterway due to the friction. Is it possible for hammer to work out what the initial setting should be to avoid this?

Kind regards

 

 

  • Attached is a sample I am working on where this issue is causing me grief.

    The plot shows the surge chamber level, the surge chamber is set as a junction.

    One would expect once full flow is established, the HGL of the tank would settle at a higher level than when flow was zero due to downstream friction. The outlet is pipe is 1.8 km long so should have some effect. When running with constant flow the HGL is shown several metres higher, so I do not know why this doesn't come thorugh in the transient once full flow is reached?

    any help would be great.

  • Hello Matt,

    I see that you have submitted a Service Request regarding the second issue and a technical support engineer is working with you on that.

    Just wanted to comment on your first question regarding the surge tank initial level; Yes, it is possible for HAMMER to calculate the initial water surface elevation if the tank operates at line pressure (floats.) It sounds like you've already done this though.

    The surge tank node acts just like a normal Tank node, if you choose "false" for "treat as junction?", or if you choose "true" for "has check valve" (one-way surge tank). The initial level sets the boundary HGL at that point and the model will solve around it. From your description, it sounds like you may be choosing "true" for "treat as junction", or you may be modeling a one-way surge tank by setting the "has check valve?" option to true.

    If you have chosen to treat the surge tank as a junction, the hydraulic grade at the surge tank in the initial conditions is calculated as if it were a junction. This is useful if the surge tank is tall and operates at line pressure (water surface = system HGL). In this case, for the transient simulation, HAMMER will know to use the HGL from the initial conditions as the HGL of the tank, and basically ignored the initial elevation setting.

    If you are modeling a one-way surge tank, for the transient simulation, HAMMER knows that there are two hydraulic grades - the HGL at the node from the initial conditions (the head of the pipeline) and the HGL inside the tank itself (the water surface elevation). So, there should be no problem with the HGL being higher than the initial level. HAMMER should know that the check valve is closed, and will open it and allow flow from the surge tank, if the pipeline HGL drops below the water surface elevation inside the tank.

    Since you say you're seeing a "false transient" from the difference between the initial elevation and initial conditions calculated HGL, we may need to investigate to see if there is perhaps some other data entry problem causing this. Are you perhaps using an older version of HAMMER? I believe we may have had an issue in the past related to this, but that was many years ago. You can check your version under Help > About HAMMER. The latest is 08.11.04.57.

    If you're using a recent version of HAMMER, take a look at the Turbine_Example.wtg model, located in the "Samples" folder within your HAMMER installation folder. This has a surge tank with "treat as junction?" set to "true". You'll notice for example in the Load Acceptance scenario, the HGL at the surge tank is different from the initial level, yet there are no problems such as false surges.

    If you need to send us the model for review, either attach it to your forum reply, or use the Secure File Upload location:

    communities.bentley.com/.../bentleysecurefilesupload.aspx


    Regards,

    Jesse Dringoli
    Technical Support Manager, OpenFlows
    Bentley Communities Site Administrator
    Bentley Systems, Inc.

  • Hi Jesse, thanks for your reply.

    I do have my tank set up as a junction with no check valve, and as you mention this tank level should follow the HGL. My version is 08.11.03.17 which isn't too old I thought?

    It seems the steady state isn't accounting for something, in the example I have attached, I have set-up the model to give a constant flow, but the surge tank still starts with an osscilation, though it dampens out. I cannot identify anything else in the system that could cause this, so hopefully tech support will have some clues.

    Strangely when I run the transient with the increasing flows (units starting), once full flow is reached the surge tank level oscilates about the intial level, even though when I run a constant flow simulation, the tank level is different from the initial value as I would expect (reflecting the downstream pipe friction. It is like in the increasing flow simulation no account is taken of friction.

     

  • I seem to have located the problem, when a transient event is run in a simulation, friction is not re-calculated from steady-state as flow increases. I have yet to work out why, perhaps someone can suggest an option I have missed here. I am using mannings friction and have applied values to all my pipes

  • A solution has been found by tech support. For those that may search later; this problem was due to the software calculating no friction in situations where the simulation begins with no flow. Calculation noise resulted in a very minor flow above the threshold for being considered no flow. This caused a friction coefficient to be calculated that was essentially zero. The problem was corrected by raising the threshold in the transient options.

    Details on this problem are here: communities.bentley.com/.../hammer-time-history-results-show-oscillating-flow-when-dampening-from-friction-is-expected.aspx

    Hope it saves someone else some time.

    Thanks for those who have helped.