TUFLOW Simulation Speed

Common Questions Answered (FAQ)

How can I speed up my TUFLOW model, make it more storage efficient and reduce RAM requirements?

The following tips provide advice on how to make TUFLOW models initialise, run and write results faster. Most of the suggestions will also ensure the model output size is kept to minimum, minimising required disk space.

• 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 ASC_to_ASC utility.
• Writing check files:
  • Writing check files to a local solid state drive usually take less time than to a network drive.
  • Make sure there is enough free space as drives slow down when they are nearing to being full.
  • Suppress unnecessary check files - some check files, such as zpt, uvpt and grd check file, can take a relatively long time to write. If some check files are not changing, they can just be written once and excluded for subsequent simulations with the below command. Any check file can be excluded, example of such command is Write Check Files EXCLUDE == zpt uvpt grd.
  • 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 here.
  • If using TUFLOW HPC, review the minimum dt map output to check for locations with low timestep and whether any improvements can be applied to speed up the simulation.
• Writing results:
  • Writing results to a local solid state drive usually take less time than to a network drive. This also applies to running models on a cloud. From our testing, writing outputs on a local drive of the virtual machine is noticeably faster than using network storage.
  • 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 Map Output Interval 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 FLT Map Output Interval == 0 instead of every Map Output Interval. Keep the temporal output only as XMDF.
  • Specify only Map Output Data Types that are needed.
  • For further details, see Output Management Advice webinar.
• Hardware:
  • Consider using multiple resources:
    • TUFLOW HPC is parallelised and can run on multiple devices. By default, TUFLOW HPC running on GPU uses one GPU card, to increase the number see Running HPC on multiple GPU devices. TUFLOW HPC running on CPU uses by default four CPU threads, to increase the number see Running HPC on multiple CPU threads. Note that model initialisation, 1D calculations and writing results are being processed on the CPU side even if GPU resources are used for the 2D simulation and currently these processes only use one CPU thread.
    • TUFLOW Classic isn't parallelised and only uses a single CPU thread for every simulation. Model initialisation, 1D calculations and writing results are also limited to only one CPU thread.
  • The better the hardware, the faster TUFLOW model would run. To see how different hardware compares to each other, see Hardware Benchmarking Results.
  • For more information on hardware specification, see Hardware Selection Advice.
    

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 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.
• The larger cell size, the less RAM is required. Cell size sensitivity testing 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.

• 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 Grid Output Cell Size == <grid_output_cell_size> can reduce the amount of memory required for this. Refer to the TUFLOW Manual for more information on grid outputs.

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)
• Scheduled computer back ups
• Operating system updates
• Antivirus scans
• Others activities (e.g. copying large files, writing large files).

Up
Back to TUFLOW Modelling Guidance