TUFLOW Version Backward Compatibility

Backward Compatibility Change Register

For backward compatibility and release notes, please see Section 18 of the TUFLOW Manual [1]

Frequently Asked Questions (FAQ)

Why are model results developed in an older release different to a newer release?

If comparing a Classic model with HPC, also check the Will TUFLOW HPC and TUFLOW Classic results match? page in addition to this answer.
In addition to the above, there are reasons why model results would be different between different TUFLOW releases, whether it is the Classic or HPC solver, as follows:

• General improvements and fine-tuning of the solution scheme, especially for the more complex hydraulic physical terms and situations such as: sub-grid turbulence representation; treatment of shocks (e.g. hydraulic jumps); and transitioning between sub-critical and super-critical flow on steep slopes.
• Some new functionality can cause a significant change in results. For example:
  • Sub-Grid Sampling (SGS) applied to an existing model that used a too coarse cell resolution in high flow areas of highly variable topography (relative to the 2D cell size). SGS will greatly improve the model's ability to convey water accurately in these situations with vastly improved results.
  • New default sub-grid turbulence scheme in the 2020 release of TUFLOW HPC that is cell size independent and allows modellers to use cell sizes much smaller than the flow depth across all scales from flume to large rivers. For more information on differences between Smagorinsky scheme (HPC releases up to 2020) and the Wu turbulence scheme (2020 onwards) see here.
• Changes to the default settings and values, e.g.:
  • different default eddy viscosity formulation and/or coefficients,
  • improved data pre-processing approaches such as sampling materials on cell mid-sides instead of cell centres,
  • and many others.
  • For backward compatibility the Defaults == command is available to run old models on new releases to replicate past results (note, sometimes full backward compatibility cannot be catered for due to different code compiler and updates that can't be reverted, especially for several releases earlier).
• New features that use GIS attributes previously reserved (i.e. unused). If these attributes were not populated with the recommended “reserved” value (usually 0 or blank), then they can cause unpredictable results in later releases.
• Bug fixes noting that most bug fixes are input/output related and rarely affect the model's hydraulic calculations.
• Change in timestepping can also produce a small change in results. HPC uses the Runge-Kutta 4th order integrator, which is usually fairly insensitive to time step provided the model is running stably. However when a region is filled by flow that only just overtops an embankment, a 10 mm difference in water levels upstream of the embankment can create a much larger difference in levels downstream. Hence, small differences in time-stepping (along with many other aspects of model setup) can trigger local differences in model results.
• Model orientation (if changed) could also mean slight change in results. This is mostly given by interpolating values from different calculation points. Every cell has nine calculation points. Based on the model origin, all or most of the calculation points would have different topography elevation sampled, which translates to slightly different results.
• If using 1D channel, possibly different cells have been selected as HX boundary and might have different elevations. This can be reviewed in 1d_to_2d check file.

Generally, there should not be substantial differences as the fundamental equations being solved are unchanged and TUFLOW Classic and HPC solvers have always solved all the physical terms using a 2nd order spatial approach. The one exception is the turbulence (eddy viscosity) representation, which is the most complex and challenging to solve of all the physical terms (many 2D schemes simply omit this term). If significant differences (>10% of depth change across the whole model) are observed then it’s most likely due to the first four dot points above. To identify in which release(s) the significant changes occurred, the model can be run with the latest build and for past releases. The changes for each release are documented in their release notes. Past releases and release notes are all available here. Once the exact release where the changes occurred is tracked down, individual features can be turned off to narrow down the cause.

The recommendation is usually for new or reworked models to use the newest build to take advantage of the latest features and enhancements, some level of calibration might be required for reworked models. The new TUFLOW executable is not different from the previous ones in the meaning that any existing model should be re-calibrated if there are available calibration data. However, particularly if a model is already calibrated, using prior builds of TUFLOW or winding back default settings using Defaults == command is considered reasonable for established models that are to be used for minor tasks where an update of the model would not be cost effective.

How can differences in model results between TUFLOW builds be investigated?

Running TUFLOW on a later Build from which it was originally calibrated will not necessarily produce the same results, as discussed in Why are model results developed in an older release different to a newer release?.

The following is an example of steps that can be taken when upgrading a TUFLOW model’s executable Build, checking for consistency to original results each time.

1. Confirm you are able to run the original model with the original Build that would have been used to initially produce results.
   • This may be particularly relevant when a model has been externally supplied, for example from a government body.
   • Confirm if reproduced results are consistent with supplied results.
2. Run the original model with the newer Build, along with a relevant Defaults == command (e.g. Defaults == Pre 2011 when the original Build was 2010-10).
   • Any differences in results compared to the original results may highlight if there are any changes over time where no backward compatibility had been provided for.
3. Run the original model with the newer Build, and without the Defaults == command.
   • This more likely to see changes in results compared to the original results, which may require justification to the client or resolution by investigating, isolating and remedying the causes, especially if recalibration is not intended as a subsequent step.
4. Iteratively run the original model with the newer Build, stepping through the different release version options for Defaults == command.
   • This will allow the modeller to investigate and isolate what changes to TUFLOW Builds may be affecting results, and when changes appear.
   • Then, individually reverting settings that make up a Default group (see Chapter 18 of the TUFLOW Manual).
   • This can help isolate the primary drivers for any differences in results.
   • The TUFLOW Classic/HPC Changelog that accompanying Build releases are also a key reference.
5. Develop new improved or updated model version, with the newer Build (and any grouped or individual defaults that are deemed necessary to retain from the iterative testing in the prior step).
   • Continue to verify results against the original results as you then iteratively add in or update to any newer functionality or formats that may be available in the later Build, a good quality assurance check that changes are behaving as expected.

Up
Back to TUFLOW Modelling Guidance