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

Bentley SWMM Engine Failure when run 24 hours

The model does not complete the run when I do 24 hours simulation, however, it is run when run less simulation time, for example, it is run for 12 hours in spite of using the same parameters in the calculation option.

I upload the model to the secured link for your reference and below are the screenshots of the notification and the calculation summary but could not figure out what is the problem, also before run the validation pass without any problems.

Regards,

Mohamad Azzam

Parents
  • Hello Mohammad,

    This is a known issue which is documented in this wiki: "Access violation in module execRouting" when computing with SWMM solver

    If you have inlets in your model, check if they are "on-grade" but don't have any downstream gutters or try changing the inlets to "in-sag".


    Regards,

    Yashodhan Joshi

  • Hello Yashodhan,

    It is the same physical network, that is running when using other time simulation and can complete the run there, the problem is only when select 24 hours run simulation, if the problem is regarding the inlet and gutters so the run should not be completed for any other simulation. So why we are able to do the complete run with simulations less than 24 hours but the run does not complete in when select 24 hours? 

    Regards,

    Mohamad

  • To close the loop regarding the performance remarks in models with a large number of catalog inlets and the SWMM solver - this has been fixed and the performance has been greatly improved. The fix is available in the latest cumulative patch set for version 10.03.04.53 and will also be included in the next version of SewerGEMS and CivilStorm.

    A new article has been published: Slow performance when using SWMM solver with a large number of inlets


    Regards,

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

    Answer Verified By: Mohamad Azzam 

  • Hello Jesse,

    It seems, unfortunately, the problem of the SWMM engine failure mentioned above is not solved with us completely, the graph unit does solve the failure for some scenarios (5 Years storm and some 10 years storm).

    I now uploaded the new model for your reference and the problems are in the 10 years storm in the following scenarios (FEH-10YR 90MIN, FEH-10YR 120MIN, FEH-10YR 180MIN, FEH-10YR 240MIN, FEH-10YR 300MIN, FEH-10YR 360MIN, FEH-10YR 720MIN). 

    As described in the post, the network physically is the same in all scenarios, and please note (for example) in the failure scenario FEH-10YR 90MIN when I used the rainfall runoff FEH-10YR 60MIN, the scenario run, then I checked the values for the 90 minutes rainfall and there is no mistake and the same used in other model and run well, the issue happens in this model with us and we are not able to figure out this failure issue. and since the network physically is the same and running in other scenarios so the issue is not related to the inlets nor the gutters  

    is occurring (such as overflow just starting to occur in a case where there is no downstream gutter) only at a time later on in the simulation.

    Yes that if the error occurs in all time simulation, but try to run for 2 hours (for example) the model completes the simulation; however it does not work for 24 hours.

    Since the network physically is the same and running in other scenarios so the issue is not related to the inlets or the gutters. This failure is really critical and we are not able to proceed any further in finalizing the design.

    Sincerly,

    Mohamad Azzam

  • Mohamad, most likely your model is unstable and small changes cause relatively large changes in the hydraulic results. It could be that an HGL "spike" occurs as a seemingly random location as small adjustments are made, and if that "spike" causes an overflow condition at a certain incorrectly configured location, the calculation fails.

    I noticed if I run the FEH-10YR 90MIN scenario for 1.6 hours it computes successfully (the failure happens sometime between 1.6 and 1.7 hours) and if I look at the Hydraulic Reviewer, I see a few particular locations such as CB-15, which have highly unstable results. 

    I am not certain if it related but I noticed that you have many in-sag catchbasins with outgoing/bypass gutters. There is a query under Network Review in Network Navigator to help identify these locations. I have attempted to make several adjustments to the advanced calculation options to no avail. This is a very complex model with a large number of interconnected inlets so it is difficult for me to pinpoint any specific data entry issues causing instability. I will continue investigating and escalate to our Development team if needed.


    Regards,

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

  • Thank you Jesse for the very fast checking and reply.

    As said in the same scenario once I change the rainfall runoff to 60MIN one it does run, and for the In Sag locations, we connected between them by gutters and the other scenario running, and the same concept we did in other large model and was working, but your developers know better than I and hope can find the issue.

    so it is difficult for me to pinpoint any specific data entry issues causing instability

    If the instability happens due to the data entry; why the model runs in other scenarios?

    I run the model "FEH-10YR 90MIN scenario" for 1.6 hours then I checked the hydraulic reviewer, and I can see the results and deviation, but would you please elaborate and help how to judge the instability from there?

    I can see the Inflow Volume = Outflow Volume so how do we have Overflow Volume and how generated if in=out?

    For the same CB-15 in the scenario "FEH-10YR 60MIN scenario" which can complete the run 24 hours shows overflow volume

    I know it is a big model and a complex one and that wy we are looking kindly the support.

    You and your team are highly appreciated for always supporting and solving the difficulties, your massive elaboration is usually given us perfect knowledge.

    Thank you,

    Mohamad Azzam

  • If the instability happens due to the data entry; why the model runs in other scenarios?

    A small change can result in totally different results because of the chaotic nature of instability. This is just an educated guess as to what is happening in your model, though. 

    I run the model "FEH-10YR 90MIN scenario" for 1.6 hours then I checked the hydraulic reviewer, and I can see the results and deviation, but would you please elaborate and help how to judge the instability from there?

    I examined a graph of HGL and flow and noticed it was erratic/unstable.

    I can see the Inflow Volume = Outflow Volume so how do we have Overflow Volume and how generated if in=out?

    If you graph HGL, rim, inflow, outflow and overflow you can see extreme overflow occurring as the HGL has unstable-looking "spikes".

    You and your team are highly appreciated for always supporting and solving the difficulties, your massive elaboration is usually given us perfect knowledge.

    I have exhausted all attempts to stabilize the model and prevent the calculation failure so I have escalated to our Development team for review. I will keep you updated.


    Regards,

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

Reply
  • If the instability happens due to the data entry; why the model runs in other scenarios?

    A small change can result in totally different results because of the chaotic nature of instability. This is just an educated guess as to what is happening in your model, though. 

    I run the model "FEH-10YR 90MIN scenario" for 1.6 hours then I checked the hydraulic reviewer, and I can see the results and deviation, but would you please elaborate and help how to judge the instability from there?

    I examined a graph of HGL and flow and noticed it was erratic/unstable.

    I can see the Inflow Volume = Outflow Volume so how do we have Overflow Volume and how generated if in=out?

    If you graph HGL, rim, inflow, outflow and overflow you can see extreme overflow occurring as the HGL has unstable-looking "spikes".

    You and your team are highly appreciated for always supporting and solving the difficulties, your massive elaboration is usually given us perfect knowledge.

    I have exhausted all attempts to stabilize the model and prevent the calculation failure so I have escalated to our Development team for review. I will keep you updated.


    Regards,

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

Children
  • Regarding the "access violation" failure with the SWMM solver - I have privately sent an updated cumulative patch set for SewerGEMS 10.03.04.53 which includes a fix to this issue. 

    The problem was again related to gutters for on-grade inlets. Although all on-grade inlets have bypass gutters based on start/stop connectivity, some on-grade bypass gutters have inverse slope which was causing the problem during timesteps when the conditions warranted bypass gutter flow. This seems to happen randomly because of the chaotic nature of unstable models, which this model appears to be.

    I have updated the related article: "Access violation in module execRouting" when computing with SWMM solver


    Regards,

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

    Answer Verified By: Mohamad Azzam 

  • Hello Jesse,

    Yes, we found that the same as well by using query (network review) and we found a few inlets and the model is running now.

    what confuses us is that the model is running for other scenario and such an issue should be reported in the validation or if exist all scenarios should give the same error.

    Thank you for your support and hope the new patch can cover that issue.

    Mohamad Azzam