Simulation ERROR Openflows FLOOD

Hello! I followed the steps in the openflowsFLOOD simulation guide, but at the end I got the following error. Any way to fix it?

Parents
  • Hello,

    Yes, when you set the initial and end date for a simulation in FLOOD, the dates should be consistent with the ones you've set in SewerGEMS. 

    In SewerGEMS the default initial date is 1 Jan 2000 at 00:00. Check the dates in FLOOD and change accordingly and it should solve the problem.

    Kind regards,
    Luis

    Answer Verified By: Luis Bergonzini 

  • Hello Luis!

    I changed the date time in SewerGEMS and uptaded the file, but the error persists, look.

  • Hello,

    Did you save the SewerGEMS file before re-importing it in FLOOD using the tool "Urban Floods -> Connect SewerGEMS model to MOHID Land model"?

    Also, after you run the tool, make sure the path to the updated "Stormwatermodel.inp" file is correctly defined in the Stormwater module. The default path to the "Stormwatermodel.inp" is set to be in the same folder of the digital terrain model Grid Data file. Make sure you're using the newly created ".inp" file. You can also open the ".inp" file in a text editor to check the initial and end dates there are consistent with the ones on the Model settings.

    If that does not work, please send us the FLOOD workspace and the SewerGEMS project for us to check. 

    Thanks and regards,
    Luis

  • Hello Luis!

    Now it worked. I didn't know I needed to import the 1D model again. I thought that because it was linked to the directory it would already update. The only problem is that it is taking a long time to complete the simulation. Now it's been 9 hours and it's at 65%. Is this normal or could it be some option that I enabled that makes processing more complex?

  • Hello Luis,

    Factors that influence computation time are: 

    1) Size of the grid (total number of grid cells)

    2) Grid resolution (the smaller the size of the grid cells, the more time it will take to compute)

    3) Water depth - the 2D solver dynamically adapts its time step to guarantee numerical stability. Water depth is the variable that determines if the integration time step needs to be adjusted. The higher the water depth (at any cell in the grid), the small the time needs to be. The smaller the time step, the more time it takes to compute the simulation. If you're simulating areas where the water depth gets too high then it will take longer to compute. Sometimes your terrain model can have some errors (inconsistent values) that create unreal depressions, where water can accumulate and cause the model to slow down. Also, if you set closed boundary conditions on 2D grid (see options Impose water level in module RunOff), the water may accumulate at the open boundary and start to increase the water depth and slow the calculations. You can check the HDF5 results even if the simulation hasn't finished. Look for grid cells where what I've mention above may be occurring. 

    Hope this helps,
    Luis

Reply
  • Hello Luis,

    Factors that influence computation time are: 

    1) Size of the grid (total number of grid cells)

    2) Grid resolution (the smaller the size of the grid cells, the more time it will take to compute)

    3) Water depth - the 2D solver dynamically adapts its time step to guarantee numerical stability. Water depth is the variable that determines if the integration time step needs to be adjusted. The higher the water depth (at any cell in the grid), the small the time needs to be. The smaller the time step, the more time it takes to compute the simulation. If you're simulating areas where the water depth gets too high then it will take longer to compute. Sometimes your terrain model can have some errors (inconsistent values) that create unreal depressions, where water can accumulate and cause the model to slow down. Also, if you set closed boundary conditions on 2D grid (see options Impose water level in module RunOff), the water may accumulate at the open boundary and start to increase the water depth and slow the calculations. You can check the HDF5 results even if the simulation hasn't finished. Look for grid cells where what I've mention above may be occurring. 

    Hope this helps,
    Luis

Children
  • Hello,

    Thanks. I will try to test some options after to improve the computation. 

    After the simulation, everything seems to have gone well. However, I have some doubts regarding the results and would like, if possible, if you could help me interpret them. In the images below, I have some examples of moments where there are points where the water level on the ground stands out, which is in fact based on my calibration scenario done in SewerGEMS.

    Simulation Image: https://prnt.sc/lZnSTDOgjxgO

    Looking at the image, I noticed that when compared with the simulation made in the guide "Quick Start - Urban Flood Simulation Apr20", the image in the guide seems to represent the entire area covered by water during the occurrence of rain, indicating with stronger colors the places where the flooding was more intense. During rain, it is natural for there to be a minimum amount of natural runoff in the streets. In my simulation above, this seems to only be occurring more occasionally. Should I worry about making any adjustments because perhaps I am presenting an incorrect result, or are the results presented correct (visually)?

    Guide Image: https://prnt.sc/65MxsZBOymaK

  • I can't really interpret the results from the image. Can you post the output HDF5 file, or the full project please? 

    Thanks,
    Luis

  • Hello Luis,

    In the RunOff module, you've set:

    • Impose boundary water level -> True
    • Boundary water level -> 100m
    • Allow boundary inflow -> True
    • Boundary maximum terrain elevation -> 10000m

    These settings mean that:

    • you want to impose a fixed water level equal to 100m at the open boundary condition.
    • You also set the option to allow boundary inflow, which means that if the boundary water level (100m) is higher than the water level in grid cells adjacent to the open boundary, then an external boundary inflow is considered (i.e. water will enter you model domain from the open boundaries).
    • Because you've set the "boundary maximum terrain elevation" to 10000m. This means that all grid cells with terrain elevation lower than 10000m that are located at the edge of the grid will be considered to be open boundary cells where the boundary water level is being imposed. In your case, that is all the grid's edge grid cells because your terrain elevations are all lower than 10000m.

    Given that you start with dry conditions (water depth is set to zero), and your terrain elevations along the open boundary range around 80-90 meters, this means that you are continuously imposing a 10 to 20 meter (!) wave entering the grid area. This is the main reason why the model was taking more time than expected because the water depth is so high. 

    To set it correctly I recommend you to set: 

    • Impose boundary water level -> True
    • Boundary water level -> 70m
    • Allow boundary inflow -> False
    • Boundary maximum terrain elevation -> 83m

    Below in an image of your gridded terrain elevations. The purple areas are grid cells with less than 83m. If you set the above options, all the purple cells at the edge of the grid will be open boundary cells. Naturally the water will flow there and when it reaches the boundary you can allow it to leave through the open boundary by setting a lower water level. If you set it to 70m (which is lower than any terrain elevation inside your grid) then you are sure it will flow out. 

    You can read more about setting open boundary conditions here

    Kind regards,
    Luis

  • Hello Luis!

    Thank you very much for the explanation. I will make the changes you suggested and I will simulate again. If in doubt, return here. Relaxed