TUFLOW Simulation Speed: Difference between revisions
Content deleted Content added
No edit summary |
Teegan.Burke (talk | contribs) |
||
| (3 intermediate revisions by 2 users not shown) | |||
Line 29:
** The better the hardware, the faster TUFLOW model would run. To see how different hardware compares to each other, see <u>[[Hardware_Benchmarking_-_Results#CPU_Results | Hardware Benchmarking Results]]</u>.
** For more information on hardware specification, see <u>[[Hardware_Selection_Advice | Hardware Selection Advice]]</u>.<br>
* Other processes can slow TUFLOW simulations down if they are competing for resources. A few potential causes:▼
Reducing RAM requirements: ▼
** Running another model at the same time (as the CPU RAM is shared between both simulations)▼
* 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.▼
** Scheduled computer back ups▼
* Using Quadtree may decrease RAM requirement as with Quadtree mesh only active code polygon is processed instead of the whole model domain rectangle used for HPC and Classic. Also, judicious refinement and using larger cells in non-focus areas will decrease the number of active cells and therefore the RAM requirement.▼
** Operating system updates▼
* 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.▼
** Antivirus scans▼
* 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.▼
** Others activities (e.g. copying large files, writing large files).▼
▲* Reducing RAM requirements:
* 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.▼
▲** 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.
* 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.▼
▲** Using Quadtree may decrease RAM requirement as with Quadtree mesh only active code polygon is processed instead of the whole model domain rectangle used for HPC and Classic. Also, judicious refinement and using larger cells in non-focus areas will decrease the number of active cells and therefore the RAM requirement.
* 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.▼
▲** 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.
* 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 the <u>[https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]</u> for more information on grid outputs.▼
** Using Sub Grid Sampling (SGS) increases the RAM requirement compared to a non SGS model with the same cell size. If SGS increases the RAM beyond what is desired, consider the following:
▲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)
*** Review your SGS Sample Frequency in the TLF. Typically, a value of 11 or less is all that is necessary to set the SGS parameterisation to a level that achieves excellent accuracy. If the SGS Sample Frequency is excessively large, test reducing the default value by using either the <font color="blue"><tt>SGS Sample Frequency</tt></font> or <font color="blue"><tt>SGS Sample Sample Target Distance </tt></font>commands.
▲* Scheduled computer back ups
▲** 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.
▲* Operating system updates
▲** 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.
▲* Antivirus scans
▲** 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.
▲* Others activities (e.g. copying large files, writing large files).
▲** 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></font> can reduce the amount of memory required for this. Refer to the <u>[https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]</u> for more information on grid outputs.
** 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.
<br>
| |||