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

  • I was not able to access the steps to reduce the size of the database.

    This is the correct link: SQLITE database size grows very large due to Change Tracking


    Regards,

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

  • Hello Jesse,

    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.

    This model has an unusual configuration of catchbasin connectivity that is unlikely to match the real world conditions

    would you please elaborate what is not match the reality?

    please confirm the scenario to compute and any other changes we need to make

    Here are the screenshots I am working on, please note all the same and as I mentioned I am facing the issue in the 24 hours.

    PS: just would pay your attention to the time it takes the run and would like to remind you about that, hope the new release enhances that, by the way; in UAE all other engineering companies suffering from the time it takes especially because the new standard is to do the model with inlets (that the feedback when I discuss with other engineers here). we all waiting for that big enhancement for saving time, in big models for any change we are waiting a long time till the run finish to see the results, so imagine the project and how long it takes!

    Thank you,

    Mohamad

  • 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.

    The unstable or unexpected condition likely occurs closer to 24 hours. We are looking into it.

    would you please elaborate what is not match the reality?

    See item #4 from my reply to this thread on January 19th. You can already provided an explanation, but the way it is configured in the model might be contributing to the long run time and potential instability that is causing the model to fail. We do not know for sure yet and will get back to you.

    Here are the screenshots I am working on, please note all the same and as I mentioned I am facing the issue in the 24 hours.

    This appears to be a different scenario than the one shown in your original screenshot. We will take a look.

    PS: just would pay your attention to the time it takes the run and would like to remind you about that, hope the new release enhances that, by the way; in UAE all other engineering companies suffering from the time it takes especially because the new standard is to do the model with inlets (that the feedback when I discuss with other engineers here). we all waiting for that big enhancement for saving time, in big models for any change we are waiting a long time till the run finish to see the results, so imagine the project and how long it takes!

    This was reported to our Development team in March (reference # 815156) and they are still looking into it. I will pass along your remarks.


    Regards,

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

  • Hello Mohammad,

    I tried several combinations of runs but anything beyond 12 hours of simulation time is still giving the same error. We have had some recent improvements in run time especially for large models using the Explicit SWMM solver. We will test your model and see if it helps and share the patch with you.

    Appreciate your patience on this.


    Regards,

    Yashodhan Joshi

  • Hello Jesse/Yashodhan

    We found the reason for the engine failure, in two locations the Inflow Hydrographs are entered in the wrong units, meaning instead of 30 m3/s it is actually 30 L/s and instead of 17.5 m3/s, it is 17.5 L/s. once that is corrected the model runs. 

    Now the issue/question is why the engine reacts to big flow by engine failure, even if the flow is huge and the pipe is small (for such flow); the model should complete the run and gives a warning/report high values?.

    hope that helps in the investigation and feedback.

    Regards,

    Mohamad Azzam

Reply
  • Hello Jesse/Yashodhan

    We found the reason for the engine failure, in two locations the Inflow Hydrographs are entered in the wrong units, meaning instead of 30 m3/s it is actually 30 L/s and instead of 17.5 m3/s, it is 17.5 L/s. once that is corrected the model runs. 

    Now the issue/question is why the engine reacts to big flow by engine failure, even if the flow is huge and the pipe is small (for such flow); the model should complete the run and gives a warning/report high values?.

    hope that helps in the investigation and feedback.

    Regards,

    Mohamad Azzam

Children
  • I'm glad to hear that you found a likely cause of the issue. As the related wiki article states, this particular error occurs when the SWMM solver encounters an extreme, unexpected situation that it is not able to handle.

    So, to answer your question - with extreme overflow occurring from the mistakenly large flows, the solver may be encountering hydraulic results that are so unstable that they are not able to properly converge, producing the failure message. 

    With that said, I agree that it would be helpful if the program were able to identify some kind of clue for you to locate such issues, such as the element name nearby the failure. It could be that this type of diagnostic information is not possible to generate within the scope of the SWMM solver, but I have reported this to our developers for consideration in a future version (reference # 887501)


    Regards,

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

    Answer Verified By: Mohamad Azzam 

  • 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