TUFLOW Version Backward Compatibility: Difference between revisions
Content deleted Content added
Anne.Kolega (talk | contribs) |
Teegan.Burke (talk | contribs) No edit summary |
||
Line 2:
=Backward Compatibility Change Register=
==Default changes post 2017-09 Build==
<br>
'''<font color="red">For changes in defaults post the 2017-09 build, see Chapter 18 of the <u>[https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]</u>.'''</font>
<br>
==Default changes pre 2017-09 Build==
<br>
{|class="wikitable"
Line 241 ⟶ 246:
|
|}
<br>
=Frequently Asked Questions (FAQ)=
<br>
== Why are model results developed in an older release different to a newer release? ==
If comparing a Classic model with HPC, also check the <u>[[HPC_FAQ#Will_TUFLOW_HPC_and_TUFLOW_Classic_results_match.3F | Will TUFLOW HPC and TUFLOW Classic results match?]]</u> page in addition to this answer. <br>
Line 265 ⟶ 271:
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 <font color="blue"><tt>Defaults</tt></font> <font color="red"><tt>== </tt></font> 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.<br>
== 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 <u>[[TUFLOW_Version_Backward_Compatibility#Why_are_model_results_developed_in_an_older_release_different_to_a_newer_release.3F | Why are model results developed in an older release different to a newer release?]]</u>.
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.
<ol>
<li> 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.
<li> Run the original model with the newer Build, along with a relevant <font color="blue"><tt>Defaults</tt></font> <font color="red"><tt>== </tt></font> command (e.g. <font color="blue"><tt>Defaults</tt></font> <font color="red"><tt>== </tt></font> 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.
<li> Run the original model with the newer Build, and without the <font color="blue"><tt>Defaults</tt></font> <font color="red"><tt>== </tt></font> 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.
<li> Iteratively run the original model with the newer Build, stepping through the different release version options for <font color="blue"><tt>Defaults</tt></font> <font color="red"><tt>== </tt></font> 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 <u>[https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]</u>).
* This can help isolate the primary drivers for any differences in results.
* The <u>[https://www.tuflow.com/downloads/tuflow-classichpc-archive/| archived release notes/change logs]</u> that accompanying Build releases are also a key reference.
<li> 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.
</ol>
<br>
{{Tips Navigation
| |||