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 Errors when using Extended CAV

Hello, 

I am getting this error: "There is a data error affecting a diameter change or air valve. Change flow(s) in adjacent pipe(s) to preclude initial pocket formation." and/or other generic errors when I use the Extended CAV option for one of my scenarios.

Shutdown under "normal" conditions works out just fine under extended CAV, but the client wanted to model an emergency shutdown under max flow with the tank at the end of the line empty. If I run with concentrated CAV method, there are no errors and no surging. However, the one time I got through the simulation without errors, there were extreme surges and air pockets in the millions of gallons.

The client requested running extended CAV, however, it is not working for me. I can upload my model so that it can be checked out, but I will need a proper explanation as to why the extended CAV option causes such errors and extreme surges.

thanks

Parents
  • Hello Kathryn,

    This may happen in some cases where extreme results are reached, such as very large air or vapor pocket formation. Check the surge tank configuration for errors. If using the surge tank with a turbine, or in other cases where it should operate at "line" pressure, consider choosing setting the property field "Treat as junction?" to "True" to allow the initial equilibrium HGL to be computed for the tank.

    The above information was taken from the following article:

    http://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/20163.there-is-a-data-error-affecting-a-diameter-change-or-air-valve-change-flow-s-in-adjacent-pipe-s-to-preclude-initial-pocket-formation-when-computing-a-hammer-simulation-with-a-surge-tank-solution-500000080431

    If that doesn't help then please provide your model files (.wtg, and .SQLite).  There are two options for sharing your model on Communities, whichever you choose please be sure to zip your files first. The first option is to attach the zip file containing your model to your reply on the forum using the Advanced Reply Editor (you'll find the link below and to the right of the reply box). If your data is confidential please use the instructions in the link below to send it via Bentley Sharefile. Files uploaded to Sharefile can only be viewed by Bentley employees. Please be sure to reply on this thread with the name of the file after it has been uploaded.

     

     

    Regards,

    Craig Calvin

    Bentley Technical Support

  • I have uploaded my model to the server. The scenario in question is scenario 03A. Again, runs fine in concentrated CAV, but frequent general errors in extended CAV.
  • Thanks for sending the files. Is your client aware of the limitations of the Extended CAV feature as documented in the below article?

    Assumptions and limitations of tracking air or vapor pockets in HAMMER

    When using the Extended CAV option, HAMMER can track the air-liquid interface at air valves, but only to the extent of the two adjacent pipes. In your model, each air valve has a short, one foot pipe on each side. I'm guessing that this was done in order to satisfy the requirement whereby the air valve must be at a higher elevation then the two adjacent nodes, in order to use the Extended CAV option. The junctions on the other side of the one-foot pipes next to each air valve are at a slightly lower elevation.

    Based on my investigation into your model, I believe that the instability is introduced because of this - when air is first admitted into the air valve, the air-liquid interface very quickly reaches the end of the adjacent one-foot pipes and stops, initiating a transition between extended to concentrated. This likely happens at a number of your many air valves, all within a short period of time, causing instability. The instability eventually reaches the point where the calculations fail. If you observe the timestep at which the error occurs, you can adjust the simulation duration to be slightly less, then run again. You'll then be able to observe these chaotic conditions start to form just before the model run "crashes".

    As a test, I started adjusting the pipes on either side, keeping the total pipeline length the same, by moving the junctions on either side of the air valve further away from it. This results in longer pipes on either side of the air valve, to allow the Extended CAV option to "work" for a longer period, while still satisfying the requirement mentioned above about the elevations and also while keeping the total pipeline length the same.

    As an illustration, this:

    Becomes this:

    As I started doing this, the model was able to progress further and further before the crash occurred. Eventually it was able to compute the entire 200 seconds without error. Though, an animation of the profile in the Transient Results Viewer showed me that things were still quite unstable near the other air valves that I hadn't gotten to yet (just not bad enough to "crash" the model). I then tried a rough approach, changing all the pipes adjacent to the air valves to scaled length, the manually dragging the junctions away, lengthening the pipes further. Once I completed this with all air valves, the results were much better, but there was still instability. Transitions between Extended and Concentrated approaches still seemed to occur rapidly in places, likely unavoidable with the nature of the extended CAV approach and with this many air valves. Based on user notifications about the adjacent pipe being drained, I lengthened some of the "hills" further and seemed to get even "better" results. I'll send you a separate private message with a copy of my example model - illustrative purposes only.

    Based on my observations, I would suggest passing along the information about the limitations of the Extended CAV option to the client and explore specifics on why they want to use it. If it must be used, consider if it needs to be on all air valves, and lengthen the "hill" if possible (per illustrations above).  


    Regards,

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

    Answer Verified By: Kathryn Pratka 

Reply
  • Thanks for sending the files. Is your client aware of the limitations of the Extended CAV feature as documented in the below article?

    Assumptions and limitations of tracking air or vapor pockets in HAMMER

    When using the Extended CAV option, HAMMER can track the air-liquid interface at air valves, but only to the extent of the two adjacent pipes. In your model, each air valve has a short, one foot pipe on each side. I'm guessing that this was done in order to satisfy the requirement whereby the air valve must be at a higher elevation then the two adjacent nodes, in order to use the Extended CAV option. The junctions on the other side of the one-foot pipes next to each air valve are at a slightly lower elevation.

    Based on my investigation into your model, I believe that the instability is introduced because of this - when air is first admitted into the air valve, the air-liquid interface very quickly reaches the end of the adjacent one-foot pipes and stops, initiating a transition between extended to concentrated. This likely happens at a number of your many air valves, all within a short period of time, causing instability. The instability eventually reaches the point where the calculations fail. If you observe the timestep at which the error occurs, you can adjust the simulation duration to be slightly less, then run again. You'll then be able to observe these chaotic conditions start to form just before the model run "crashes".

    As a test, I started adjusting the pipes on either side, keeping the total pipeline length the same, by moving the junctions on either side of the air valve further away from it. This results in longer pipes on either side of the air valve, to allow the Extended CAV option to "work" for a longer period, while still satisfying the requirement mentioned above about the elevations and also while keeping the total pipeline length the same.

    As an illustration, this:

    Becomes this:

    As I started doing this, the model was able to progress further and further before the crash occurred. Eventually it was able to compute the entire 200 seconds without error. Though, an animation of the profile in the Transient Results Viewer showed me that things were still quite unstable near the other air valves that I hadn't gotten to yet (just not bad enough to "crash" the model). I then tried a rough approach, changing all the pipes adjacent to the air valves to scaled length, the manually dragging the junctions away, lengthening the pipes further. Once I completed this with all air valves, the results were much better, but there was still instability. Transitions between Extended and Concentrated approaches still seemed to occur rapidly in places, likely unavoidable with the nature of the extended CAV approach and with this many air valves. Based on user notifications about the adjacent pipe being drained, I lengthened some of the "hills" further and seemed to get even "better" results. I'll send you a separate private message with a copy of my example model - illustrative purposes only.

    Based on my observations, I would suggest passing along the information about the limitations of the Extended CAV option to the client and explore specifics on why they want to use it. If it must be used, consider if it needs to be on all air valves, and lengthen the "hill" if possible (per illustrations above).  


    Regards,

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

    Answer Verified By: Kathryn Pratka 

Children
No Data