TUFLOW Simulation Speed: Difference between revisions
Content deleted Content added
Chris Huxley (talk | contribs) No edit summary |
|||
| (6 intermediate revisions by 4 users not shown) | |||
Line 4:
* Initialisation:
** Use XF files to speed up the model initialisation (the default).
** Use TIF or FLT grids for grid inputs instead of ASC as they are faster to read. FLT files are ESRI binary (float) version of the ASC files, their size is about 1/2 to 1/5 of an ASC file. To convert ASC to FLT, use -conv switch with our <u>[[ASC_to_ASC#Convert | ASC_to_ASC utility]]</u>.
* Writing check files:
** Writing check files to a local solid state drive usually take less time than to a network drive.
Line 11:
** Use output zones to write localised check files when specific areas of a model domain are of interest.
* Simulation:
** Use single precision version of TUFLOW if double precision is not required. More information on single and double versions <u>[[
** If using TUFLOW HPC, review the <u>[[HPC_Model_Review#dt_Map_Output | minimum dt map output]]</u> to check for locations with low timestep and whether any improvements can be applied to speed up the simulation.
* Writing results:
Line 17:
** Make sure there is enough free space as drives slow down when they are nearing to being full.
** Use output zones to write localised results when specific areas of a model domain are of interest.
** Use TIF or FLT for grid results instead of ASC as they are more efficient in terms of write speed and file size.
** Specify XMDF for temporal output instead of DAT as they are more compressed and faster to write.
** Use appropriate <font color="blue"><tt>Map Output Interval</tt></font> for XMDF, e.g. around 100 output increments for the whole simulation unless an animation of high temporal resolution is to be created.
** Output only maximum TIF or FLT grids with <font color="blue"><tt>FLT Map Output Interval </tt></font> <font color="red"><tt>== </tt></font><tt>0</tt> instead of every <font color="blue"><tt>Map Output Interval</tt></font>. Keep the temporal output only as XMDF.
** Specify only <font color="blue"><tt>Map Output Data Types </tt></font> that are needed.
** For further details, see <u>[https://www.youtube.com/watch?v=-CsKKjG7jpQ&ab_channel=TUFLOW Output Management Advice]</u> webinar.
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 Sub Grid Sampling (SGS)
<ol>
▲* 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.
* Increase your 2D cell size. Thanks to SGS the cell size can typically be increased whilst still achieving a good cell size convergence.
* 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> <tt>or <font color="blue"><tt>SGS Sample Sample Target Distance </tt></font><tt>commands.
</ol>
* 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)
| |||