TUFLOW Simulation Speed: Difference between revisions
Content deleted Content added
No edit summary |
|||
| (2 intermediate revisions by 2 users not shown) | |||
Line 30:
** For more information on hardware specification, see <u>[[Hardware_Selection_Advice | Hardware Selection Advice]]</u>.<br>
Reducing RAM requirements:
* Model domain should be as tight to the model code (active areas) as possible - search the .tlf for "Isolating redundant perimeter sections", this will tell you how much larger the domain is than it needs to be as a percentage.
* Using Quadtree may
* The larger cell size, the less RAM is required. <u>[https://www.youtube.com/watch?v=1jWyIXHR_lM Cell size sensitivity testing]</u> can be carried out to find out the largest cell size without compromising model accuracy.
* Using SGS does increase RAM requirement compared to a non SGS model with the same cell size. However, thanks to SGS the cell size can typically be increased whilst still achieving a good cell size convergence and therefore RAM requirement may be lower than the original non-SGS model.
▲* Using Quadtree may also decrease RAM requirement as with Quadtree mesh only active code polygon is processed instead of the whole model domain rectangle used for HPC. Also, judicious refinement and using larger cells in non-focus areas will decrease the number of active cells and therefore the RAM requirement.
* Inputs might be clipped if their extent is much larger than the code, e.g. grids, material layers and so on. For example if a 100GB DEM is being input to TUFLOW with the majority of the DEM being outside the TUFLOW model, TUFLOW allocates memory to read the entire DEM in for processing. Memory for reading inputs is only used temporarily and is released after the processing of the input, e.g. the DEM.
* Large DEM and material grids can use up a lot of memory during model initialisation as the entire grid is read for processing. Re-tiling the grid into smaller sections will use up less memory as each smaller grid will be processed at the time avoiding high memory peaks.
* Inspecting .tlf file can help recognising which model features require the most RAM and more RAM efficient methods might be considered. For example, using gridded rainfall is more RAM efficient than using large number of rainfall polygons. Other features such as soil infiltration, hazard outputs and output zones all require additional memory.
* Grid (raster) outputs from TUFLOW (including DEM check files and Map Output Formats ASC, FLT, NC, TGO and WRR), require significant memory for storing interpolation factors. An interpolation is required as these outputs are all north-south aligned, while TUFLOW models can include rotation, water level lines and varying cell sizes. By default the grid output resolution is half the 2D cell size. Increasing the output cell size with the .tcf command <font color="blue"><tt>Grid Output Cell Size </tt></font> <font color="red"><tt>==</tt></font><tt> <grid_output_cell_size></tt> can reduce the amount of memory required for this. Refer to
* When using Quadtree the .qcf command <font color="blue"><tt>Quadtree Mesh Processing Method </tt></font> <font color="red"><tt>==</tt></font><tt> Memory Efficient</tt> can reduce the amount of memory, although the model initialisation might take longer.
Other processes can slow TUFLOW simulations down if they are competing for resources. A few potential causes:
* Running another model at the same time (as the CPU RAM is shared between both simulations)
| |||