Tuflow - User contributions [en]

Linux Install

2026-03-29T22:39:22Z

Jaap.vandervelde: Jaap.vandervelde moved page Linux Install Draft to Linux Install without leaving a redirect: Publishing Linux install Draft

== Introduction ==
TUFLOW is installed on Linux using the <code>.rpm</code> and <code>.deb</code> installer packages, which can be [https://www.tuflow.com/downloads/#tuflow downloaded here]. There's also a tar.gz archive available from the same location, which can serve as a portable application, similar to the .zip archive available for Windows.

The installers have been tested on Rocky Linux 9 and Ubuntu 22.04, but should work on other modern Red Hat and Debian distributions.

== Codemeter Configuration ==
To provide licenses to TUFLOW on Linux install and configure the CodeMeter User Runtime Package for Linux (.rpm or .deb options are available) https://www.wibu.com/support/user/user-software.html.

* If using a hardware based usb dongle (either network or local licenses) please follow the instructions within [[Installing_Wibu_CodeMeter_Linux | Installing Wibu Codemeter Linux]].
* If using a software lock (either network or local licenses please follow the instructions within [[WIBU_Software_Licence_Linux | Wibu Software License Linux]].

== TUFLOW Versioning ==
TUFLOW uses a year.minor.patch versioning convention as follows.

* The year corresponds to the major version number e.g. 2026.0.0. Major releases are the only releases that will admit the possibility of breaking changes, which are changes in defaults or features that may change model results between versions. There is one major release per year

* Minor releases contain new features and bug fixes, but no breaking changes and increment the minor version number, e.g. 2026.1.0
* Patch releases are bug fixes only and increment the patch version number, e.g. 2026.0.1

== RPM Install ==
<ul>
<li> Download the <code>.rpm</code> for the specific TUFLOW build from https://www.tuflow.com/downloads/#tuflow
<li> Save the <code>.rpm</code> locally. A common location is the home folder for the current user <code>~/</code>
<li> Run the preferred installation command. For example, if installing the TUFLOW 2026.0.0 release:<syntaxhighlight lang="bash">
sudo dnf install ~/tuflow-2026.0-2026.0.0-1.x86_x64.rpm
</syntaxhighlight></li></ul>
<ul>
<li>This installs a version-specific copy of the TUFLOW binaries and libraries under <code>/opt/tuflow/<version>/bin</code> and <code>/opt/tuflow/<version>/lib</code>. A symbolic link to the executable is created in <code>/usr/bin</code>, allowing the required version to be run with a versioned shortcut, e.g. <code>tuflow-2026.0-isp</code>.
<li>There is also a launcher script in <code>/opt/tuflow/tuflow-<version>/bin/tuflow-<version>-idp.sh</code> for use cases where some environment variables needs to be set before execution. If you need to edit these, we recommend copying these into <code>/usr/local/bin</code>, as they will be overwritten if a patch release is installed.
<li>To uninstall run the preferred uninstaller command. For example:<syntaxhighlight lang="bash">
sudo dnf remove tuflow-2026.0
</syntaxhighlight></li><li>To return a list of previously installed versions and review the correct uninstall version use <code>dnf list installed</code>'', or <code>dnf list installed 'tuflow*'</code>''</li></ul>''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== DEB Install ==
The process for <code>.deb</code> is essentially the same as the <code>.rpm</code> steps 2-5. For steps 3 and 5, the install and uninstall command examples below are for Debian derivatives. For example (assuming TUFLOW 2026.0.0, modify for the specific version required):

To install:
sudo apt install ./tuflow-2026.0_2026.0.0-1_amd64.deb

To uninstall:
sudo apt remove tuflow-2026.0
If unsure about which versions you have previously installed you can return a list of all the installed versions via:
apt list --installed | grep tuflow
''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== Notes for Running TUFLOW Under WSL ==
If you are running a Linux installation with Microsoft Windows under WSL (Windows Subsystem for Linux), things should run as expected. If you want to use NVIDIA hardware with CUDA support with TUFLOW under WSL, you need to add the correct folder to the LD_LIBRARY_PATH environment variable, so that TUFLOW can find the correct CUDA shared libraries that work in WSL:
export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH
In that folder there's a utility <code>/usr/lib/wsl/lib/nvidia-smi</code> which will indicate if the Linux installation can connect to the NVIDIA hardware otherwise managed by the Microsoft Windows driver.

== Running a Model ==
For either Linux distribution TUFLOW can be run by calling <code>tuflow-2026.0-isp</code> (this example would the currently installed patch for version 2026.0 and single precision) and by passing it a configuration file name:<syntaxhighlight lang="bash">
tuflow-2026.0-isp my_run.tcf
</syntaxhighlight>Model-specific commands such as the <code>export OMP_NUM_THREADS</code> environment variable can either be added via the command line, or in your own custom run script that calls the configuration file name, for example ''<code>run_model.sh</code>'':<syntaxhighlight lang="bash">
#!/bin/bash
export OMP_NUM_THREADS=8
tuflow-2026.0-idp my_run.tfc

</syntaxhighlight>Once saved the script will need to be configured to run as an executable as follows:<syntaxhighlight lang="bash">
chmod +x run_model.sh
</syntaxhighlight>

== Return to Home Page ==
Return to [[Main_Page | Wiki Home Page]].

Linux Install

2026-03-27T08:04:25Z

Jaap.vandervelde: spelling

Linux Install

2026-03-27T08:03:21Z

Jaap.vandervelde: various minor corrections, match other wiki

== Introduction ==
TUFLOW is installed on Linux using the <code>.rpm</code> and <code>.deb</code> installer packages, which can be [https://www.tuflow.com/downloads/#tuflow downloaded here]. There's also a tar.gz archive available from the same location, which can serve as a portable application, similar to the .zip archive available for Windows.

The installers have been tested on Rocky Linux 9 and Ubuntu 22.04, but should work on other modern Red Hat and Debian distributions.

== Codemeter Configuration ==
To provide licenses to TUFLOW on Linux install and configure the CodeMeter User Runtime Package for Linux (.rpm or .deb options are available) https://www.wibu.com/support/user/user-software.html.

* If using a hardware based usb dongle (either network or local licenses) please follow the instructions within [[Installing_Wibu_CodeMeter_Linux | Installing Wibu Codemeter Linux]].
* If using a software lock (either network or local licenses please follow the instructions within [[WIBU_Software_Licence_Linux | Wibu Software License Linux]].

== TUFLOW Versioning ==
TUFLOW uses a year.minor.patch versioning convention as follows.

* The year corresponds to the major version number e.g. 2026.0.0. Major releases are the only releases that will admit the possibility of breaking changes, which are changes in defaults or features that may change model results between versions. There is one major release per year

* Minor releases contain new features and bug fixes, but no breaking changes and increment the minor version number, e.g. 2026.1.0
* Patch releases are bug fixes only and increment the patch version number, e.g. 2026.0.1

== RPM Install ==
<ul>
<li> Download the <code>.rpm</code> for the specific TUFLOW build from https://www.tuflow.com/downloads/#tuflow
<li> Save the <code>.rpm</code> locally. A common location is the home folder for the current user <code>~/</code>
<li> Run the preferred installation command. For example, if installing the TUFLOW 2026.0.0 release:<syntaxhighlight lang="bash">
sudo dnf install ~/tuflow-2026.0-2026.0.0-1.x86_x64.rpm
</syntaxhighlight></li></ul>
<ul>
<li>This installs a version-specific copy of the TUFLOW binaries and libraries under <code>/opt/tuflow/<version>/bin</code> and <code>/opt/tuflow/<version>/lib</code>. A symbolic link to the executable is created in <code>/usr/bin</code>, allowing the required version to be run with a versioned shortcut, e.g. <code>tuflow-2026.0-isp</code>.
<li>There is also a launcher script in <code>/opt/tuflow/tuflow-<version>/bin/tuflow-<version>-idp.sh</code> for use cases where some environment variables needs to be set before execution. If you need to edit these, we recommend copying these into <code>/usr/local/bin</code>, as they will be overwritten if a patch release is installed.
<li>To uninstall run the preferred uninstaller command. For example:<syntaxhighlight lang="bash">
sudo dnf remove tuflow-2026.0
</syntaxhighlight></li><li>To return a list of previously installed versions and review the correct uninstall version use <code>dnf list installed</code>'', or <code>dnf list installed 'tuflow*'</code>''</li></ul>''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== DEB Install ==
The process for <code>.deb</code> is essentially the same as the <code>.rpm</code> steps 2-5. For steps 3 and 5, the install and uninstall command examples below are for Debian derivatives. For example (assuming TUFLOW 2026.0.0, modify for the specific version required):

To install:
sudo apt install ./tuflow-2026.0_2026.0.0-1_amd64.deb

To uninstall:
sudo apt remove tuflow-2026.0
If unsure about which versions you have previously installed you can return a list of all the installed versions via:
apt list --installed | grep tuflow
''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== Notes For Running TUFLOW Under WSL ==
If you are running a Linux installation with Microsoft Windows under WSL (Windows Subsystem for Linux), things should run as expected. If you want to use NVIDIA hardware with CUDA support with TUFLOW under WSL, you need to add the correct folder to the LD_LIBRARY_PATH environment variable, so that TUFLOW can find the correct CUDA shared libraries that work in WSL:
export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH
In that folder there's a utility <code>/usr/lib/wsl/lib/nvidia-smi</code> which will indicate if the Linux installation can connect to the NVIDIA hardware otherwise managed by the Microsoft Windows driver.

== Running A Model ==
For either Linux distribution TUFLOW can be run by calling <code>tuflow-2026.0-isp</code> (this example would the currently installed patch for version 2026.0 and single precision) and by passing it a configuration file name:<syntaxhighlight lang="bash">
tuflow-2026.0-isp my_run.tcf
</syntaxhighlight>Model-specific commands such as the <code>export OMP_NUM_THREADS</code> environment variable can either be added via the command line, or in your own custom run script that calls the configuration file name, for example ''<code>run_model.sh</code>'':<syntaxhighlight lang="bash">
#!/bin/bash
export OMP_NUM_THREADS=8
tuflow-2026.0-idp my_run.tfc

</syntaxhighlight>Once saved the script will need to be configured to run as an executable as follows:<syntaxhighlight lang="bash">
chmod +x run_model.sh
</syntaxhighlight>

== Return To Home Page ==
Return to [[Main_Page | Wiki Home Page]].

Linux Install

2026-03-27T07:47:58Z

Jaap.vandervelde: a few minor corrections, and reformatting of code examples

== Introduction ==
TUFLOW is installed on Linux using the <code>.rpm</code> and <code>.deb</code> installer packages, which can be [https://www.tuflow.com/downloads/#tuflow downloaded here]. There's also a tar.gz archive available from the same location, which can serve as a portable application, similar to the .zip archive available for Windows.

The installers have been tested on Rocky Linux 9 and Ubuntu 22.04, but should work on other modern Red Hat and Debian distributions.

== Codemeter Configuration ==
To license TUFLOW on Linux install and configure CodeMeter User Runtime Package for Linux (.rpm or .deb options are available) https://www.wibu.com/support/user/user-software.html.

* If using a hardware based usb dongle (either network or local licenses) please follow the instructions within [[Installing_Wibu_CodeMeter_Linux | Installing Wibu Codemeter Linux]].
* If using a software lock (either network or local licenses please follow the instructions within [[WIBU_Software_Licence_Linux | Wibu Software License Linux]].

== TUFLOW Versioning ==
TUFLOW uses a year.minor.patch versioning convention as follows.

* The year corresponds to the major version number e.g. 2026.0.0. Major releases are the only releases that will admit the possibility of breaking changes, which are changes in defaults or features that may change model results between versions. There is one major release per year

* Minor releases contain new features and bug fixes, but no breaking changes and increment the minor version number, e.g. 2026.1.0
* Patch releases are bug fixes only and increment the patch version number, e.g. 2026.0.1

== RPM Install ==
<ul>
<li> Download the <code>.rpm</code> for the specific TUFLOW build from https://www.tuflow.com/downloads/#tuflow
<li> Save the <code>.rpm</code> locally. A common location is the home folder for the current user <code>~/</code>
<li> Run the preferred installation command. For example, if installing the TUFLOW 2026.0.0 release:<syntaxhighlight lang="bash">
sudo dnf install ~/tuflow-2026.0-2026.0.0-1.x86_x64.rpm
</syntaxhighlight></li></ul>
<ul>
<li>This installs a version-specific copy of the TUFLOW binaries and libraries under <code>/opt/tuflow/<version>/bin</code> and <code>/opt/tuflow/<version>/lib</code>. A symbolic link to the executable is created in <code>/usr/bin</code>, allowing the required version to be run with a versioned shortcut, e.g. <code>tuflow-2026.0-isp</code>.
<li>There is also a launcher script in <code>/opt/tuflow/tuflow-<version>/bin/tuflow-<version>-idp.sh</code> for use cases where some environment variables needs to be set before execution. If you need to edit these, we recommend copying these into <code>/usr/local/bin</code>, as they will be overwritten if a patch release is installed.
<li>To uninstall run the preferred uninstaller command. For example:<syntaxhighlight lang="bash">
sudo dnf remove tuflow-2026.0
</syntaxhighlight></li><li>To return a list of previously installed versions and review the correct uninstall version use <code>dnf list installed</code>'', or <code>dnf list installed 'tuflow*'</code>''</li></ul>''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== DEB Install ==
The process for <code>.deb</code> is essentially the same as the <code>.rpm</code> steps 2-5. For steps 3 and 5, the install and uninstall command examples below are for Debian derivatives. For example (assuming TUFLOW 2026.0.0, modify for the specific version required):

To install:
sudo apt install ./tuflow-2026.0_2026.0.0-1_amd64.deb

To uninstall:
sudo apt remove tuflow-2026.0
If unsure about which versions you have previously installed you can return a list of all the installed versions via:
apt list --installed | grep tuflow
''Note: Major and minor releases are installed with a new directory under <code>/opt/tuflow</code>. For example, TUFLOW 2026.0.0 is installed under <code>/opt/tuflow/tuflow-2026.0</code>. Patch releases overwrite the existing installation that shares the same major and minor release number. For example, TUFLOW 2026.0.1 will update 2026.0.0 if present.''

== Notes For Running Linux Under WSL ==
If you are running a Linux installation with Microsoft Windows under WSL (Windows Subsystem for Linux), things should run as expected. If you want to use NVIDIA hardware with CUDA support with TUFLOW under WSL, you need to add the correct folder to the LD_LIBRARY_PATH environment variable, so that TUFLOW can find the correct CUDA shared libraries that works in WSL:
export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH
In that folder there's a utility <code>/usr/lib/wsl/lib/nvidia-smi</code> which will indicate if the Linux installation can connect to the NVIDIA hardware otherwise managed by the Microsoft Windows driver.

== Running A Model ==
For either Linux distribution TUFLOW can be run by calling <code>tuflow-2026.0-isp</code> (this example would the currently installed patch for version 2026.0 and single precision) and by passing it a configuration file name:<syntaxhighlight lang="bash">
tuflow-2026.0-isp my_run.tcf
</syntaxhighlight>Model-specific commands such as the <code>export OMP_NUM_THREADS</code> environment variable can either be added via the command line, or in your own custom run script that calls the configuration file name, for example ''<code>run_model.sh</code>'':<syntaxhighlight lang="bash">
#!/bin/bash
export OMP_NUM_THREADS=8
tuflow-2026.0-idp my_run.tfc

</syntaxhighlight>Once saved the script will need to be configured to run as an executable as follows:<syntaxhighlight lang="bash">
chmod +x run_model.sh
</syntaxhighlight>

== Return To Home Page ==
Return to [[Main_Page | Wiki Home Page]].

Installing Wibu CodeMeter Linux

2026-03-27T01:58:06Z

Jaap.vandervelde: modernise and align with other wiki

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at https://www.wibu.com/support/user/user-software.html.

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS, Rocky, or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. Download the 64-bit version for use with 64-bit TUFLOW (all modern versions are). From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat you can install the CodeMeter Runtime with <pre>sudo dnf install ./codemeter.rpm</pre>

On Debian you can install the CodeMeter Runtime with <pre>sudo apt install ./codemeter.deb</pre> If that fails due to missing dependencies, you can attempt <pre>sudo apt install -f</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, try: <pre>sudo /etc/init.d/codemeter restart</pre>

== Configuring Codemeter Runtime for Server Host ==
Turn off codemeter service (Note: If this is not completed you will not be able to edit the config files):<pre>sudo systemctl stop codemeter.service</pre>Open <code>/etc/wibu/CodeMeter/Server.ini</code> with write access.

Within Server.ini set: <code>IsNetworkServer=1</code>

Restart the CodeMeter service:<pre>sudo systemctl start codemeter.service</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22350/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<syntaxhighlight lang="bash">
sudo ufw allow 22350/tcp
</syntaxhighlight>

Alternatively, if `ufw` is not available to you, try:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

Similarly, if you want users to be able to access the web admin interface for CodeMeter on the server, you need to ensure the firewall allows request on port 22352 (for http) and/or 22353 (for https). However, access to the web admin interface from other machines is not required for obtaining a license and in typical configurations, you would be able to access the web admin interface on the host itself (localhost) without additional firewall rules.

WIBU Licence for Linux

2026-03-27T01:31:26Z

Jaap.vandervelde: fix mixed RHEL / Debian syntax

For the process of requesting a Wibu-Systems Software License for a ''Windows'' licence host, please refer to [[WIBU Licence Update Request|Wibu Software Licence Update Request]]. This article describes the process of setting up a software licence container and installing licence updates from a Linux command line interface, like one you would access on an SSH console. It applies to both Local and Network software licences, not cloud-based licences.

The Linux commands used on this wiki should work on most modern Linux distributions but were tested on CentOS and Debian. This article assumes you have downloaded and installed an appropriate version of the [https://www.wibu.com/support/user/user-software.html CodeMeter Runtime (download)] for your Linux host and CodeMeter is running as a service. If you are uncertain, you can run <pre>systemctl | grep codemeter</pre> and you should see both `codemeter.service` and `codemeter-webadmin.service` as `running` or `exited`. For the CodeMeter service, you can also check <pre>systemctl status codemeter.service</pre> which should report CodeMeter Server as running. By default, your CodeMeter Control Center web application would be hosted on http://<your hostname>:22352/ or https://<your hostname>:22353/ and accessible from http://<your hostname>:22350/.

For a basic setup of CodeMeter on Linux, refer to [[Installing_Wibu_CodeMeter_Linux | Installing Wibu CodeMeter on Linux]].

Software licences are an alternative option to hardware USB dongle licences. Please select the licence host carefully as a software-based dongle will be bound to it when it is first imported. If over time you decide you want to move to another computer, we will need to re-issue you with a new software licence (which will incur a small administration fee).

== Setting up a new software licence container ==

Email [mailto:sales@tuflow.com sales@tuflow.com] to request a software licence. You will be sent an empty licence container file (*.WibuCmLif).

Install the licence container file with:
<pre>cmu --import --file Universal_Firm_Code_CmActLicense_6000224.WibuCmLif</pre>
Which should result in something like:
<pre>cmu - CodeMeter Universal Support Tool.
Version 6.60a of 2018-Feb-26 (Build 2878) for Linux
Copyright (C) 2007-2018 by WIBU-SYSTEMS AG. All rights reserved.

The file contains 1 Update:
CmActLtLicense binding information: FirmCode 6000224

Execute Update ...
The file contains 1 Update:
CmActLtLicense update: Serial number xxx-xxxxxxxxxx, FirmCode 6000224.
--> successful
1 successful update done</pre>

After installing the licence container file, the CodeMeter WebAdmin interface may report an error if you try to check the new container (e.g. 'Error 407: Unknown error'). This can be resolved by restarting the CodeMeter service after installing the licence container:
<pre>sudo systemctl restart codemeter.service</pre>

Make a note of the serial number displayed. You can list serial numbers of installed dongles and software licence containers with the command:
<pre>cmu --list</pre>

== Updating licences in an existing licence container ==

Once you have an existing licence container for either local or network licences, you can update it with licences by first creating a licence update request.

For hardware-based licences, on a dongle:<pre>cmu --context 101139 --serial x-xxxxxxx --file x-xxxxxxx.WibuCmRaC</pre>For software-based licences:<pre>cmu --context 6000224 --serial xxx-xxxxxxxxxx --file xxx-xxxxxxxxxx.WibuCmRaC</pre>Where "xxx-xxxxxxxxxx" / "x-xxxxxxxxxx" is the serial number of your licence container. E-mail the created licence request file (.WibuCmRaC) file to [mailto:sales@tuflow.com sales@tuflow.com].

Once your licence request is processed, you will receive a licence update file (.WibuCmRaU) in return, which you can install with
<pre>cmu --import --file <serial>.WibuCmRaU</pre>
Which should result in something like (this example for a software-based licence):
<pre>cmu - CodeMeter Universal Support Tool.
Version 6.60a of 2018-Feb-26 (Build 2878) for Linux
Copyright (C) 2007-2018 by WIBU-SYSTEMS AG. All rights reserved.

The file contains 1 Updates:
CmActLtLicense binding information: FirmCode 6000224
CmDongle update for 130-3796453031 (FirmCode 6000224).

Execute Update ...
The file contains 1 Updates:
CmActLtLicense update: Serial number xxx-xxxxxxxxxx, FirmCode 6000224.
--> successful
1 successful update done</pre>

Once your licence update has been imported, you should see your installed licences in the CodeMeter WebAdmin. If they fail to show up, restart the CodeMeter Service:
<pre>sudo systemctl restart codemeter.service</pre>
==Using the installed licenses==
If you are running a model on another machine and have installed the license on a remote license host, refer to [[WIBU_Configure_Network_Server|Wibu Configure Network Server]] and [[WIBU_Configure_Network_Client|Wibu_Configure Network Client]] to learn how to connect to it.

If the software license container is the only license container (i.e. you have no dongle installed), you can test using the installed license by simply starting a model run that requires it (i.e. some run other than a benchmark or tutorial model).

However, if you have both a dongle and software license container installed, you can ensure TUFLOW prefers the software license by creating a license control file (.lcf) for your model, with the line: <pre>WIBU Firm Code Search Order == 6000224 101139</pre> This ensures that TUFLOW will prefer a software license container (6000224) over a dongle license container (101139) to obtain a license. You can learn more about where such a file can be placed and what the followed logic for obtaining a license is in the [https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual].

WIBU Licence for Linux

2026-03-27T01:13:20Z

Jaap.vandervelde: Reviewed, corrected errors on licence types, aligned with other wiki

For the process of requesting a Wibu-Systems Software License for a ''Windows'' licence host, please refer to [[WIBU Licence Update Request|Wibu Software Licence Update Request]]. This article describes the process of setting up a software licence container and installing licence updates from a Linux command line interface, like one you would access on an SSH console. It applies to both Local and Network software licences, not cloud-based licences.

The Linux commands used on this wiki should work on most modern Linux distributions but were tested on CentOS and Debian. This article assumes you have downloaded and installed an appropriate version of the [https://www.wibu.com/support/user/user-software.html CodeMeter Runtime (download)] for your Linux host and CodeMeter is running as a service. If you are uncertain, you can run <pre>systemctl | grep codemeter</pre> and you should see both `codemeter.service` and `codemeter-webadmin.service` as `running` or `exited`. For the CodeMeter service, you can also check <pre>/etc/init.d/codemeter status</pre> which should report "CodeMeter Server is running.". By default, your CodeMeter Control Center web application would be hosted on http://<your hostname>:22352/ or https://<your hostname>:22353/ and accessible from http://<your hostname>:22350/.

For a basic setup of CodeMeter on Linux, refer to [[Installing_Wibu_CodeMeter_Linux | Installing Wibu CodeMeter on Linux]].

Software licences are an alternative option to hardware USB dongle licences. Please select the licence host carefully as a software-based dongle will be bound to it when it is first imported. If over time you decide you want to move to another computer, we will need to re-issue you with a new software licence (which will incur a small administration fee).

== Setting up a new software licence container ==

Email [mailto:sales@tuflow.com sales@tuflow.com] to request a software licence. You will be sent an empty licence container file (*.WibuCmLif).

Install the licence container file with:
<pre>cmu --import --file Universal_Firm_Code_CmActLicense_6000224.WibuCmLif</pre>
Which should result in something like:
<pre>cmu - CodeMeter Universal Support Tool.
Version 6.60a of 2018-Feb-26 (Build 2878) for Linux
Copyright (C) 2007-2018 by WIBU-SYSTEMS AG. All rights reserved.

The file contains 1 Update:
CmActLtLicense binding information: FirmCode 6000224

Execute Update ...
The file contains 1 Update:
CmActLtLicense update: Serial number xxx-xxxxxxxxxx, FirmCode 6000224.
--> successful
1 successful update done</pre>

After installing the licence container file, the CodeMeter WebAdmin interface may report an error if you try to check the new container (e.g. 'Error 407: Unknown error'). This can be resolved by restarting the CodeMeter service after installing the licence container:
<pre>sudo systemctl restart codemeter.service</pre>

Make a note of the serial number displayed. You can list serial numbers of installed dongles and software licence containers with the command:
<pre>cmu --list</pre>

== Updating licences in an existing licence container ==

Once you have an existing licence container for either local or network licences, you can update it with licences by first creating a licence update request.

For hardware-based licences, on a dongle:<pre>cmu --context 101139 --serial x-xxxxxxx --file x-xxxxxxx.WibuCmRaC</pre>For software-based licences:<pre>cmu --context 6000224 --serial xxx-xxxxxxxxxx --file xxx-xxxxxxxxxx.WibuCmRaC</pre>Where "xxx-xxxxxxxxxx" / "x-xxxxxxxxxx" is the serial number of your licence container. E-mail the created licence request file (.WibuCmRaC) file to [mailto:sales@tuflow.com sales@tuflow.com].

Once your licence request is processed, you will receive a licence update file (.WibuCmRaU) in return, which you can install with
<pre>cmu --import --file <serial>.WibuCmRaU</pre>
Which should result in something like (this example for a software-based licence):
<pre>cmu - CodeMeter Universal Support Tool.
Version 6.60a of 2018-Feb-26 (Build 2878) for Linux
Copyright (C) 2007-2018 by WIBU-SYSTEMS AG. All rights reserved.

The file contains 1 Updates:
CmActLtLicense binding information: FirmCode 6000224
CmDongle update for 130-3796453031 (FirmCode 6000224).

Execute Update ...
The file contains 1 Updates:
CmActLtLicense update: Serial number xxx-xxxxxxxxxx, FirmCode 6000224.
--> successful
1 successful update done</pre>

Once your licence update has been imported, you should see your installed licences in the CodeMeter WebAdmin. If they fail to show up, restart the CodeMeter Service:
<pre>sudo systemctl restart codemeter.service</pre> or <pre>sudo /etc/init.d/codemeter restart</pre>

==Using the installed licenses==
If you are running a model on another machine and have installed the license on a remote license host, refer to [[WIBU_Configure_Network_Server|Wibu Configure Network Server]] and [[WIBU_Configure_Network_Client|Wibu_Configure Network Client]] to learn how to connect to it.

If the software license container is the only license container (i.e. you have no dongle installed), you can test using the installed license by simply starting a model run that requires it (i.e. some run other than a benchmark or tutorial model).

However, if you have both a dongle and software license container installed, you can ensure TUFLOW prefers the software license by creating a license control file (.lcf) for your model, with the line: <pre>WIBU Firm Code Search Order == 6000224 101139</pre> This ensures that TUFLOW will prefer a software license container (6000224) over a dongle license container (101139) to obtain a license. You can learn more about where such a file can be placed and what the followed logic for obtaining a license is in the [https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual].

Hardware Selection Advice

2026-03-23T04:33:38Z

Jaap.vandervelde: Removing statement on misinformation, added links, made testing advice specific to non-ECC memory

This page provides general hardware advice for running TUFLOW models on GPU or CPU. 
[[File: Hardware_Configuration_001.jpg ||450px|right]]

=Introduction=
We often get asked about the optimum computing setup to run TUFLOW models. While every model is different and will interact differently with your hardware there is some general advice that we can offer. Note that recommendations focus specifically on running TUFLOW. It is highly recommend to consult your IT team to confirm that all components of the machine are fully capable of supporting your intended uses and meet your requirements for quality, speed, and durability. 

In the sections below you will find more detailed advice on GPU and CPU but generally: 

* The amount of RAM in the computer will be the limiter for the size of model you can run. This applies to CPU RAM (TUFLOW Classic, TUFLOW FV and TUFLOW HPC with Hardware == CPU) and also GPU RAM (TUFLOW HPC and TUFLOW FV with Hardware == GPU). If available RAM becomes a limitation, users should also investigate improvements to their model configuration to reduce RAM requirements (see [[TUFLOW Simulation Speed | TUFLOW Simulation Speed]]).

* The processing speed of the CPU, the architecture, cache size, speed and number of processors play a role.
* For GPU simulations, the number of CUDA cores, the core speed, GPU card architecture, memory speed and interfacing with the motherboard PCI lanes and CPU are all important.
* The system must be well cooled to avoid throttling (meaning reduction of clock speeds to reduce heating), and have sufficient and reliable power supply. Should upgrades to the system be expected in the future (such as adding a second GPU card), then consider configuring these components to avoid future limitations. 
For information on minimum and recommended system requirement, see [[System_Requirements | System Requirements]].

To discover a computer's NVIDIA GPU hardware, see [[Console_Window_GPU_Usage | NVIDIA GPU Hardware and Usage]]. 

=The TUFLOW Software Suite=
The TUFLOW Software suite has a range of solvers. Each interact differently with your hardware so pairing the correct solver (or the range of solvers you want to run) and hardware is an important consideration. A brief summary of each solver's needs is provided as follows: 
*TUFLOW Classic: A single model run can only use the CPU and cannot be run across multiple CPU cores or GPU hardware. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, architecture and cache size.
* TUFLOW HPC - Run on CPU Hardware: A single model run uses the CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, the number of cores available to be run in parallel, architecture and cache size.
*TUFLOW HPC - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW HPC requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute.
*TUFLOW FV - Run on CPU Hardware: A single model run uses CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is determined by the CPU speed, the number of cores available to be run in parallel, chip architecture and cache size.
*TUFLOW FV - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW FV requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute. 

The [[Hardware_Benchmarking_-_Results#CPU_Results | Hardware Benchmarking]] page shows recently run combinations of GPU, CPU and RAM. These can be compared with the system intended for purchase. The recommendation is to seek advise from an appropriate computer hardware vendor who can advise on the compatibility and optimisation of the setup.

=GPU Advice=
TUFLOW HPC on GPU Hardware is typically our fastest solver for 1D/2D pipe and floodplain simulations.
* TUFLOW HPC supports CUDA enabled NVIDIA GPU cards. For list of supported CUDA enabled graphics cards please visit the [https://developer.nvidia.com/cuda-gpus NVIDIA website].
*To discover a computer's NVIDIA GPU hardware, see [[Console_Window_GPU_Usage | NVIDIA GPU Hardware and Usage]].
*TUFLOW HPC on GPU Hardware can be run in either single or double precision. However, for the vast majority of flood applications single precision is sufficient. We typically run our models on single precision. If you are unsure we recommend running with both the single and double precision solvers and comparing your results.
The precision solver you require will determine the type of GPU card that is best suited for your compute. For any given generation/architecture of cards, the “gaming” cards such as the GTX GeForce and RTX provide excellent single precision performance – typically comparable to that of the “scientific” cards such as the Tesla series. If double precision is required then the scientific cards are substantially faster, but these are also significantly more expensive. The Quadro series cards sit in between for both double precision performance and cost. When checking the specifications of the card it should provide you with a breakdown of the single and double precision throughput in flops. Single precision compute is typically sufficient for TUFLOW HPC modelling.

For the higher end GPU cards, users may wish to consider server-based computers rather than workstations, and also weigh the cost of an extra TUFLOW licence against the cost of the high end hardware.

===GPU RAM===
RAM is the computer memory required to store all of the model data used during the computation. A computer has CPU RAM which is located on the motherboard and accessed from the CPU, and it has GPU RAM which is located on the GPU device and accessed from the GPU. The two memory storage systems are physically separate.
The amount of GPU RAM is one of two factors that will determine the size of the model that can be run (the other being CPU RAM). As a rule of thumb, approximately 5 million cells can be run per gigabyte (GB) of GPU RAM depending on the model features, e.g. a model with infiltration requires more memory due to the extra variables needed for the infiltration calculation.

===CPU RAM===
TUFLOW HPC on GPU hardware still uses the CPU to compute and store data (in CPU RAM) during model initialisation and for all 1D calculations. While we are working on improving our CPU RAM usage, currently we tend to find that CPU RAM is often the limiter to the size of the model domain you can run, particularly if using running over multiple GPU cards. During initialisation and simulation a model will typically require 4-6 times the amount of CPU RAM relative to GPU RAM. As an example, a model that utilises 11GB of GPU RAM (typical memory for high-end gaming card, and corresponds to about a 50 million cell model) the CPU RAM required during initialisation will typically be in range 44GB to 66GB. A model that fully utilises two 11 GB GPUs (i.e. a 100 million cell model) may require as much as 128GB of CPU RAM during initialisation. Note that anything more than 256GB of CPU RAM will exceed the limitations of consumer chipsets that are available in 2025 and requires more expensive workstation hardware - additionally, users should consult a hardware expert to check limitations of specific hardware.

=== RAM Reliability (ECC vs non-ECC) ===
ECC (Error-Correcting Code) RAM detects and corrects memory errors, improving reliability, while non-ECC cannot. Use of non-ECC memory may raise worries about global error rates affecting simulation results. However, large [https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf field studies] show errors are usually caused by physical faults in specific DIMMs (Dual In-line Memory Modules, the removable RAM sticks), not uniform random events. Most DIMMs experience no errors, while a small number produce the vast majority of faults. Modern DDR5 memory also includes on-die correction that silently fixes some errors before they leave the chip.

A failing DIMM on a non-ECC system is more likely to cause crashes or obvious corruption than a silent incorrect result. In numerical solvers, bit flips often trigger instability or failure rather than plausible but wrong outputs. For a single TUFLOW workstation, ECC is generally not required solely to protect result quality, though it may be beneficial for servers, critical workloads, or environments operating many machines.

If additional confidence is desired, run a memory test (for example [https://www.memtest.org/ Memtest86+]) for multiple passes after installation, for non-ECC memory. Consistent errors indicate defective hardware that should be replaced.

===CUDA Cores, GPU Clock speed, and FLOPs ===
One way of reporting a GPU card's throughput is in Floating Point Operations per second (FLOPs). The more FLOPs, the more calculations that can get crunched per second and the faster the model should run. For any given generation of GPU, FLOPs are approximately proportional to number of CUDA cores times the GPU clock speed. However, there have been significant improvements in GPU architecture since the inception of CUDA, and this has contributed to increases in overall FLOPs performance beyond just the increases in cores and clock speed that have occurred over this time.

===Multiple GPUs===
TUFLOW can use multiple GPU cards on a machine to run a single model (TUFLOW FV can currently use a single GPU only). This is useful for models that are too large for a single GPU, or for running a model as quickly as possible. In general terms the run time benefit of using multiple cards increases with model size.
*TUFLOW HPC-GPU does not support SLI for inter-GPU communications.
*It does (as of build 2020-01-AA) auto detect and utilise peer-to-peer access over NVLink or PCI bus on the motherboard. Note that not all GPUs support peer-to-peer access.
**PCI bus - this method requires cards that supports TCC driver mode and all cards must be in TCC driver mode. As TUFLOW primarily relies on GPU CUDA capabilities, the impact of using higher or lower PCI slot option is minimal.
**NVLink - high-end compute cards can have up to 8 cards talking to each other through a high-spec NVLink, but many of the less expensive cards are limited to only having two connected together over a dual socket NVLink.
*Models may still be run across multiple GPUs even if a NVLink is not present and the GPUs do not support peer-to-peer access. In this case HPC reverts to exchanging the domain boundary data between the GPUs via the CPU. The memory bandwidth between the GPU and the main system is not a critical bottleneck for TUFLOW.
*When using multiple GPUs it is best to use cards of similar memory and performance. While it is possible (as of build 2020-01-AA) to re-balance a model over multiple GPUs, we do not recommend using cards with vastly disparate performance.
*Sufficient cooling and power supply should be considered if multiple cards are used. When installed in adjacent PCI slots, the preference is to use rear vented cards rather than side vented to avoid blowing hot air onto the neighbouring cards (which could lead to overheating).

===GPU Performance Comparison===
Extensive GPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking | Hardware Benchmarking]] page. Review the GPU benchmarking runtime results table to compare the speed performance of different cards. If your GPU card is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to [mailto:support@tuflow.com support@tuflow.com]. We will add the details to the runtime results table. 

External videocard benchmark websites can be used to compare GPU cards, for example, [https://www.videocardbenchmark.net/high_end_gpus.html PassMark Software - Video Card (GPU) Benchmarks] is an excellent performance guide. Note that PassMark may not be representative for the highest end cards, for TUFLOW. GPU are complex devices, newer cards may not perform as well on PassMark's benchmarks for criteria consumers buy GPUs for (games, video editing, etc.), even though the cards may well perform a lot better for TUFLOW.
 

=CPU Advice=
In general terms a more recent architecture, higher clock speed CPU with a large cache will perform better than a slower clock speed chip. This section discusses CPU RAM, RAM speed, Processor frequency, Multi-core processing and hyper-threading.

===CPU RAM===
The amount of CPU RAM will determine the size of the model that can be run or a number of models that can be run at one time.
Faster RAM will result in quicker runtimes, however this is usually a secondary consideration to chip speed, cache size and architecture.

===CPU Cores ===
*TUFLOW HPC - Run on GPU Hardware: The parallel processing is being done on the GPU card. However, TUFLOW HPC-GPU still uses the CPU for model initialisation and for 1D calculations. If multiple GPU cards are used, TUFLOW will use the equivalent number of CPU threads for controlling the GPUs and migrating data. So for a machine dedicated to HPC-GPU modelling, the number of CPU cores should be higher than the number of installed GPUs.
*TUFLOW HPC - Run on CPU Hardware: HPC model can also be run on multiple CPU cores. For the comparison of simulation speed, please refer to [[Hardware_Benchmarking_Topic_HPC_on_CPU_vs_GPU | HPC on CPU vs GPU]].
*TUFLOW Classic: TUFLOW Classic simulation can only use one CPU core due to the implicit nature of the numerical solution. More CPU cores will enable running more simulations at the same time most efficiently.

===Hyperthreading===
https://fvwiki.tuflow.com/index.php?title=TUFLOW_FV_Parallel_Computing

===Processor Frequency and RAM Frequency===
The frequency directly affects the run times. In general, the higher the frequency, the faster the model runs.

===CPU Performance Comparison===
Extensive CPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking| Hardware Benchmarking]] page of the Wiki. Review the CPU benchmarking runtime results table to compare the speed performance of different chips. If your chip is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to [mailto:support@tuflow.com support@tuflow.com]. We will add the details to the runtime results table.
 

=Storage Advice=
Solid state hard drives are preferred for temporary storage as they are faster to write to than traditional hard drives. Large data files can then be transferred to a more permanent location. 
 

{{Tips Navigation
|uplink=[[Main_Page| TUFLOW Main Page]]
}}

TUFLOW on Linux

2025-11-17T06:17:52Z

Jaap.vandervelde: First draft of an article for release alongside 2026.0

= Introduction =
Starting at version 2026.0, TUFLOW Classic/HPC will also be available for Linux, just like TUFLOW FV has been since its inception. Although the application functions the same on either Microsoft Windows or Linux, there are some caveats to consider especially when working across both platforms within a single project.

= How to install =
TUFLOW for Linux will be made available in two types of packages, <code>.deb</code> for Debian family distributions (like Debian, Ubuntu, Mint, etc.) and <code>.rpm</code> for RHEL family distributions (Red Hat, CentOS, Rocky, etc.).

These can be downloaded and installed with tools that are available on any Linux distribution by default. It is recommended that admins use <code>dnf</code> or <code>apt</code> respectively, to ensure that dependencies are automatically downloaded and installed as needed.

= How to use =
After installation, TUFLOW will be available from the command line as <code>tuflow_2026.0</code>. Users may define an alias like <code>alias tuflow='tuflow_2026.0'</code> or use the specific versioned command directly in their scripts. Command-line options are passed just as in Windows.

However, because Linux often runs without a graphical environment, TUFLOW on Linux runs as if the <code>-nmb</code> option was provided.

= Use across both Microsoft Windows and Linux =
Some of the quirky differences between Windows and Linux will affect users that want to use TUFLOW across both systems.

By no means a complete overview, but these are some aspects to consider:
<ol>
*'''Slashes and backslashes''' Windows uses backslashes in file and directory paths like <code>D:\Project\results\</code>. Linux uses forward slashes instead like <code>~/Project/results</code> and will often interpret characters following backslashes as special characters. TUFLOW will usually deal with either format on either system in configuration files, but when writing scripts or commands users should remain aware. Also, logs and outputs referring to files will use the format appropriate to the system it is running on.
*'''Drive letters''' Drive letters like <code>D:</code> are specific to Windows. Configuration files that need to be usable across both systems should avoid their use and instead use relative paths like <code>../Model/Materials_001.csv</code> or absolute paths that assume the file is on the current drive like <code>/Project/model/Materials_001.csv</code>.
*'''Character case in names''' Windows is case-insensitive, which means that files called <code>Hello.TXT</code> and <code>hello.txt</code> are considered to have the same name, and cannot exist in the same location. Linux is case-sensitive and considers uppercase characters and lowercase characters to be different, and so those two files can exist side by side. This is very relevant if TUFLOW users use one spelling in one place, and the other in another - whereas Windows might interpret both references to point to the same file, on Linux they would result in two separate files. Similarly, if a file's name is spelled with different case from its actual name, a Windows application would find it, and a Linux application might not. (see below)
*'''Encoding and special characters''' On older versions of Windows in English-speaking countries, text files (including TUFLOW configuration files) would use the 1252-Windows encoding. In modern versions of Windows, UTF-8 with BOM is the standard. On Linux UTF-8 without BOM is the standard. TUFLOW accepts any of these encodings and will typically write files in UTF-8 without BOM. On Windows, line endings in such text files are encoded as two characters, a carriage return and a line feed (CR/LF), while Linux uses only a single LF. TUFLOW accepts both forms and writes what is appropriate to the system it is running on.
</ol>

To ensure maximum compatibility of models across systems, TUFLOW will do its best to match names in the model files in the same way between Windows and Linux. This may surprise some new users on Linux and can be disabled with a command-line flag if undesirable, in future releases.

As a general principle, TUFLOW will default to trying to run a model with as little change as possible required across both platforms, writing results in a form that is appropriate to the platform it runs on. Future releases may provide users with more control over this behaviour, if needed.

= Common Questions Answered (FAQ)=
== Why use TUFLOW on Linux at all? ==
TUFLOW on Linux is not just for users that use Linux as their primary work environment, although those certainly exist. Other reasons to consider are:
<ol>
*'''Performance''' Servers or workstations that are dedicated for the running of models can be configured to run TUFLOW and the necessary supporting software (e.g. CodeMeter, NVIDIA GPU drivers, etc.) and very little else, using Linux. There may also be small performance differences in general between an executable built and optimised for Windows or Linux.
*'''Infrastructure cost''' Especially relevant when running virtual machines dedicated to running TUFLOW, or many of those in the cloud, most distributions of Linux do not require a licence whereas Windows does. This can substantially reduce the cost of infrastructure.
*'''HPC tooling''' Automation of running TUFLOW models across many computers or in the cloud can be greatly simplified with tooling designed for that purpose. Many such tools are available "off the shelf", but mostly on Linux. (e.g. SLURM, PBS/Torque, etc.). Similarly, containerisation (e.g. Docker, Podman, LXC) typically requires running on Linux as well.
</ol>

== Must TUFLOW users on Linux use the command line interface? ==
Linux offers a variety of desktop environments and TUFLOW can be used from those just like users would using Microsoft Windows. However, in either case TUFLOW itself is always running as a so-called console application and that makes it uniquely suited to running in lightweight non-graphical environments as well.

Like Windows, Linux offers a variety of scripting options that can help minimise the direct use of the command line by users, if that is desirable. Bash shell scripts are as easy to write and run as batch files are on Windows. Running Python or even PowerShell on Linux is easy to set up as well.

However, given the nature of the application and Linux as an operating system, TUFLOW users on Linux would do well to try and understand some of the very basic of using TUFLOW from the command line and the TUFLOW Support team can assist with that.

Configure CUDA device selection

2025-06-18T03:51:13Z

Jaap.vandervelde: rewrite for a most consistent style

Computers running TUFLOW may have multiple GPUs. These may be multiple NVIDIA GPUs with CUDA capabilities, used to accelerate simulation runs. Alternatively, they can be GPUs used for purposes such as rendering the interactive desktop or handling other computational tasks. A common occurrence on modern motherboards is the availability of an integrated GPU.

Generally, it is recommended to use a GPU that is not used for TUFLOW modelling as the primary GPU for rendering the desktop, if needed. If there is no additional GPU available, one of the NVIDIA GPUs can be used, in which case it is recommended to use the most capable card for running your models and the less capable one for rendering the desktop.

TUFLOW allows selection of a specific GPU for computation using command-line options such as -pu0 for the first GPU, -pu1 for the second, and so on. (See [[HPC Running and Converting Models]].)

However, what TUFLOW considers the first or second GPU may not match the order shown in tools such as Windows Device Manager, Task Manager, or the output of <code>nvidia-smi</code> on the command line. Another common problem is that the needed GPUs are not actually in the expected order and may cause difficulty selecting GPUs in the preferred order.

To this end, an environment variable called <code>CUDA_VISIBLE_DEVICES</code> limits the devices that will be visible to CUDA-capable applications like TUFLOW, as well as specifying the order they will appear in. The remainder of this article outlines how to configure that setting. As an example, a Windows computer is used that has 2 NVIDIA GPUs, and an on-board AMD GPU. In Windows, all available GPUs can be listed using a PowerShell command like this:
<syntaxhighlight lang="powershell">
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController | Select-Object DeviceID, Name
</syntaxhighlight>
(PowerShell commands can be run by opening PowerShell from the Windows Start Menu and pasting a command there)

The output for the example computer is as follows (note that virtual adapters, such as a Remote Desktop adapter, will also appear):
<pre>
DeviceID Name
-------- ----
VideoController1 AMD Radeon(TM) Graphics
VideoController2 Microsoft Remote Display Adapter
VideoController3 NVIDIA GeForce RTX 4090
VideoController4 NVIDIA GeForce RTX 4090
</pre>
In this case, only 'VideoController3' and 'VideoController4' need to be visible to CUDA-enabled applications like TUFLOW. More details on those can be obtained by running the following command (from either PowerShell, Command Prompt, or a Linux shell):
<syntaxhighlight lang="batch">
nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits
</syntaxhighlight>
And the output is as follows:
<pre>
NVIDIA GeForce RTX 4090, GPU-5060f556-4eb4-7155-4020-abadcb2fd735
NVIDIA GeForce RTX 4090, GPU-f3825978-37f8-b933-5327-583196d560cd
</pre>
The tool does not list the AMD card, but up to and including version 2025.1 of TUFLOW, that card may still interfere with the GPU selection order. Also, from this readout, it is not at all clear which card is which and the order here may not match the order you expect from tools like Task Manager ('GPU 0', 'GPU 1', etc.).

This issue can be resolved by setting the environment variable <code>CUDA_VISIBLE_DEVICES</code>. There are two possible formats. It can either have a value like <code>0,1</code> or a more explicit value like <code>GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd</code> using the identifiers from the <code>nvidia-smi</code> output.

The short format just affects the default order. If using <code>-pu0</code> with TUFLOW selects the GPU considered #1 and vice versa, setting <code>CUDA_VISIBLE_DEVICES</code> to <code>1,0</code> reverses the default order. However, this order may change as new hardware is installed, or existing hardware reinstalled. The recommendation is to use the explicit values in the long format.

The value of the environment variable can either be set at the start of scripts used to run models, like batch files, PowerShell scripts, or Linux shell scripts, or globally so that it automatically applies to all running applications.

In a batch file or from the Command Prompt use this (note there are no quotes around the values, replace the values with the identifiers for detected GPUs):
<syntaxhighlight lang="dos">
SET CUDA_VISIBLE_DEVICES=GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd
</syntaxhighlight>
In a PowerShell script or from the PowerShell prompt use this (note the quotes around the values, replace the values with the identifiers for detected GPUs):
<syntaxhighlight lang="powershell">
$env:CUDA_VISIBLE_DEVICES = "GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd"
</syntaxhighlight>

If a globally set value is preferred, it can either be set for a single user account by finding "Edit environment variables ''for your account''" in the Windows Start menu and entering the values without quotes, or it can be set for all users on the machine by finding "Edit the ''system'' environment variables" in the Windows Start menu and doing the same in the 'System Variables' section. Note that administrator rights are required (elevation) to be able to do the latter.

'''Warning:''' setting the value globally affects all CUDA-capable applications, not just TUFLOW. Please ensure that no other applications need the CUDA capabilities of the GPUs that are left out or use a local value in scripts or batch files instead.

Configure CUDA device selection

2025-06-18T02:26:03Z

Jaap.vandervelde: fix syntax error

The computer you use to run TUFLOW may have multiple GPUs. These can be multiple NVIDIA GPUs with CUDA-capabilities, which you may want to use to accelerate running your models. Or they can be additional GPUs for other purposes like rendering the interactive desktop for users of the computer, or other computational tasks. A common occurrence on modern motherboards is the availability of an integrated GPU.

Generally, we recommend using a GPU you don't use for TUFLOW modelling as your primary GPU for rendering the desktop, if needed. If you don't have an additional GPU available, you can use one of the NVIDIA GPUs, be we would then recommend using the most capable card as the primary card for running your models, and the secondary card as the primary GPU for rendering the desktop.

TUFLOW allows you to select a specific GPU for its compute, using command line options like <code>-pu0</code> for the first GPU, <code>-pu1</code> for the second, etc. (see [[HPC Running and Converting Models]])

However, you may find that what TUFLOW considers the first or second GPU does not match your expectations based on what you see in tools like the Windows Device Manager, Task Manager, or the output from <code>nvidia-smi</code> on the command line. Another common problem is that the GPUs you want to use are not actually #0 and #1 and you may have trouble selecting the cards you prefer, in the order you prefer them in.

To this end, you can set an environment variable called <code>CUDA_VISIBLE_DEVICES</code>, which limits the devices that will be visible to CUDA-capable applications like TUFLOW, as well as specifying the order they will appear in. The rest of this article will explain how to go about that. As an example, we'll use a Windows computer that has 2 NVIDIA GPUs, and an on-board AMD GPU. In Windows, you can list all the available GPUs using a Powershell command like this:
<syntaxhighlight lang="powershell">
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController | Select-Object DeviceID, Name
</syntaxhighlight>
(you can run PowerShell commands by opening PowerShell from the Windows Start Menu and pasting a command there)

The output for the example computer looks like this (note that even virtual adapters like a Remote Desktop adapter will show):
<pre>
DeviceID Name
-------- ----
VideoController1 AMD Radeon(TM) Graphics
VideoController2 Microsoft Remote Display Adapter
VideoController3 NVIDIA GeForce RTX 4090
VideoController4 NVIDIA GeForce RTX 4090
</pre>
In this case, we only need 'VideoController3' and 'VideoController4' to be visible to CUDA-enabled applications like TUFLOW. We can get more details on those by running the following command (from either PowerShell, Command Prompt, or a Linux shell):
<syntaxhighlight lang="batch">
nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits
</syntaxhighlight>
And the output looks like this:
<pre>
NVIDIA GeForce RTX 4090, GPU-5060f556-4eb4-7155-4020-abadcb2fd735
NVIDIA GeForce RTX 4090, GPU-f3825978-37f8-b933-5327-583196d560cd
</pre>
The tool won't list the AMD card, but up to and including version 2025.1 of TUFLOW, that card may still interfere with your GPU selection order. Also, from this readout, it is not at all clear which card is which and the order here may not match the order you expect from tools like Task Manager ('GPU 0', 'GPU 1', etc.).

This is what we will solve by setting the environment variable <code>CUDA_VISIBLE_DEVICES</code>. There are two possible formats. It can either have a value like <code=>0,1</code> or a more explicit value like <code>GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd</code> using the identifiers from the <code>nvidia-smi</code> output.

The short format just affects the default order. If you find using <code>-pu0</code> with TUFLOW selects the GPU you'd consider #1 and vice versa, you could set <code>CUDA_VISIBLE_DEVICES</code> to <code>1,0</code>, to reverse the default order. However, this order may change as you install new hardware or reinstall existing hardware, so the recommendation is to use the explicit values in the long format.

You can either set the value of the environment variable at the start of scripts you use to run your models, like batch files, PowerShell scripts, or Linux shell scripts, or you can set it globally so that it automatically applies to all running applications.

In a batch file or from the Command Prompt use this (note there are no quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="dos">
SET CUDA_VISIBLE_DEVICES=GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd
</syntaxhighlight>
In a PowerShell script or from the PowerShell prompt use this (note the quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="powershell">
$env:CUDA_VISIBLE_DEVICES = "GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd"
</syntaxhighlight>

If you prefer to set the value globally, you can either set it for a single user account by finding "Edit environment variables ''for your account''" in the Windows Start menu and entering the values without quotes, or you can set it for all users on the machine by finding "Edit the ''system'' environment variables" in the Windows Start menu and doing the same in the 'System Variables' section. Note that you need to be an administrator to be able to do the latter.

'''Warning:''' setting the value globally affects all CUDA-capable applications, not just TUFLOW. Please ensure that no other applications need the CUDA-capabilities of the GPUs you're leaving out or use a local value in your scripts or batch files instead.

Configure CUDA device selection

2025-06-18T02:25:27Z

Jaap.vandervelde: fix syntax error

The computer you use to run TUFLOW may have multiple GPUs. These can be multiple NVIDIA GPUs with CUDA-capabilities, which you may want to use to accelerate running your models. Or they can be additional GPUs for other purposes like rendering the interactive desktop for users of the computer, or other computational tasks. A common occurrence on modern motherboards is the availability of an integrated GPU.

Generally, we recommend using a GPU you don't use for TUFLOW modelling as your primary GPU for rendering the desktop, if needed. If you don't have an additional GPU available, you can use one of the NVIDIA GPUs, be we would then recommend using the most capable card as the primary card for running your models, and the secondary card as the primary GPU for rendering the desktop.

TUFLOW allows you to select a specific GPU for its compute, using command line options like <code>-pu0</code> for the first GPU, <code>-pu1</code> for the second, etc. (see [[HPC Running and Converting Models]])

However, you may find that what TUFLOW considers the first or second GPU does not match your expectations based on what you see in tools like the Windows Device Manager, Task Manager, or the output from <code>nvidia-smi</code> on the command line. Another common problem is that the GPUs you want to use are not actually #0 and #1 and you may have trouble selecting the cards you prefer, in the order you prefer them in.

To this end, you can set an environment variable called <code>CUDA_VISIBLE_DEVICES</code>, which limits the devices that will be visible to CUDA-capable applications like TUFLOW, as well as specifying the order they will appear in. The rest of this article will explain how to go about that. As an example, we'll use a Windows computer that has 2 NVIDIA GPUs, and an on-board AMD GPU. In Windows, you can list all the available GPUs using a Powershell command like this:
<syntaxhighlight lang="powershell">
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController | Select-Object DeviceID, Name
</syntaxhighlight>
(you can run PowerShell commands by opening PowerShell from the Windows Start Menu and pasting a command there)

The output for the example computer looks like this (note that even virtual adapters like a Remote Desktop adapter will show):
<pre>
DeviceID Name
-------- ----
VideoController1 AMD Radeon(TM) Graphics
VideoController2 Microsoft Remote Display Adapter
VideoController3 NVIDIA GeForce RTX 4090
VideoController4 NVIDIA GeForce RTX 4090
</pre>
In this case, we only need 'VideoController3' and 'VideoController4' to be visible to CUDA-enabled applications like TUFLOW. We can get more details on those by running the following command (from either PowerShell, Command Prompt, or a Linux shell):
<syntaxhighlight>
nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits
</syntaxhighlight>
And the output looks like this:
<pre>
NVIDIA GeForce RTX 4090, GPU-5060f556-4eb4-7155-4020-abadcb2fd735
NVIDIA GeForce RTX 4090, GPU-f3825978-37f8-b933-5327-583196d560cd
</pre>
The tool won't list the AMD card, but up to and including version 2025.1 of TUFLOW, that card may still interfere with your GPU selection order. Also, from this readout, it is not at all clear which card is which and the order here may not match the order you expect from tools like Task Manager ('GPU 0', 'GPU 1', etc.).

This is what we will solve by setting the environment variable <code>CUDA_VISIBLE_DEVICES</code>. There are two possible formats. It can either have a value like <code=>0,1</code> or a more explicit value like <code>GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd</code> using the identifiers from the <code>nvidia-smi</code> output.

The short format just affects the default order. If you find using <code>-pu0</code> with TUFLOW selects the GPU you'd consider #1 and vice versa, you could set <code>CUDA_VISIBLE_DEVICES</code> to <code>1,0</code>, to reverse the default order. However, this order may change as you install new hardware or reinstall existing hardware, so the recommendation is to use the explicit values in the long format.

You can either set the value of the environment variable at the start of scripts you use to run your models, like batch files, PowerShell scripts, or Linux shell scripts, or you can set it globally so that it automatically applies to all running applications.

In a batch file or from the Command Prompt use this (note there are no quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="dos">
SET CUDA_VISIBLE_DEVICES=GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd
</syntaxhighlight>
In a PowerShell script or from the PowerShell prompt use this (note the quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="powershell">
$env:CUDA_VISIBLE_DEVICES = "GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd"
</syntaxhighlight>

If you prefer to set the value globally, you can either set it for a single user account by finding "Edit environment variables ''for your account''" in the Windows Start menu and entering the values without quotes, or you can set it for all users on the machine by finding "Edit the ''system'' environment variables" in the Windows Start menu and doing the same in the 'System Variables' section. Note that you need to be an administrator to be able to do the latter.

'''Warning:''' setting the value globally affects all CUDA-capable applications, not just TUFLOW. Please ensure that no other applications need the CUDA-capabilities of the GPUs you're leaving out or use a local value in your scripts or batch files instead.

Configure CUDA device selection

2025-06-18T02:22:08Z

Jaap.vandervelde: update deprecated source tags

The computer you use to run TUFLOW may have multiple GPUs. These can be multiple NVIDIA GPUs with CUDA-capabilities, which you may want to use to accelerate running your models. Or they can be additional GPUs for other purposes like rendering the interactive desktop for users of the computer, or other computational tasks. A common occurrence on modern motherboards is the availability of an integrated GPU.

Generally, we recommend using a GPU you don't use for TUFLOW modelling as your primary GPU for rendering the desktop, if needed. If you don't have an additional GPU available, you can use one of the NVIDIA GPUs, be we would then recommend using the most capable card as the primary card for running your models, and the secondary card as the primary GPU for rendering the desktop.

TUFLOW allows you to select a specific GPU for its compute, using command line options like <code>-pu0</code> for the first GPU, <code>-pu1</code> for the second, etc. (see [[HPC Running and Converting Models]])

However, you may find that what TUFLOW considers the first or second GPU does not match your expectations based on what you see in tools like the Windows Device Manager, Task Manager, or the output from <code>nvidia-smi</code> on the command line. Another common problem is that the GPUs you want to use are not actually #0 and #1 and you may have trouble selecting the cards you prefer, in the order you prefer them in.

To this end, you can set an environment variable called <code>CUDA_VISIBLE_DEVICES</code>, which limits the devices that will be visible to CUDA-capable applications like TUFLOW, as well as specifying the order they will appear in. The rest of this article will explain how to go about that. As an example, we'll use a Windows computer that has 2 NVIDIA GPUs, and an on-board AMD GPU. In Windows, you can list all the available GPUs using a Powershell command like this:
<syntaxhighlight lang="powershell">
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController | Select-Object DeviceID, Name
</syntaxhighlight>
(you can run PowerShell commands by opening PowerShell from the Windows Start Menu and pasting a command there)

The output for the example computer looks like this (note that even virtual adapters like a Remote Desktop adapter will show):
<pre>
DeviceID Name
-------- ----
VideoController1 AMD Radeon(TM) Graphics
VideoController2 Microsoft Remote Display Adapter
VideoController3 NVIDIA GeForce RTX 4090
VideoController4 NVIDIA GeForce RTX 4090
</pre>
In this case, we only need 'VideoController3' and 'VideoController4' to be visible to CUDA-enabled applications like TUFLOW. We can get more details on those by running the following command (from either PowerShell, Command Prompt, or a Linux shell):
<syntaxhighlight>
nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits
</syntaxhighlight>
And the output looks like this:
<pre>
NVIDIA GeForce RTX 4090, GPU-5060f556-4eb4-7155-4020-abadcb2fd735
NVIDIA GeForce RTX 4090, GPU-f3825978-37f8-b933-5327-583196d560cd
</pre>
The tool won't list the AMD card, but up to and including version 2025.1 of TUFLOW, that card may still interfere with your GPU selection order. Also, from this readout, it is not at all clear which card is which and the order here may not match the order you expect from tools like Task Manager ('GPU 0', 'GPU 1', etc.).

This is what we will solve by setting the environment variable <code>CUDA_VISIBLE_DEVICES</code>. There are two possible formats. It can either have a value like <code=>0,1</code> or a more explicit value like <code>GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd</code> using the identifiers from the <code>nvidia-smi</code> output.

The short format just affects the default order. If you find using <code>-pu0</code> with TUFLOW selects the GPU you'd consider #1 and vice versa, you could set <code>CUDA_VISIBLE_DEVICES</code> to <code="none">1,0</code>, to reverse the default order. However, this order may change as you install new hardware or reinstall existing hardware, so the recommendation is to use the explicit values in the long format.

You can either set the value of the environment variable at the start of scripts you use to run your models, like batch files, PowerShell scripts, or Linux shell scripts, or you can set it globally so that it automatically applies to all running applications.

In a batch file or from the Command Prompt use this (note there are no quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="dos">
SET CUDA_VISIBLE_DEVICES=GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd
</syntaxhighlight>
In a PowerShell script or from the PowerShell prompt use this (note the quotes around the values, replace the values with the identifiers for your GPUs):
<syntaxhighlight lang="powershell">
$env:CUDA_VISIBLE_DEVICES = "GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd"
</syntaxhighlight>

If you prefer to set the value globally, you can either set it for a single user account by finding "Edit environment variables ''for your account''" in the Windows Start menu and entering the values without quotes, or you can set it for all users on the machine by finding "Edit the ''system'' environment variables" in the Windows Start menu and doing the same in the 'System Variables' section. Note that you need to be an administrator to be able to do the latter.

'''Warning:''' setting the value globally affects all CUDA-capable applications, not just TUFLOW. Please ensure that no other applications need the CUDA-capabilities of the GPUs you're leaving out or use a local value in your scripts or batch files instead.

HPC Running and Converting Models

2025-06-18T02:17:36Z

Jaap.vandervelde:

= Introduction =
This page contains information about converting an existing TUFLOW Classic or GPU (pre 2017 HPC release) model to a format that can be run using the TUFLOW HPC engine. This page provides a quick summary for experienced TUFLOW users to use as a reference point for updating their models. It is recommended that less experienced TUFLOW users refer to our [[Tutorial_Introduction |TUFLOW Tutorial Modules]] for greater support and guidance on creating a HPC model. 

To convert an existing TUFLOW Classic or GPU Model to run on HPC, an update to the TUFLOW Control File (TCF) is needed. Some features from TUFLOW Classic that are not currently supported in HPC, may prevent the HPC model running successfully. To find out more about unsupported features in HPC, refer to the [https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]. 

= Converting TUFLOW Classic to HPC (TCF Updates) =
To run an existing TUFLOW Classic simulation with the new HPC engine, the following lines of text need to be added to the TUFLOW Control File (TCF). 
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> <tt> !This command specifies that you want to run TUFLOW using the HPC solution scheme or engine.</tt> 
The following command is also required to run the model using GPU hardware: 
<tt>Hardware </tt> <tt>==</tt><tt> GPU </tt> <tt> !CPU is default. The hardware command instructs TUFLOW HPC to run using GPU hardware. This is typically orders of magnitude faster than on CPU.</tt> 
These two commands are all that's needed to run convert the TUFLOW Classic model to HPC and run using GPU hardware. There are however more commands provided below that give the modeller greater control over the Hardware that HPC uses. 

= Running HPC on Multiple CPU Threads =
As mentioned in the [[HPC_Introduction | HPC Introduction]] page, HPC can be parallelised to run across multiple CPU processors when run on CPU (i.e. not GPU). The following command allows the modeller to dictate the number of core processors to run TUFLOW HPC across. 
<tt>CPU Threads </tt> <tt>==</tt><tt> 8 </tt> <tt> !Default is 4. This instructs TUFLOW to search for and run the model across four different core processors. </tt> 
If the number of processors or TUFLOW licences found by TUFLOW are less than the specified value, then TUFLOW will utilise the maximum number of core processors available within the licence and hardware limitations. 
Alternatively, the number of CPU threads can be specified in the batch file / command line by using the -nt<number of threads> argument. If both control file and command line are used to specify number of threads, the command line option will prevail.

= Running HPC on Multiple GPU Devices =
Much like HPC can be run across multiple CPU processors, HPC can be run across multiple GPU cards. Models can also be instructed to run on a specific GPU card. 
If a machine only has a single GPU card, the GPU Device ID should be 0, this is a default. If a second GPU card was added, the Device ID would be 1 and so on. The GPU IDs can be checked by reviewing the machines ''Device Manager''. (Note that the order may not match your expectations, more on that in [[Configure CUDA device selection]]) 
The most common method is to specify the GPU card ID in the batch file / command line by using the -pu<id> argument. 
Example below will run single simulation across the first and second GPU card (ID 0 and 1).
<pre>"TUFLOW_iSP_w64.exe" -pu0 -pu1 "M01_5m_001.tcf"</pre>
Example below will run single simulation on the fourth GPU card (ID 3).
<pre>"TUFLOW_iSP_w64.exe" -pu3 "M01_5m_001.tcf"</pre>

Alternatively, the following TCF command can be used to set the number of GPU devices and which devices to use. 
<tt>GPU Device IDs </tt> <tt>==</tt><tt> 0, 1 </tt> <tt> !This command instructs TUFLOW to run the model on GPU Device 0 and GPU Device 1.</tt> 
If both control file and command line are used to specify devices, the command line option will prevail.

= Converting TUFLOW GPU to HPC (TCF Updates) =
When converting a TUFLOW GPU model across to HPC, first confirm that all features in the GPU model are available in HPC by referring to the [https://tuflow.com/Download/TUFLOW/Releases/2017-09/TUFLOW%20Release%20Notes.2017-09.pdf TUFLOW 2017-09 Release Notes]. 
Delete the following command from the *.tcf file and insert the commands specified above, for converting a TUFLOW Classic model to HPC. 
<s><tt>GPU Solver </tt> <tt>==</tt><tt> ON </tt></s> 

= HPC Scenarios and Updating the Batch File =
Modellers may want to change the hardware that HPC is run on throughout the course of a project. For example, if your company own more CPU than GPU licences it may be beneficial to run the model using CPU hardware during the initial model build phase so your colleagues have access to the higher speed GPU licences for production runs on other projects that are running in parallel. If this is the case, it may be easier to setup a Scenario Logic statement in the TUFLOW Control File (TCF), that allows the modeller to change the hardware being used with a simple switch in the batch file used to run the model.

To setup a scenario for varying hardware options, the following commands can be used in the TCF file:
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> 
<tt>Hardware </tt> <tt>==</tt> <tt> <<~s1~>> </tt> <tt> !The scenario will either be "CPU" or "GPU"</tt> 

This basic scenario logic can be configured further within the TCF as shown below: 

<tt>If Scenario </tt> <tt>==</tt> <tt> CPU </tt> 
:: <tt>CPU Threads </tt> <tt>==</tt> <tt> 8 </tt> 
<tt>Else If Scenario </tt> <tt>==</tt> <tt> GPU </tt> 
:: <tt>GPU Device IDs</tt> <tt>==</tt> <tt> 0, 1 </tt> 
<tt>End If </tt> 

If using the above Scenario Logic, the modeller must include a scenario call in the batch file. 
<tt>-s1 <Hardware Type> </tt> 
If you are unfamiliar with using Scenario Logic, please refer to [[Tutorial_M08 |Tutorial Module 08]]. 

Other useful batch file switches include: 
<tt>-nt <number_of_threads> </tt>: This switch is used to set the number of CPU threads used for CPU mode simulations. 
<tt>-pu <GPU Device IDs> </tt>: This switch is used to set the number of GPU devices and which devices to use. 
An example of how this would be implemented into a simple batch file for CPU and GPU are shown below. 

'''CPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 CPU -nt8 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on CPU using 8 CPU threads. 

'''GPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 GPU -pu0 -pu1 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on GPU using 2 GPU cards. 
 
 
{{Tips Navigation
|uplink=[[ HPC_Modelling_Guidance | Back to HPC Modelling Guidance]]
}}

HPC Running and Converting Models

2025-06-18T02:17:18Z

Jaap.vandervelde: add reference back to Configure CUDA device selection

= Introduction =
This page contains information about converting an existing TUFLOW Classic or GPU (pre 2017 HPC release) model to a format that can be run using the TUFLOW HPC engine. This page provides a quick summary for experienced TUFLOW users to use as a reference point for updating their models. It is recommended that less experienced TUFLOW users refer to our [[Tutorial_Introduction |TUFLOW Tutorial Modules]] for greater support and guidance on creating a HPC model. 

To convert an existing TUFLOW Classic or GPU Model to run on HPC, an update to the TUFLOW Control File (TCF) is needed. Some features from TUFLOW Classic that are not currently supported in HPC, may prevent the HPC model running successfully. To find out more about unsupported features in HPC, refer to the [https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW Manual]. 

= Converting TUFLOW Classic to HPC (TCF Updates) =
To run an existing TUFLOW Classic simulation with the new HPC engine, the following lines of text need to be added to the TUFLOW Control File (TCF). 
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> <tt> !This command specifies that you want to run TUFLOW using the HPC solution scheme or engine.</tt> 
The following command is also required to run the model using GPU hardware: 
<tt>Hardware </tt> <tt>==</tt><tt> GPU </tt> <tt> !CPU is default. The hardware command instructs TUFLOW HPC to run using GPU hardware. This is typically orders of magnitude faster than on CPU.</tt> 
These two commands are all that's needed to run convert the TUFLOW Classic model to HPC and run using GPU hardware. There are however more commands provided below that give the modeller greater control over the Hardware that HPC uses. 

= Running HPC on Multiple CPU Threads =
As mentioned in the [[HPC_Introduction | HPC Introduction]] page, HPC can be parallelised to run across multiple CPU processors when run on CPU (i.e. not GPU). The following command allows the modeller to dictate the number of core processors to run TUFLOW HPC across. 
<tt>CPU Threads </tt> <tt>==</tt><tt> 8 </tt> <tt> !Default is 4. This instructs TUFLOW to search for and run the model across four different core processors. </tt> 
If the number of processors or TUFLOW licences found by TUFLOW are less than the specified value, then TUFLOW will utilise the maximum number of core processors available within the licence and hardware limitations. 
Alternatively, the number of CPU threads can be specified in the batch file / command line by using the -nt<number of threads> argument. If both control file and command line are used to specify number of threads, the command line option will prevail.

= Running HPC on Multiple GPU Devices =
Much like HPC can be run across multiple CPU processors, HPC can be run across multiple GPU cards. Models can also be instructed to run on a specific GPU card. 
If a machine only has a single GPU card, the GPU Device ID should be 0, this is a default. If a second GPU card was added, the Device ID would be 1 and so on. The GPU IDs can be checked by reviewing the machines ''Device Manager''. (Note that the order may not match your expectations, more on that in [Configure CUDA device selection]) 
The most common method is to specify the GPU card ID in the batch file / command line by using the -pu<id> argument. 
Example below will run single simulation across the first and second GPU card (ID 0 and 1).
<pre>"TUFLOW_iSP_w64.exe" -pu0 -pu1 "M01_5m_001.tcf"</pre>
Example below will run single simulation on the fourth GPU card (ID 3).
<pre>"TUFLOW_iSP_w64.exe" -pu3 "M01_5m_001.tcf"</pre>

Alternatively, the following TCF command can be used to set the number of GPU devices and which devices to use. 
<tt>GPU Device IDs </tt> <tt>==</tt><tt> 0, 1 </tt> <tt> !This command instructs TUFLOW to run the model on GPU Device 0 and GPU Device 1.</tt> 
If both control file and command line are used to specify devices, the command line option will prevail.

= Converting TUFLOW GPU to HPC (TCF Updates) =
When converting a TUFLOW GPU model across to HPC, first confirm that all features in the GPU model are available in HPC by referring to the [https://tuflow.com/Download/TUFLOW/Releases/2017-09/TUFLOW%20Release%20Notes.2017-09.pdf TUFLOW 2017-09 Release Notes]. 
Delete the following command from the *.tcf file and insert the commands specified above, for converting a TUFLOW Classic model to HPC. 
<s><tt>GPU Solver </tt> <tt>==</tt><tt> ON </tt></s> 

= HPC Scenarios and Updating the Batch File =
Modellers may want to change the hardware that HPC is run on throughout the course of a project. For example, if your company own more CPU than GPU licences it may be beneficial to run the model using CPU hardware during the initial model build phase so your colleagues have access to the higher speed GPU licences for production runs on other projects that are running in parallel. If this is the case, it may be easier to setup a Scenario Logic statement in the TUFLOW Control File (TCF), that allows the modeller to change the hardware being used with a simple switch in the batch file used to run the model.

To setup a scenario for varying hardware options, the following commands can be used in the TCF file:
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> 
<tt>Hardware </tt> <tt>==</tt> <tt> <<~s1~>> </tt> <tt> !The scenario will either be "CPU" or "GPU"</tt> 

This basic scenario logic can be configured further within the TCF as shown below: 

<tt>If Scenario </tt> <tt>==</tt> <tt> CPU </tt> 
:: <tt>CPU Threads </tt> <tt>==</tt> <tt> 8 </tt> 
<tt>Else If Scenario </tt> <tt>==</tt> <tt> GPU </tt> 
:: <tt>GPU Device IDs</tt> <tt>==</tt> <tt> 0, 1 </tt> 
<tt>End If </tt> 

If using the above Scenario Logic, the modeller must include a scenario call in the batch file. 
<tt>-s1 <Hardware Type> </tt> 
If you are unfamiliar with using Scenario Logic, please refer to [[Tutorial_M08 |Tutorial Module 08]]. 

Other useful batch file switches include: 
<tt>-nt <number_of_threads> </tt>: This switch is used to set the number of CPU threads used for CPU mode simulations. 
<tt>-pu <GPU Device IDs> </tt>: This switch is used to set the number of GPU devices and which devices to use. 
An example of how this would be implemented into a simple batch file for CPU and GPU are shown below. 

'''CPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 CPU -nt8 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on CPU using 8 CPU threads. 

'''GPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 GPU -pu0 -pu1 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on GPU using 2 GPU cards. 
 
 
{{Tips Navigation
|uplink=[[ HPC_Modelling_Guidance | Back to HPC Modelling Guidance]]
}}

Configure CUDA device selection

2025-06-18T02:15:14Z

Jaap.vandervelde: new article on setting CUDA_VISIBLE_DEVICES referenced from the FAQ for Hardware Selection Advice

The computer you use to run TUFLOW may have multiple GPUs. These can be multiple NVIDIA GPUs with CUDA-capabilities, which you may want to use to accelerate running your models. Or they can be additional GPUs for other purposes like rendering the interactive desktop for users of the computer, or other computational tasks. A common occurrence on modern motherboards is the availability of an integrated GPU.

Generally, we recommend using a GPU you don't use for TUFLOW modelling as your primary GPU for rendering the desktop, if needed. If you don't have an additional GPU available, you can use one of the NVIDIA GPUs, be we would then recommend using the most capable card as the primary card for running your models, and the secondary card as the primary GPU for rendering the desktop.

TUFLOW allows you to select a specific GPU for its compute, using command line options like <source enclose="none">-pu0</source> for the first GPU, <source enclose="none">-pu1</source> for the second, etc. (see [[HPC Running and Converting Models]])

However, you may find that what TUFLOW considers the first or second GPU does not match your expectations based on what you see in tools like the Windows Device Manager, Task Manager, or the output from <source enclose="none">nvidia-smi</source> on the command line. Another common problem is that the GPUs you want to use are not actually #0 and #1 and you may have trouble selecting the cards you prefer, in the order you prefer them in.

To this end, you can set an environment variable called <source enclose="none">CUDA_VISIBLE_DEVICES</source>, which limits the devices that will be visible to CUDA-capable applications like TUFLOW, as well as specifying the order they will appear in. The rest of this article will explain how to go about that. As an example, we'll use a Windows computer that has 2 NVIDIA GPUs, and an on-board AMD GPU. In Windows, you can list all the available GPUs using a Powershell command like this:
<source language="powershell">
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_VideoController | Select-Object DeviceID, Name
</source>
(you can run PowerShell commands by opening PowerShell from the Windows Start Menu and pasting a command there)

The output for the example computer looks like this (note that even virtual adapters like a Remote Desktop adapter will show):
<pre>
DeviceID Name
-------- ----
VideoController1 AMD Radeon(TM) Graphics
VideoController2 Microsoft Remote Display Adapter
VideoController3 NVIDIA GeForce RTX 4090
VideoController4 NVIDIA GeForce RTX 4090
</pre>
In this case, we only need 'VideoController3' and 'VideoController4' to be visible to CUDA-enabled applications like TUFLOW. We can get more details on those by running the following command (from either PowerShell, Command Prompt, or a Linux shell):
<source>
nvidia-smi --query-gpu=name,uuid --format=csv,noheader,nounits
</source>
And the output looks like this:
<pre>
NVIDIA GeForce RTX 4090, GPU-5060f556-4eb4-7155-4020-abadcb2fd735
NVIDIA GeForce RTX 4090, GPU-f3825978-37f8-b933-5327-583196d560cd
</pre>
The tool won't list the AMD card, but up to and including version 2025.1 of TUFLOW, that card may still interfere with your GPU selection order. Also, from this readout, it is not at all clear which card is which and the order here may not match the order you expect from tools like Task Manager ('GPU 0', 'GPU 1', etc.).

This is what we will solve by setting the environment variable <source enclose="none">CUDA_VISIBLE_DEVICES</source>. There are two possible formats. It can either have a value like <source enclose="none">0,1</source> or a more explicit value like <source enclose="none">GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd</source> using the identifiers from the <source enclose="none">nvidia-smi</source> output.

The short format just affects the default order. If you find using <source enclose="none">-pu0</source> with TUFLOW selects the GPU you'd consider #1 and vice versa, you could set <source enclose="none">CUDA_VISIBLE_DEVICES</source> to <source enclose="none">1,0</source>, to reverse the default order. However, this order may change as you install new hardware or reinstall existing hardware, so the recommendation is to use the explicit values in the long format.

You can either set the value of the environment variable at the start of scripts you use to run your models, like batch files, PowerShell scripts, or Linux shell scripts, or you can set it globally so that it automatically applies to all running applications.

In a batch file or from the Command Prompt use this (note there are no quotes around the values, replace the values with the identifiers for your GPUs):
<source language="dos">
SET CUDA_VISIBLE_DEVICES=GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd
</source>
In a PowerShell script or from the PowerShell prompt use this (note the quotes around the values, replace the values with the identifiers for your GPUs):
<source language="powershell">
$env:CUDA_VISIBLE_DEVICES = "GPU-5060f556-4eb4-7155-4020-abadcb2fd735,GPU-f3825978-37f8-b933-5327-583196d560cd"
</source>

If you prefer to set the value globally, you can either set it for a single user account by finding "Edit environment variables ''for your account''" in the Windows Start menu and entering the values without quotes, or you can set it for all users on the machine by finding "Edit the ''system'' environment variables" in the Windows Start menu and doing the same in the 'System Variables' section. Note that you need to be an administrator to be able to do the latter.

'''Warning:''' setting the value globally affects all CUDA-capable applications, not just TUFLOW. Please ensure that no other applications need the CUDA-capabilities of the GPUs you're leaving out or use a local value in your scripts or batch files instead.

Hardware Selection Advice

2025-06-18T01:22:51Z

Jaap.vandervelde: add FAQ section on Pavlina's request, add link to CUDA device selection article

This page provides general hardware advice for running TUFLOW models on GPU or CPU. 
[[File: Hardware_Configuration_001.jpg ||450px|right]]

=Introduction=
We often get asked about the optimum computing setup to run TUFLOW models. While every model is different and will interact differently with your hardware there is some general advice that we can offer. In the sections below you will find more detailed advice on GPU and CPU but generally: 

* The amount of RAM in the computer will be the limiter for the size of model you can run. This applies to CPU RAM (TUFLOW Classic, TUFLOW FV and TUFLOW HPC with Hardware == CPU) and also GPU RAM (TUFLOW HPC and TUFLOW FV with Hardware == GPU).
* The processing speed of the CPU, the architecture, cache size, speed and number of processors play a role.
* For GPU simulations, the number of CUDA cores, the core speed, GPU card architecture, memory speed and interfacing with the motherboard PCI lanes and CPU are all important.
* The system must be well cooled to avoid throttling (meaning reduction of clock speeds to reduce heating). 
For information on minimum and recommended system requirement, see [[System_Requirements | System Requirements]].

To discover a computer's NVIDIA GPU hardware, see [[Console_Window_GPU_Usage | NVIDIA GPU Hardware and Usage]]. 

=The TUFLOW Software Suite=
The TUFLOW Software suite has a range of solvers. Each interact differently with your hardware so pairing the correct solver (or the range of solvers you want to run) and hardware is an important consideration. A brief summary of each solver's needs is provided as follows: 
*TUFLOW Classic: A single model run can only use the CPU and cannot be run across multiple CPU cores or GPU hardware. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, architecture and cache size.
* TUFLOW HPC - Run on CPU Hardware: A single model run uses the CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, the number of cores available to be run in parallel, architecture and cache size.
*TUFLOW HPC - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW HPC requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute.
*TUFLOW FV - Run on CPU Hardware: A single model run uses CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is determined by the CPU speed, the number of cores available to be run in parallel, chip architecture and cache size.
*TUFLOW FV - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW FV requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute. 

The [[Hardware_Benchmarking_-_Results#CPU_Results | Hardware Benchmarking]] page shows recently run combinations of GPU, CPU and RAM. These can be compared with the system planned for purchase. The recommendation is to seek advise from an appropriate computer hardware vendor who can advise on the compatibility and optimisation of the setup. 
 

=GPU Advice=
TUFLOW HPC on GPU Hardware is typically our fastest solver for 1D/2D pipe and floodplain simulations.
* TUFLOW HPC supports CUDA enabled NVIDIA GPU cards. For list of supported CUDA enabled graphics cards please visit the [https://developer.nvidia.com/cuda-gpus NVIDIA website].
*To discover a computer's NVIDIA GPU hardware, see [[Console_Window_GPU_Usage | NVIDIA GPU Hardware and Usage]].
*TUFLOW HPC on GPU Hardware can be run in either single or double precision. However, for the vast majority of flood applications single precision is sufficient. We typically run our models on single precision. If you are unsure we recommend running with both the single and double precision solvers and comparing your results.
The precision solver you require will determine the type of GPU card that is best suited for your compute. For any given generation/architecture of cards, the “gaming” cards such as the GTX GeForce and RTX provide excellent single precision performance – typically comparable to that of the “scientific” cards such as the Tesla series. If double precision is required then the scientific cards are substantially faster, but these are also significantly more expensive. The Quadro series cards sit in between for both double precision performance and cost. When checking the specifications of the card it should provide you with a breakdown of the single and double precision throughput in flops. Single precision compute is typically sufficient for TUFLOW HPC modelling.

===GPU RAM===
RAM is the computer memory required to store all of the model data used during the computation. A computer has CPU RAM which is located on the motherboard and accessed from the CPU, and it has GPU RAM which is located on the GPU device and accessed from the GPU. The two memory storage systems are physically separate.
The amount of GPU RAM is one of two factors that will determine the size of the model that can be run (the other being CPU RAM). As a rule of thumb, approximately 5 million cells can be run per gigabyte (GB) of GPU RAM depending on the model features, e.g. a model with infiltration requires more memory due to the extra variables needed for the infiltration calculation.

===CPU RAM===
TUFLOW HPC on GPU hardware still uses the CPU to compute and store data (in CPU RAM) during model initialisation and for all 1D calculations. While we are working on improving our CPU RAM usage, currently we tend to find that CPU RAM is often the limiter to the size of the model domain you can run, particularly if using running over multiple GPU cards. During initialisation and simulation a model will typically require 4-6 times the amount of CPU RAM relative to GPU RAM. As an example, a model that utilises 11GB of GPU RAM (typical memory for high-end gaming card, and corresponds to about a 50 million cell model) the CPU RAM required during initialisation will typically be in range 44GB to 66GB. A model that fully utilises two 11 GB GPUs (i.e. a 100 million cell model) may require as much as 128GB of CPU RAM during initialisation.

===CUDA Cores, GPU Clock speed, and FLOPs ===
One way of reporting a GPU card's throughput is in Floating Point Operations per second (FLOPs). The more FLOPs, the more calculations that can get crunched per second and the faster the model should run. For any given generation of GPU, FLOPs are approximately proportional to number of CUDA cores times the GPU clock speed. However, there have been significant improvements in GPU architecture since the inception of CUDA, and this has contributed to increases in overall FLOPs performance beyond just the increases in cores and clock speed that have occurred over this time.

===Multiple GPUs===
TUFLOW can use multiple GPU cards on a machine to run a single model (TUFLOW FV can currently use a single GPU only). This is useful for models that are too large for a single GPU, or for running a model as quickly as possible. In general terms the run time benefit of using multiple cards increases with model size.
*TUFLOW HPC-GPU does not support SLI for inter-GPU communications.
*It does (as of build 2020-01-AA) auto detect and utilise peer-to-peer access over NVLink or PCI bus on the motherboard. Note that not all GPUs support peer-to-peer access.
**PCI bus - this method requires cards that supports TCC driver mode and all cards must be in TCC driver mode. As TUFLOW primarily relies on GPU CUDA capabilities, the impact of using higher or lower PCI slot option is minimal.
**NVLink - high-end compute cards can have up to 8 cards talking to each other through a high-spec NVLink, but many of the less expensive cards are limited to only having two connected together over a dual socket NVLink.
*Models may still be run across multiple GPUs even if a NVLink is not present and the GPUs do not support peer-to-peer access. In this case HPC reverts to exchanging the domain boundary data between the GPUs via the CPU. The memory bandwidth between the GPU and the main system is not a critical bottleneck for TUFLOW.
*When using multiple GPUs it is best to use cards of similar memory and performance. While it is possible (as of build 2020-01-AA) to re-balance a model over multiple GPUs, we do not recommend using cards with vastly disparate performance.
*Sufficient cooling and power supply should be considered if multiple cards are used. When installed in adjacent PCI slots, the preference is to use rear vented cards rather than side vented to avoid blowing hot air onto the neighbouring cards (which could lead to overheating).

===GPU Performance Comparison===
Extensive GPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking_(2018-03-AA)| Hardware Benchmarking]] page of the Wiki. Review the GPU benchmarking runtime results table to compare the speed performance of different cards. If your GPU card is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to [mailto:support@tuflow.com support@tuflow.com]. We will add the details to the runtime results table. 

External videocard benchmark websites can be used to compare GPU cards, for example, [https://www.videocardbenchmark.net/high_end_gpus.html PassMark Software - Video Card (GPU) Benchmarks] is an excellent performance guide.
 

=CPU Advice=
In general terms a more recent architecture, higher clock speed CPU with a large cache will perform better than a slower clock speed chip. This section discusses CPU RAM, RAM speed, Processor frequency, Multi-core processing and hyper-threading.

===CPU RAM===
The amount of CPU RAM will determine the size of the model that can be run or a number of models that can be run at one time.
Faster RAM will result in quicker runtimes, however this is usually a secondary consideration to chip speed, cache size and architecture.

===CPU Cores ===
*TUFLOW HPC - Run on GPU Hardware: The parallel processing is being done on the GPU card. However, TUFLOW HPC-GPU still uses the CPU for model initialisation and for 1D calculations. If multiple GPU cards are used, TUFLOW will use the equivalent number of CPU threads for controlling the GPUs and migrating data. So for a machine dedicated to HPC-GPU modelling, the number of CPU cores should be higher than the number of installed GPUs.
*TUFLOW HPC - Run on CPU Hardware: HPC model can also be run on multiple CPU cores. For the comparison of simulation speed, please refer to [[Hardware_Benchmarking_Topic_HPC_on_CPU_vs_GPU | HPC on CPU vs GPU]].
*TUFLOW Classic: TUFLOW Classic simulation can only use one CPU core due to the implicit nature of the numerical solution. More CPU cores will enable running more simulations at the same time most efficiently.

===Hyperthreading===
https://fvwiki.tuflow.com/index.php?title=TUFLOW_FV_Parallel_Computing

===Processor Frequency and RAM Frequency===
The frequency directly affects the run times. In general, the higher the frequency, the faster the model runs.

===CPU Performance Comparison===
Extensive CPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking_(2018-03-AA)| Hardware Benchmarking]] page of the Wiki. Review the CPU benchmarking runtime results table to compare the speed performance of different chips. If your chip is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to [mailto:support@tuflow.com support@tuflow.com]. We will add the details to the runtime results table. 
 

=Storage Advice=
Solid state hard drives are preferred for temporary storage as they are faster to write to than traditional hard drives. Large data files can then be transferred to a more permanent location.
 

=Common Questions Answered (FAQ)=
==How do I reliably select the correct GPU on systems with multiple GPUs?==
You may encounter issues like these:
* The order of GPUs in Task Manager does not match the order of GPUs for TUFLOW.
* The order of GPUs in the `nvidia-smi` tool does not match the order of GPUs for TUFLOW.
* Non-NVIDIA GPUs or GPUs you do not want to use interfere with GPU selection.
You can resolve these issues by reading about [[configure_CUDA_device_selection | specifying the exact CUDA-capable GPUs]] you want to be available to CUDA-enabled applications like TUFLOW.

 
{{Tips Navigation
|uplink=[[Main_Page| TUFLOW Main Page]]
}}

Hardware Selection Advice

2025-01-06T23:15:22Z

Jaap.vandervelde: 'throttling' is not a common phrase.

This page provides general hardware advice for running TUFLOW models on GPU or CPU. 
[[File: Hardware_Configuration_001.jpg ||450px|right]]

=Introduction=
We often get asked about the optimum computing setup to run TUFLOW models. While every model is different and will interact differently with your hardware there is some general advice that we can offer. In the sections below you will find more detailed advice on GPU and CPU but generally: 

* The amount of RAM in the computer will be the limiter for the size of model you can run. This applies to CPU RAM (TUFLOW Classic, TUFLOW FV and TUFLOW HPC with Hardware == CPU) and also GPU RAM (TUFLOW HPC and TUFLOW FV with Hardware == GPU).
* The processing speed of the CPU, the architecture, cache size, speed and number of processors play a role.
* For GPU simulations, the number of CUDA cores, the core speed, GPU card architecture, memory speed and interfacing with the motherboard PCI lanes and CPU are all important.
* The system must be well cooled to avoid throttling (meaning reduction of clock speeds to reduce heating). 
 

=The TUFLOW Software Suite=
The TUFLOW Software suite has a range of solvers. Each interact differently with your hardware so pairing the correct solver (or the range of solvers you want to run) and hardware is an important consideration. A brief summary of each solver's needs is provided as follows: 
* TUFLOW Classic: A single model run can only use the CPU and cannot be run across multiple CPU cores or GPU hardware. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, architecture and cache size.
* TUFLOW HPC - Run on CPU Hardware: A single model run uses the CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is driven by the CPU speed, the number of cores available to be run in parallel, architecture and cache size.
* TUFLOW HPC - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW HPC requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute.
* TUFLOW FV - Run on CPU Hardware: A single model run uses CPU and is parallelised to run across multiple cores. In general terms: The maximum model size is dependent on the available CPU RAM and the runtime is determined by the CPU speed, the number of cores available to be run in parallel, chip architecture and cache size.
* TUFLOW FV - Run on GPU Hardware: A single model run uses the GPU(s) for computation. In general terms: The maximum model size is dependent on the available GPU and CPU RAM and the runtime is driven by the CUDA core speed, the number of CUDA cores available and the GPU architecture. GPU performance is complex and is not easily inferred from GPU clock speed and number of cores, it is also very dependent on the ‘generation’ or architecture of GPU. As TUFLOW FV requires some data exchange between GPU and CPU, the motherboard bus speeds and CPU speeds also play a role but typically a much lesser role compared to the GPU CUDA compute. 

On our [[Hardware_Benchmarking_-_Results#CPU_Results | Hardware Benchmarking]] page you can compare recently run combinations of GPU, CPU and RAM with the system you are planning to purchase. We recommend that if building a computer that you seek advise from an appropriate computer hardware vendor who can advise on the compatibility and optimisation of your setup. 
 

=GPU Advice=
TUFLOW HPC on GPU Hardware is typically our fastest solver for 1D/2D pipe and floodplain simulations.
* TUFLOW HPC supports CUDA enabled NVIDIA GPU cards. For list of supported CUDA enabled graphics cards please visit the [https://developer.nvidia.com/cuda-gpus NVIDIA website].
* TUFLOW HPC on GPU Hardware can be run in either single or double precision. However, for the vast majority of flood applications single precision is sufficient. We typically run our models on single precision. If you are unsure we recommend running with both the single and double precision solvers and comparing your results.
The precision solver you require will determine the type of GPU card that is best suited for your compute. For any given generation/architecture of cards, the “gaming” cards such as the GTX GeForce and RTX provide excellent single precision performance – typically comparable to that of the “scientific” cards such as the Tesla series. If double precision is required then the scientific cards are substantially faster, but these are also significantly more expensive. The Quadro series cards sit in between for both double precision performance and cost. When checking the specifications of the card it should provide you with a breakdown of the single and double precision throughput in flops. Single precision compute is typically sufficient for TUFLOW HPC modelling.

===GPU RAM===
RAM is the computer memory required to store all of the model data used during the computation. A computer has CPU RAM which is located on the motherboard and accessed from the CPU, and it has GPU RAM which is located on the GPU device and accessed from the GPU. The two memory storage systems are physically separate.
The amount of GPU RAM is one of two factors that will determine the size of the model that can be run (the other being CPU RAM). As a rule of thumb, approximately 5 million cells can be run per gigabyte (GB) of GPU RAM depending on the model features, e.g. a model with infiltration requires more memory due to the extra variables needed for the infiltration calculation.

===CPU RAM===
TUFLOW HPC on GPU hardware still uses the CPU to compute and store data (in CPU RAM) during model initialisation and for all 1D calculations. While we are working on improving our CPU RAM usage, currently we tend to find that CPU RAM is often the limiter to the size of the model domain you can run, particularly if using running over multiple GPU cards. During initialisation and simulation a model will typically require 4-6 times the amount of CPU RAM relative to GPU RAM. As an example, a model that utilises 11GB of GPU RAM (typical memory for high-end gaming card, and corresponds to about a 50 million cell model) the CPU RAM required during initialisation will typically be in range 44GB to 66GB. A model that fully utilises two 11 GB GPUs (i.e. a 100 million cell model) may require as much as 128GB of CPU RAM during initialisation.

===CUDA Cores, GPU Clock speed, and FLOPs===
One way of reporting a GPU card's throughput is in Floating Point Operations per second (FLOPs). The more FLOPs, the more calculations that can get crunched per second and the faster the model should run. For any given generation of GPU, FLOPs are approximately proportional to number of CUDA cores times the GPU clock speed. However, there have been significant improvements in GPU architecture since the inception of CUDA, and this has contributed to increases in overall FLOPs performance beyond just the increases in cores and clock speed that have occurred over this time.

===Multiple GPUs===
TUFLOW can use multiple GPU cards on a machine to run a single model (TUFLOW FV can currently use a single GPU only). This is useful for models that are too large for a single GPU, or for running a model as quickly as possible. In general terms the run time benefit of using multiple cards increases with model size.
* TUFLOW HPC-GPU does not support SLI for inter-GPU communications.
* It does (as of build 2020-01-AA) auto detect and utilise peer-to-peer access over NVLink or PCI bus on the motherboard. Note that not all GPUs support peer-to-peer access.
** PCI bus - this method requires cards that supports TCC driver mode and all cards must be in TCC driver mode. As TUFLOW primarily relies on GPU CUDA capabilities, the impact of using higher or lower PCI slot option is minimal.
** NVLink - high-end compute cards can have up to 8 cards talking to each other through a high-spec NVLink, but many of the less expensive cards are limited to only having two connected together over a dual socket NVLink.
* Models may still be run across multiple GPUs even if a NVLink is not present and the GPUs do not support peer-to-peer access. In this case HPC reverts to exchanging the domain boundary data between the GPUs via the CPU. The memory bandwidth between the GPU and the main system is not a critical bottleneck for TUFLOW.
* When using multiple GPUs it is best to use cards of similar memory and performance. While it is possible (as of build 2020-01-AA) to re-balance a model over multiple GPUs, we do not recommend using cards with vastly disparate performance.
* Sufficient cooling and power supply should be considered if multiple cards are used. When installed in adjacent PCI slots, the preference is to use rear vented cards rather than side vented to avoid blowing hot air onto the neighbouring cards (which could lead to overheating).

===GPU Performance Comparison===
Extensive GPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking_(2018-03-AA)| Hardware Benchmarking]] page of the Wiki. Review the GPU benchmarking runtime results table to compare the speed performance of different cards. If your GPU card is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to support@tuflow.com. We will add the details to the runtime results table. 

External videocard benchmark websites can be used to compare GPU cards, for example, [https://www.videocardbenchmark.net/high_end_gpus.html PassMark Software - Video Card (GPU) Benchmarks] is an excellent performance guide.
 

=CPU Advice=
In general terms a more recent architecture, higher clock speed CPU with a large cache will perform better than a slower clock speed chip. This section discusses CPU RAM, RAM speed, Processor frequency, Multi-core processing and hyper-threading.

===CPU RAM===
The amount of CPU RAM will determine the size of the model that can be run or a number of models that can be run at one time.
Faster RAM will result in quicker runtimes, however this is usually a secondary consideration to chip speed, cache size and architecture.

===CPU Cores===
* TUFLOW HPC - Run on GPU Hardware: The parallel processing is being done on the GPU card. However, TUFLOW HPC-GPU still uses the CPU for model initialisation and for 1D calculations. If multiple GPU cards are used, TUFLOW will use the equivalent number of CPU threads for controlling the GPUs and migrating data. So for a machine dedicated to HPC-GPU modelling, the number of CPU cores should be higher than the number of installed GPUs.
* TUFLOW HPC - Run on CPU Hardware: HPC model can also be run on multiple CPU cores. For the comparison of simulation speed, please refer to [[Hardware_Benchmarking_Topic_HPC_on_CPU_vs_GPU | HPC on CPU vs GPU]].
* TUFLOW Classic: TUFLOW Classic simulation can only use one CPU core due to the implicit nature of the numerical solution. More CPU cores will enable running more simulations at the same time most efficiently.

===Hyperthreading===
https://fvwiki.tuflow.com/index.php?title=TUFLOW_FV_Parallel_Computing

===Processor Frequency and RAM Frequency===
The frequency directly affects the run times. In general, the higher the frequency, the faster the model runs.

===CPU Performance Comparison===
Extensive CPU hardware speed comparison testing has been completed using TUFLOW's standardised hardware benchmarking dataset. Details for the benchmarking are available via the [[Hardware_Benchmarking_(2018-03-AA)| Hardware Benchmarking]] page of the Wiki. Review the CPU benchmarking runtime results table to compare the speed performance of different chips. If your chip is not listed in the result dataset please download and run the benchmarking dataset, and provide the result summary to support@tuflow.com. We will add the details to the runtime results table. 
 

=Storage Advice=
Solid state hard drives are preferred for temporary storage as they are faster to write to than traditional hard drives. Large data files can then be transferred to a more permanent location.
 
{{Tips Navigation
|uplink=[[Main_Page| TUFLOW Main Page]]
}}

Wibu Dongles

2024-07-01T00:49:22Z

Jaap.vandervelde: Link to cloud licence troubleshooting section

=Introduction=
TUFLOW Products are licenced via Codemeter locks, available in three forms; WIBU USB-2 Dongles (Hardware lock), WIBU Software Licences (Software lock) and WIBU Cloud locks. 
* '''WIBU Hardware Lock''': WIBU hardware locks are physical dongles (USB-2) that contain TUFLOW licences. Licences are coded onto the dongle and can be moved between computers. WIBU hardware locks are recognised by the 2006-06-BD release onwards.
*'''WIBU Software Lock''': WIBU software locks are coded onto the computer's or server's motherboard, it cannot be transferred to a different host. WIBU software locks are recognised by the 2016-03-AF release onwards.
* '''WIBU Cloud Licence''': WIBU cloud licences are available for Network licences, and a hosting on the WIBU cloud server. An internet connection is required to access a cloud licence. WIBU Cloud licences are recognised by the 2016-03-AF release onwards. 
The following pages provide details how to install, update and manage TUFLOW licences using all of the above forms.

=Installation=
==Installing CodeMeter RunTime Kit==
The first step in using the Wibu licence is to install the CodeMeter Runtime Kit. This needs to be installed for any computers that will be running TUFLOW as well as for the network licence server. 
The latest version of CodeMeter can be downloaded from CodeMeter site: 
* [https://www.wibu.com/support/user/downloads-user-software.html https://www.wibu.com/support/user/downloads-user-software.html]
 
The correct file to download is the '''CodeMeter Runtime Kit for Windows''' 
[[File:CodeMeter_RuntimeKit_Download.jpg|400px]]
 
If a computer is used as network license server, please select the "Network Server" option during the installation, so that CodeMeter can configure TCP and UDP protocols in the Windows Firewall. 
[[File:CodeMeter_Network_Server_install.PNG|500px]]
 
 
Once installed the configuration depends on if the TUFLOW licence is a local, network or software licence.
* If this is the first time the licence has been used, or your existing licence has expired. You will need to update your licence file. Please progress to the [[#Request_a_licence_update| Request a licence update]] section
* If there is already an active licence associated with the dongle:
:* For a local licence, the dongle can now be inserted into the machine and TUFLOW simulations can be started.
:* For a network and software licence, continue to the [[#Configuring_Network_Server | configure network server]] and [[#Configuring_Access_to_Network Licence | configure network access]] sections below.

===Silent Install===
It is possible to do a silent install of the CodeMeter Runtime kit. CodeMeter support staff have advised that this can be done with the following parameters: 
<tt>CodeMeterRuntime.exe /ComponentArgs "*":"/qn"</tt>

===Installing CodeMeter RunTime Kit for Linux===
If you are installing on a Linux computer from the command line, refer to:
* [[Installing_Wibu_CodeMeter_Linux|Installing Wibu CodeMeter Linux]]. 

==Configuring Network Server==
If the TUFLOW licence is a network licence, the computer hosting the dongle will need to be configured as a TUFLOW server. This is required even if the simulations are to be performed on the server. Instructions for configuring the network licence are detailed in the following page: 
*[[WIBU_Configure_Network_Server_2016| WIBU Configure Network Server]]

==Configuring Access to Network Licence==
To access TUFLOW licences on a remote network server, the CodeMeter runtime kit needs to be installed on the client machine. Once installed, CodeMeter needs to be configured to use the network licence.
Instructions for configuring the network licence are detailed in the following page: 
*[[WIBU_Configure_Network_Client_2016| WIBU Configure Network Client]]

 

=Updating=
There are a number of reasons that the Wibu licence may need to be updated, for example:
* To add additional modules
* To update to new support year
* To add rental licences
For each change to the dongle, it will be necessary to provide a licence update request file to the TUFLOW staff. 
The procedure is the same for local and network licences, the request will need to be generated from the computer which has the dongle plugged in.
==Request a licence update==
The instructions for creating a licence request differ slightly depending whether the dongle has not previously been coded for TUFLOW simulations or if the dongle has not been provided by BMT. 
'''Hardware Licence (USB)''' 
* [[WIBU_Licence_Update_Request | Wibu licence update request for Windows (normal)]] - Unless specified otherwise by the TUFLOW staff, this option is the correct one to chose.
* [[WIBU_Licence_Update_Request_Uncoded | Wibu licence update request for Windows (uncoded or blank dongle)]] - If you have been provided with a blank dongle or are using a non BMT dongle the TUFLOW producer code needs to be added when requesting the licence update. 
* [[WIBU_Licence_for_Linux | Wibu licence update request for Linux]]
'''Software Licence (File)''' 
* [[WIBU_Software_Licence_Update_Request | Wibu software licence update request for Windows]]
* [[WIBU_Licence_for_Linux | Wibu software licence update request for Linux]]
After creating the licence update request, please email the created file ('''.WibuCmRaC''') to [mailto:sales@tuflow.com sales@tuflow.com]. 
'''Cloud Licence''' 
* Contact sales@tuflow.com.

==Import a licence update==
Once a licence update has been created, an update file will be provide to you via email. This update file will have the extension '''.WibuCmRaU'''. The same method is used for network, local and software licences. 
'''Hardware Licence (USB)'''
* [[WIBU_Licence_Update_Import | Importing a Wibu licence update for Windows]]
* [[WIBU_Licence_for_Linux | Importing a Wibu licence update request for Linux]]
When an update is applied, this modifies the content of the dongle, it does not need to be applied on each computer that will be used for TUFLOW modelling! 
'''Software Licence (File)'''
* [[WIBU_Licence_Update_Softlock_Import |Importing a Wibu licence update for Windows]] 
'''Cloud Licence'''
* [[WIBU_Configure_Cloud_Client | Importing a WIBU Cloud License]].
 

=Troubleshooting=
*[[WIBU_Dongle_Not_Working_Correctly | Dongle Not Working Correctly]]
*[[WIBU_Unable_to_Remove_Licence_Container | Unable to Remove Licence Container]]
*[[WIBU Configure Cloud Client#Troubleshooting|Unable to Connect to Cloud Licence]]

==Diagnostics==
===cmDust===
When the CodeMeter runtime kit is installed a diagnostics utility call '''cmDust''' is also installed. Instructions for creating a diagnostics file:
* [[WIBU_create_cmDust | Create CM Dust Diagnostics File]]

===Enabling Logging===
Codemeter allows you to write extended log files to you local drive. To setup these features:
* [[Codemeter_Enable_Logging | Enable Codemeter Logging]]

=== Enabling Network Server License Monitoring===
Codemeter allows you to conduct real-time licence network monitoring. To setup these features:
* [[Network_Server_License_Monitoring | Network License Monitoring]]

 
{{Tips Navigation
|uplink=[[Main_Page| Back to Wiki Main Page]]
}}

TUFLOW Licensing

2024-03-27T07:04:07Z

Jaap.vandervelde: /* Frequently Asked Questions (FAQ) - What is the best licence for me */

=Introduction=
A TUFLOW licence is required to run TUFLOW, except when using third party software such as a GIS to prepare input data or view results, or when running TUFLOW demo, tutorial or example models in licence free mode. 

==Lock Types==
TUFLOW Products are licenced via locks, available in two forms; WIBU USB-2 Dongles (hardware lock) and WIBU Software Licences (software lock). A third form, WIBU Cloud locks, have been available since 2023.

===Current Licence Lock Options:===
Refer to [[Wibu_Dongles | WIBU Lock Guidance]] for further information on the following licence hosting options:
* '''WIBU Hardware Lock''': WIBU hardware locks are physical dongles (USB-2) that contain TUFLOW licences. Licences are coded onto the dongle and can be moved between computers. WIBU hardware locks are recognised by the 2006-06-BD release onwards.
*'''WIBU Software Lock''': WIBU software locks are coded onto the computer's or server's motherboard, it cannot be transferred to a different host. WIBU software locks are recognised by the 2016-03-AF release onwards.
* '''WIBU Cloud Licence''': WIBU cloud licences are available for Network licences, and a hosting on the WIBU cloud server. An internet connection is required to access a cloud licence. WIBU Cloud licences are recognised by the 2016-03-AF release onwards.

===Legacy Licence Lock Options===
* '''Softlok Dongle''': As of August 2010 Softlok USB dongles are no longer issued due to the dongle provider not supporting 64-bit. Maintained Softlok dongles may be exchanged for a WIBU dongle for a nominal fee, please contact [mailto:sales@tuflow.com sales@tuflow.com]. For the 2009-07, 2008-08, 2007-07 and 2006-06 releases, the “DB” builds or later will need to be used to recognise a WIBU Codemeter dongle. Refer to [[Softlok_Dongles | Softlok Guidance]] for further information.

==Licence Types==
TUFLOW simulations can be executed using a variety of licence types:
* '''Licence Free Mode''': A licence free mode has been built in TUFLOW. For information outlining the limits associated with the licence free mode, see [[New_User_Guide_Free_Demo_Version | TUFLOW Free DEMO Version Guide]]
* '''Local Licence''': TUFLOW simulations can only be run on the computer hosting the Lock. For installation guidance, see [[New_User_Guide_Local_Licences | Local Licence Installation Guide]]
* '''Network Licence''': The Lock can be hosted on any computer or server. Other computers 'check out' licences from the host computer via a company’s network. There are no regional restrictions associated with Network licences. For installation guidance, see [[New_User_Guide_Network_Licences | Network Licence Installation Guide]]. 
* '''Cloud Licence''': The Lock is hosted on a central WIBU cloud server. Other computers 'check out' licences from the host server over an internet connection. There are no regional restrictions associated with Cloud licences. For installation guidance, see [[New_User_Guide_Cloud_Licences | Cloud Licence Installation Guide]]. Note that a cloud licence can either be provided as a Local Cloud Licence, so that TUFLOW simulations can only be run on the computer that have the cloud licence installed, or as a Network Cloud Licence, for the same benefits that a Network Licence provides, but with the added administrative overhead as well. 
 

=Frequently Asked Questions (FAQ) =
== Do I require a TUFLOW licence to create TUFLOW inputs and view results from a TUFLOW simulation? ==
No, a TUFLOW licence is only needed to run a TUFLOW .exe file (excluding tutorial, demo and example models or small models eligible for free mode). Running a TUFLOW .exe is required to:
* Process control files (.tcf, etc), check the data inputs and to construct the model using the GIS layers and other inputs. As part of this process any ERROR, WARNING or CHECK messages are issued to help resolve input data conflicts. Check files and GIS layers representing the final model construct are also produced to quality control the model’s inputs.
* To carry out the hydraulic computations provided Step 1 above produces no ERROR messages.
No licence is needed for all other tasks, including:
* Creation and editing of all input files and GIS layers.
* Running GIS plugins such as the QGIS TUFLOW Viewer.
* Running utilities (e.g. asc_to_asc.exe).
* Reviewing check files/layers in GIS.
* Viewing results (e.g. using TUFLOW Viewer in QGIS).
All TUFLOW inputs and outputs use free open formats that are readable and editable by third party software, for example QGIS and Notepad++:
* Download Notepad++ to create and review tabular data: [[NotepadPlusPlus_Tips | Notepad++ installation and tips]].
* Download QGIS: [[QGIS_Tips | QGIS installation and tips]].
* Install the TUFLOW Plugin: [[TUFLOW_QGIS_Plugin | TUFLOW QGIS plugin installation and tips]].
* Use TUFLOW Viewer to review XMDF results: [[TUFLOW_Viewer |TUFLOW Viewer]]. 

==Why is a pre 2010 version of TUFLOW not working?==
In 2010 [[TUFLOW_Licensing#Softlok_Dongles_.28Legacy_Product.29 | Softlok dongles]] were replaced by WIBU dongles. TUFLOW versions earlier than 2010 might be searching for a Softlok licence, however it is likely you have a WIBU licence. The "DB" builds of TUFLOW were created so earlier versions of TUFLOW recognise the new WIBU licences. Please download a "DB" version from the [https://tuflow.com/downloads/tuflow-classichpc-archive/ TUFLOW website].

==How many simulations can be run at the same time?==
The number of licences reflect how many TUFLOW simulations can be run in parallel at any given time. For example, a Local 4 can run 4 simulations at the same time on the one computer. A Network 5 allows up to 5 simulations at any one time across an organisation’s network. If all licences are in use when a TUFLOW simulation starts, the simulation enters a holding pattern until a free licence is available.

== What is the best licence for me? ==

=== Hardware vs. Software ===
The advantage of a hardware lock is that it is portable and not tied to a specific computer. You can unplug it and plug it into another computer. A software lock is tied to a specific computer and cannot be moved once bound to that computer. This also means that if the computer changes substantially, the lock may become invalid and may need replacement.

This is especially relevant if you install the lock on a virtual machine (VM), since migrating the VM or rebuilding it can cause the lock to become invalid. Specifically, if you run a VM in the cloud as a licence server, you need to keep in mind that stopping and starting the VM is safe. But only retaining the physical storage and basing a new VM on it will invalidate the licence.

The advantage of a software lock is that it can be installed on a computer that you don't have physical access to, and doesn't require a free USB port. This makes software locks well-suited to installation on VMs, or remote computers.

=== Local vs. Network ===
The advantage of a local lock is that you only need CodeMeter installed on the computer that will be running your TUFLOW software, and the required configuration will be minimal. No network access beyond this computer is required. The lock is either installed directly on this local CodeMeter, as a software lock, or CodeMeter will pick up an inserted hardware lock automatically.

The advantage of a network lock is that you can manage all your locks in a single place (called the CodeMeter Network Server), and that licences can very easily be accessed from multiple computers on your network. However, this does mean that each additional computer that needs to be able to run TUFLOW will also need CodeMeter installed. These extra instances of CodeMeter need to be configured to find the Network Server. And these computers need to be able to access the Network Server over port 22350, which may require some cooperation of your IT staff to configure.

=== Cloud vs. non-Cloud ===
The advantage of a cloud licence is that you can install it on as many machines as you like, and reuse it on future machines, for as long as the licence is valid. This gives you a similar advantage to using a Network Licence, without the complexity of network connectivity. Another benefit of this is that you can put the licence on computers that are not connected to your local network, which would make using a Network Licence on a Network Server on your network impossible, while Local Software Licences would not be reusable.

A disadvantage of a cloud licence can be the requirement that the computer it is installed on has https (web) internet access to `wibu.cloud`. Using a Local Cloud Licence also means that you need to distribute your licence to many locations, which may be a security concern.

Since Cloud Licences can be provided as either Local Cloud or Network Cloud licences, you can have the benefits of both combined: a Cloud Network Licence would allow you to licence computers not connected to your local network, while not requiring https access to wibu.cloud for each machine running TUFLOW. Instead you can organise network connections from the computers running TUFLOW to the Cloud Network Licence server, while the entire network can be independent of your local network. This makes the Cloud Licence ideal for use in situations where you want to create your own cloud infrastructure for running TUFLOW.{{Tips Navigation
|uplink=[[Main_Page| TUFLOW Main Page]]
}}

TUFLOW Licensing

2024-03-27T06:25:40Z

Jaap.vandervelde: Update to date + clarification of Local vs Network Cloud Licence

Organisation Cloud Software Execution

2023-12-15T04:06:55Z

Jaap.vandervelde: /* Technical Terms Glossary */ Alphabetical ordering

The TUFLOW [https://www.tuflow.com/Download/Licensing/TUFLOW%20Products%20Licence%20Agreement.pdf End User Licence Agreement] was updated in 2018 allowing companies to host their own licences on the cloud. The only restrictions associated with users running TUFLOW simulations on their own company public or private cloud environment are:
<ol>
<li> The licence must be a “Network” type (use of “Local” licences is not permitted on the cloud).
<li> Usage of TUFLOW software on a virtual machine is confined to Authorised Users within the Licensee's Network. This clause means companies cannot on-sell access to TUFLOW licences hosted in the cloud or otherwise (excluding TUFLOW vendor contract arrangements).
</ol>

Configuration of your cloud environment is your own responsibility. There are numerous ways TUFLOW licensing and simulation can be configured in a cloud environment depending on the cloud provider (Microsoft, Google, Amazon, other etc.) and internal company protocols. We recommend engaging a professional with suitable cloud architecture expertise to design your bespoke system. Clients who have already migrated to the cloud have done so in a variety ways:
* Some use a hardware lock (USB) dongle that resides in their office on a physical computer or server. Cloud virtual machines link to the network licence via the IP address of the hardware lock.
* Others use a software lock. Software locks are a digital licence file that is locked to a dedicated host computer, server or virtual machine. When using a software lock please select the host carefully as the software licence will be bound to it. Relocating the licence to a new location will require TUFLOW sales staff to reissue the licence, which incurs a small administration fee.

'''Please Note: Network licence rentals can be used to upscale the available licences on your cloud system when demand requires it.'''
Refer to the [https://www.tuflow.com/Prices.aspx TUFLOW Pricelist] for more information.

This detailed report from the TUFLOW Library discusses some benefits, challenges and solutions relating to cloud computing to help people who are setting up their own system:
[https://downloads.tuflow.com/Licensing/2021_Running_TUFLOW_on_the_Cloud.pdf Running TUFLOW on the Cloud (Whitepaper)] 
[[File:2021_Running_TUFLOW_on_the_Cloud.png]] 
 
= Common Questions Answered (FAQ)=
== Q1: How do I execute a simulation on the cloud? Can I still use batch files? ==
Running a simulation on the cloud can be very similar to running it on any other computer. You can access a VM remotely just like you would any other remote computer, using Remote Desktop, SSH, VNC, an X-Server client, etc. - whatever you are used to and what is set up on the VM. However, that assumes the VM is set up for that type of access and is running when you need to connect to it. If you want to make use of the real benefits of the cloud, like the ability to run on many computers at once, starting them automatically only when needed, doing it through such a process would be very cumbersome. You may want to consider looking at more advanced techniques like [https://azure.microsoft.com/en-au/products/batch Azure Batch], AWS Batch, or [https://cloud.google.com/batch/docs/get-started Google Cloud Batch].

In either case, you will need access to a TUFLOW licence server from VMs running the model. Have a look at "Do I need a different licence to run models on the cloud?" below. And the VMs will always need to have CodeMeter installed, configured to find the licence you plan to use, as well as appropriate drivers for hardware like GPUs.

When running on the cloud, consider that you may not have network access to locations where you would normally store your results. You may need to set up storage in the cloud separate from the VM, but connected to it, to collect your results and still have them available to you once the VM stops running.

If you're using remote access to desktop VMs, you can still use ''batch files'' or scripts like you're used to. If you look into batch services, you will need more involved scripting, and you would typically not use batch files, but split up the work into separate tasks for the cloud platform to schedule on available computers. Keep in mind that this is a substantial and complex task, requiring some development and IT skills. If you plan on this type of cloud use, plan ahead and be ready with a working and tested solution, before you take on a deadline.
== Q2: Do I need a different TUFLOW executable to run models on the cloud? ==
No, you can use the same executable appropriate to the operating system you are on. Keep in mind that running TUFLOW with a licence does require that CodeMeter is installed as well and configured to find the licence. And if you are using a GPU on the cloud, you will need to have the appropriate NVIDIA drivers with CUDA installed, and a GPU licence available.

Although you do use the same executable, it may be advantageous to provide some additional command line options to TUFLOW when you run it on the cloud. Since you typically won't be present and looking at the screen, consider using the `-nc` switch, which prevents user interaction on the console. Also, the familiar `-b` option will prevent the simulation waiting for a key press at the end of the simulation. And finally, given the possible cost of running models at scale, you would do well to test your model with the `-t` switch before sending it to the cloud. In addition to command line options, learn about TUFLOW override files to override configuration that may need to be different on the cloud VM, like the location where TUFLOW should write results.
== Q3: What steps do I need to take to run my model on the cloud? ==
In no particular order:

* Assuming you have chosen a cloud provider you will use, make sure you understand the answers to the previous questions. If some of this is too technical, ensure you go over this with staff with appropriate IT skills and administrative access.
* With regard to the model itself, ensure that it has no references to files on computers that wouldn't be accessible from the cloud VM running the model. Ideally, construct your model configuration so that it can be self-contained within a single folder and would run wherever you put it.
* Ensure you have sufficient TUFLOW licences available and accessible to your cloud VMs to run the number of simulations you plan to run in parallel on the cloud.
* Ensure you have sufficient quota for storage and cloud resources you need to run the number of simulations you plan to run, specifically when using the 'Batch' services mention under Q1.
* Ensure you have the right level of access to make use of the cloud resources you need, and that you're able to use and manage them when you do.
* Ensure that what you're planning on the cloud complies with your company and client's security policies for the work. Think about where the cloud computers are, how data is transferred to and from the cloud, and who has access.
* If you can, pick a region that puts the compute and storage relatively close to your own location, ensuring that your access (or perhaps your clients' access) to them over the internet can achieve good total network speeds.
* Test you model before putting it on the cloud and test your preferred method of running a model on the cloud before scaling it up.
* Make sure your model configuration matches your actual needs before sending it to the cloud. Consider the frequency of writing outputs, whether you need check files, etc.

When in doubt, feel free to contact [mailto:support@tuflow.com TUFLOW Support] and [mailto:sales@tuflow.com TUFLOW Sales] with questions, but keep in mind that we can only offer limited guidance when it comes to the specifics of your chosen cloud provider, and that your company's IT policies may further limit your options.

== Q4: How can I download the simulation results? ==
This depends on your chosen solution.

If you have cloud VMs that have access to your company's internal network, you may be able to copy the results automatically (with a script or batch file) after a simulation completes, and no download would be needed. If you have cloud VMs that you interactively use remotely, you can use whatever tools you would use from any remote machine, like OneDrive, Dropbox, FTP, SSH, to name but a few.

However, all cloud service providers also provide cloud storage, and it may be cheaper and faster to keep unprocessed results in the cloud. Once a run completes, you typically do not want to keep the results on storage that is local to the VM that ran the model (e.g. its C: or D: drive on a Windows computer), unless you plan to use the same VM for post-processing of the results. But you can set up network file shares in the cloud that can be connected to your VM as extra drives or mounts, or you can make use of blob storage like Azure Blob, S3 Buckets, etc. Depending on the cloud service provider, there will be relatively user-friendly tools to access these remotely and download your data later.

For particularly massive datasets, some cloud providers also offer services where they can put the data on physical media and ship them to you. However, keep in mind that this takes substantial time to reserve beforehand and then some time to execute after you complete the work. And the service may not be available for smaller volumes you may need.

Finally, at the risk of stating the obvious: perform the download on a good internet connection. Cloud providers charge a small amount per GB downloaded, and in return they offer very good download speeds for your data. But your internet connection may end up limiting how quickly you get your data to your computer.
== Q5: What are the benefits of running a simulation in the cloud rather than locally? ==
Not all benefits apply in all cases, but consider these:

* You can get access to as many cloud VMs (and GPUs) you need to run as many runs you need in parallel, provided you have sufficient licences and quota with the provider.
* If you only need compute infrequently, it's there in the cloud when you need it and you only pay for it when you use it.
* If your workload suddenly increases (which may be a good thing), you can quickly increase the amount of compute with cloud computing, provided you're set up to do so.
* Most cloud providers offer access to a variety of very capable hardware, that may allow you to run models larger or longer running than you could on your own hardware.
* If you collaborate with others from various locations (wherever they are in the world), having the results in the cloud may be a real benefit.

However, there are some potential downsides to consider as well:

* If you make efficient use of hardware you own, the compute is likely cheaper per model run than it would be compared to cloud computing, especially for on-demand compute.
* Although it's not very complicated to set up a VM for cloud runs and to get up and running, it may be complicated to do so in a way that satisfies your company or client's security policies.
* Similarly, just running some models on an interactively accessible VM may be simple, but developing scripts for automated model running may require time and skills that prevent you from doing so yourself.

== Q6: Do I need to add in any extra commands in my control files? ==
If your model is self-contained and could run from its folder on any computer, perhaps not. However, you may want to change where a VM in the cloud tries to write its results, for example. You can achieve that with extra command in your control files, but also consider the use of TUFLOW override control files, which you can tailor to the cloud VMs you're using, without affecting the control files you use for running or testing locally.

To keep costs of storage and transport manageable, as well as saving on some run time, configure your model to write only the outputs you need. This includes selecting the right variables to output, at the appropriate time intervals. Have a look at our [https://www.youtube.com/watch?v=-CsKKjG7jpQ Output Management Advice] webinar (15 minutes) for more tips on that.

Also look at the command line switches mentioned in the answer to Q2.
== Q7: Do I need a different licence to run models on the cloud? ==
Not necessarily, but there are some things to keep in mind. If your existing licences are on a dongle, they would need to be network licences and the server they are installed on would have to be accessible over the network from the cloud VMs you're looking to run models on. If you have sufficient existing network licences you can use in this manner, including licences for special hardware you'd be using on the cloud (like a GPU), you will not need different licences.

You can also set up a dedicated VM to run a small CodeMeter network licence server in the cloud for software network licences. But keep in mind that licences on such a server cannot be moved elsewhere - they are bound to this specific VM. Access to this licence server would be limited to VMs in the cloud, on the same virtual network as the licence server. Or you'd need to have someone with the appropriate IT skills make the licence server accessible from all locations you need access from.

Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.
== Q8: What can go wrong when running models on the cloud? ==
For starters, almost everything that can go wrong when running models locally, although power failure and loss of network connection is exceedingly rare on the cloud.

Common problems arise from the differences in the computer's environment: software you may have installed that batch files rely on, software required to run TUFLOW (CodeMeter, NVIDIA drivers for GPU), access to networked resources you get inputs from, or write results to, etc.

Also, if you're using Batch services from your cloud provider, once a VM completes its tasks, it may disappear. If something went wrong during the run, you may have very limited access to information about what went wrong, so you want to be careful about logging and where logs are written to.

Similarly, but much simpler: of you run models interactively on a desktop VM, once you turn it off, you will no longer have access to its local storage. And once you remove the VM to save on cost, keep in mind that its attached disk storage will be removed as well, so ensure you have your results in a safe place before that.

Finally, access to licences using Codemeter from the cloud VM can sometimes cause some complications. And access for users to the VM or the data may cause some complications, depending on your IT setup.

None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.
== Q9: If I stop the cloud VM after models are finished, can I still download the results? ==
If the results were written to local storage on the VM (like the default C: or D: drive on a Windows VM), you will only be able to access these when the cloud VM is running. If you stopped it, you could restart it to gain access again. Once you delete the VM, data on those volumes will be deleted as well, and cannot be recovered.

To be able to access results in the cloud even when a VM is stopped, or deleted, copy the results to a network share on the cloud. On the VM, you may be able to mount this storage as a network share, or tools will be available to perform a copy to cloud storage, depending on the cloud provider and operating system you are using.
== Q10: Why is my run on the cloud slower than I expected based on the specs? ==
Although cloud hardware may be faster for some use cases, and certainly a lot more expensive to purchase, it may not be guaranteed to run your TUFLOW model faster. This mostly depends on how modern the NVIDIA hardware architecture is, how many CUDA cores it has available and specific metrics of the hardware like the amount of memory, the clock speed of the memory, the clock speed of the cores, and how the GPU is connected to the rest of the hardware. For a good assessment of whether you should expect better performance, refer to our [[Hardware Benchmarking (2018-03-AA)|Hardware Benchmarking]] pages.

If you're wondering why TUFLOW software doesn't benefit from these supposedly faster and more expensive GPUs, consider that a GPU has many different features, and TUFLOW only makes use of an important subset of these. Also, most TUFLOW models are executed using the single-precision floating-point executable, which is faster than the double-precision executable. Desktop GPUs are highly optimised for single-precision compute, because this is what benefits gaming, and as it happens, TUFLOW runs. Data centre GPUs are more optimised for double-precision compute, but most TUFLOW simulations don't benefit in result quality from using this.

Even when the hardware should be faster according to benchmarks, it's possible that you have some other restrictions. For one, if your cloud environment shares GPUs between many users, the part of the GPU available to your model run may only see a small percentage of the performance it would show with exclusive access to the GPU. This is particularly true in Virtual Desktop Infrastructure (VDI) setups. The way TUFLOW uses the GPU is very different from normal graphics processing, and VDI solutions are often not good for model running.

Another common cause of slowing is writing results directly to network shares that may be accessed over network connections that are orders of magnitude slower than local disk access. In these situations, the recommendation is to write results locally (with minimal overhead) on the cloud VM and then copy the results to other storage in one go, when the run completes. Even if you perform this copy while another run starts, you'll find that running first and copying after is a lot faster than writing directly to the network share. To understand why, imagine writing and sending an email one word at a time, or writing it all in one go. The amount of typing you have to do is roughly the same, if you do it cleverly, but clearly the whole process will take longer, and you can imagine the network having to send far more data back and forth. The difference between writing results to the network one part at a time, instead of all at once is analogous.
== Q11: How can I lower the cost of running simulations on the cloud? ==
The first step would be to select the hardware that's best suited to your needs, at the lowest price, from the most affordable provider.

Secondly, if you get cloud hardware on-demand, you're paying the highest rates for the flexibility this affords. You can also reserve instances of specific hardware types, for periods like a year, or three years (depending on the cloud provider), dramatically lowering the price - but then you will have to pay for the entire period for the reserved instances. If your organisation is large enough, it can be worthwhile to have access to a pool of reserved resources, as long as the business achieves high utilisation over time, so that you only pay on-demand prices when you exceed your reserved instances.

If you do end up using on-demand hardware, ensure you only run it when you're actually using it. By automatically turning off VMs when the work is done and copied to appropriate storage, you can save on compute costs - you're not paying for how much power they use, you're paying for the hours they're on. And keep data on cheap storage like blob storage or online file shares, where you pay only for the size you're using, instead of keeping expensive VMs around that have massive virtual hard drives that you're paying for as long as they exist, empty or not.

Don't download data repeatedly, especially if you need access to it frequently. If you only need access to a small part of the data, it may be worth it to do so remotely. But if you need to process entire files, or multiple users need a copy, it will be more economical to download the data to your network once and use it from there.

You may have heard about 'spot pricing' for VMs. This may be suitable if you're running many small simulations in sequence, and if you're not under strict time pressure to deliver results, but in many cases, it won't be ideal, especially if your model is not set up with restart files that get stored away from the VM. We find that the added complexity rarely outweighs the price difference for the hardware, but the discounts on VMs obtained through spot pricing can be substantial.

If you find that the number of licences you need to scale up model running on the cloud is the main limiting factor for cost, contact our [mailto:sales@tuflow.com TUFLOW Sales] to discuss options for your situation.

Finally, read through these questions, and take the advice given to heart. Optimising your model configuration and making the right choices when running on the cloud can save a lot of run time, and thus cost.
== Q12: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==
As of 2019, TUFLOW offer an [[TUFLOW Cloud Simulation Service|on-demand cloud simulation service]] that may suit your needs if your project is sufficiently urgent or large. As of 2023, you may find third parties providing services on the cloud as well, and TUFLOW may support use of its software in such services.
== Q13: Which machine size / hardware type do you recommend for my model runs? ==
Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.

However, some comments that generally apply:

* As with physical hardware, top speed comes at a premium. If you compare model run times between different VM sizes, you may find that running on the slower machines may work out cheaper for a certain amount of work, than using the faster ones. Of course, you will have to consider project lead time, and time spent on licences as well.
* For most cloud providers, the number of vCPU cores scales together with the type and number of available GPUs. And together with vCPUs, the amount of available RAM and storage scales up as well. As a result, you may end up with a lot of unused resources on some machine types.
* If you're considering purchasing cloud infrastructure for permanent use, keep in mind that Virtual Desktop Infrastructure solutions often share resources like GPUs between many users. You may find that a specific type of hardware works really well in a test setup, where you're the only user on it, but performs really poorly when under load from many users. If you purchase access to a cloud VM directly, you will have it all to yourself, but additional infrastructure on top of the VMs may affect your performance greatly.
* Conversely, when selecting a VM type that provides access to only 'half' of a data centre VM, you don't have to worry about negative performance impact. This type of sharing (that your IT can also achieve in your own data centre with NVIDIA MIG) still ensures that you always get full access to a dedicated part of the GPU and performance should be as expected.
== Technical Terms Glossary ==
A brief explanation of some of the technical terms used in this FAQ, and relevant to cloud model running:

* '''Azure Batch''': A cloud computing service provided by Microsoft Azure for running large-scale parallel and batch compute jobs.
*'''Azure Blob''': Microsoft Azure's object storage solution for the cloud.
*'''AWS Batch''': Amazon Web Services' batch computing service that enables the processing of a large number of batch jobs.
*'''Blob Storage (Binary Large Object Storage)''': A storage service for large amounts of unstructured data.
*'''CodeMeter''': A software technology developed by WIBU, used by TUFLOW for software licensing and protection.
*'''CUDA''': A parallel computing platform and application programming interface model created by Nvidia.
*'''GPU (Graphics Processing Unit)''': A specialized processor designed to accelerate graphics rendering.
*'''Google Cloud Batch''': A batch computing service provided by Google Cloud, similar in functionality to Azure Batch and AWS Batch.
*'''Network File Shares''': Storage locations on a network that multiple users can access to store and retrieve files, as on a regular file system.
*'''NVIDIA MIG (Multi-Instance GPU)''': A technology that provides hardware partitioning of NVIDIA GPUs.
*'''On-Demand Compute''': A cloud computing service model where computing resources are made available immediately to the user as needed.
* '''Remote Desktop''': A program or feature that allows a user to connect to a computer in another location, see that computer's desktop, and interact with it as if it were local.
*'''S3 Buckets''': Amazon Web Services' scalable storage buckets in the cloud.
*'''Spot Pricing''': A pricing model in cloud computing where available compute capacity can be purchased at potentially lower costs compared to on-demand rates.
*'''SSH (Secure Shell)''': A cryptographic network protocol for operating network services securely over an unsecured network.
*'''Virtual Desktop Infrastructure (VDI)''': Technology that hosts a desktop operating system on a centralized server in a data center.
*'''VM (Virtual Machine)''': A software emulation of a physical computer that runs an operating system and applications just like a physical machine.
*'''VNC (Virtual Network Computing)''': A graphical desktop-sharing system that uses the Remote Frame Buffer protocol to remotely control another computer.
* '''X-Server''': A program that manages and displays graphical user interfaces in a Unix or Linux environment.

Organisation Cloud Software Execution

2023-12-15T04:04:21Z

Jaap.vandervelde: Numbering error

The TUFLOW [https://www.tuflow.com/Download/Licensing/TUFLOW%20Products%20Licence%20Agreement.pdf End User Licence Agreement] was updated in 2018 allowing companies to host their own licences on the cloud. The only restrictions associated with users running TUFLOW simulations on their own company public or private cloud environment are:
<ol>
<li> The licence must be a “Network” type (use of “Local” licences is not permitted on the cloud).
<li> Usage of TUFLOW software on a virtual machine is confined to Authorised Users within the Licensee's Network. This clause means companies cannot on-sell access to TUFLOW licences hosted in the cloud or otherwise (excluding TUFLOW vendor contract arrangements).
</ol>

Configuration of your cloud environment is your own responsibility. There are numerous ways TUFLOW licensing and simulation can be configured in a cloud environment depending on the cloud provider (Microsoft, Google, Amazon, other etc.) and internal company protocols. We recommend engaging a professional with suitable cloud architecture expertise to design your bespoke system. Clients who have already migrated to the cloud have done so in a variety ways:
* Some use a hardware lock (USB) dongle that resides in their office on a physical computer or server. Cloud virtual machines link to the network licence via the IP address of the hardware lock.
* Others use a software lock. Software locks are a digital licence file that is locked to a dedicated host computer, server or virtual machine. When using a software lock please select the host carefully as the software licence will be bound to it. Relocating the licence to a new location will require TUFLOW sales staff to reissue the licence, which incurs a small administration fee.

'''Please Note: Network licence rentals can be used to upscale the available licences on your cloud system when demand requires it.'''
Refer to the [https://www.tuflow.com/Prices.aspx TUFLOW Pricelist] for more information.

This detailed report from the TUFLOW Library discusses some benefits, challenges and solutions relating to cloud computing to help people who are setting up their own system:
[https://downloads.tuflow.com/Licensing/2021_Running_TUFLOW_on_the_Cloud.pdf Running TUFLOW on the Cloud (Whitepaper)] 
[[File:2021_Running_TUFLOW_on_the_Cloud.png]] 
 
= Common Questions Answered (FAQ)=
== Q1: How do I execute a simulation on the cloud? Can I still use batch files? ==
Running a simulation on the cloud can be very similar to running it on any other computer. You can access a VM remotely just like you would any other remote computer, using Remote Desktop, SSH, VNC, an X-Server client, etc. - whatever you are used to and what is set up on the VM. However, that assumes the VM is set up for that type of access and is running when you need to connect to it. If you want to make use of the real benefits of the cloud, like the ability to run on many computers at once, starting them automatically only when needed, doing it through such a process would be very cumbersome. You may want to consider looking at more advanced techniques like [https://azure.microsoft.com/en-au/products/batch Azure Batch], AWS Batch, or [https://cloud.google.com/batch/docs/get-started Google Cloud Batch].

In either case, you will need access to a TUFLOW licence server from VMs running the model. Have a look at "Do I need a different licence to run models on the cloud?" below. And the VMs will always need to have CodeMeter installed, configured to find the licence you plan to use, as well as appropriate drivers for hardware like GPUs.

When running on the cloud, consider that you may not have network access to locations where you would normally store your results. You may need to set up storage in the cloud separate from the VM, but connected to it, to collect your results and still have them available to you once the VM stops running.

If you're using remote access to desktop VMs, you can still use ''batch files'' or scripts like you're used to. If you look into batch services, you will need more involved scripting, and you would typically not use batch files, but split up the work into separate tasks for the cloud platform to schedule on available computers. Keep in mind that this is a substantial and complex task, requiring some development and IT skills. If you plan on this type of cloud use, plan ahead and be ready with a working and tested solution, before you take on a deadline.
== Q2: Do I need a different TUFLOW executable to run models on the cloud? ==
No, you can use the same executable appropriate to the operating system you are on. Keep in mind that running TUFLOW with a licence does require that CodeMeter is installed as well and configured to find the licence. And if you are using a GPU on the cloud, you will need to have the appropriate NVIDIA drivers with CUDA installed, and a GPU licence available.

Although you do use the same executable, it may be advantageous to provide some additional command line options to TUFLOW when you run it on the cloud. Since you typically won't be present and looking at the screen, consider using the `-nc` switch, which prevents user interaction on the console. Also, the familiar `-b` option will prevent the simulation waiting for a key press at the end of the simulation. And finally, given the possible cost of running models at scale, you would do well to test your model with the `-t` switch before sending it to the cloud. In addition to command line options, learn about TUFLOW override files to override configuration that may need to be different on the cloud VM, like the location where TUFLOW should write results.
== Q3: What steps do I need to take to run my model on the cloud? ==
In no particular order:

* Assuming you have chosen a cloud provider you will use, make sure you understand the answers to the previous questions. If some of this is too technical, ensure you go over this with staff with appropriate IT skills and administrative access.
* With regard to the model itself, ensure that it has no references to files on computers that wouldn't be accessible from the cloud VM running the model. Ideally, construct your model configuration so that it can be self-contained within a single folder and would run wherever you put it.
* Ensure you have sufficient TUFLOW licences available and accessible to your cloud VMs to run the number of simulations you plan to run in parallel on the cloud.
* Ensure you have sufficient quota for storage and cloud resources you need to run the number of simulations you plan to run, specifically when using the 'Batch' services mention under Q1.
* Ensure you have the right level of access to make use of the cloud resources you need, and that you're able to use and manage them when you do.
* Ensure that what you're planning on the cloud complies with your company and client's security policies for the work. Think about where the cloud computers are, how data is transferred to and from the cloud, and who has access.
* If you can, pick a region that puts the compute and storage relatively close to your own location, ensuring that your access (or perhaps your clients' access) to them over the internet can achieve good total network speeds.
* Test you model before putting it on the cloud and test your preferred method of running a model on the cloud before scaling it up.
* Make sure your model configuration matches your actual needs before sending it to the cloud. Consider the frequency of writing outputs, whether you need check files, etc.

When in doubt, feel free to contact [mailto:support@tuflow.com TUFLOW Support] and [mailto:sales@tuflow.com TUFLOW Sales] with questions, but keep in mind that we can only offer limited guidance when it comes to the specifics of your chosen cloud provider, and that your company's IT policies may further limit your options.

== Q4: How can I download the simulation results? ==
This depends on your chosen solution.

If you have cloud VMs that have access to your company's internal network, you may be able to copy the results automatically (with a script or batch file) after a simulation completes, and no download would be needed. If you have cloud VMs that you interactively use remotely, you can use whatever tools you would use from any remote machine, like OneDrive, Dropbox, FTP, SSH, to name but a few.

However, all cloud service providers also provide cloud storage, and it may be cheaper and faster to keep unprocessed results in the cloud. Once a run completes, you typically do not want to keep the results on storage that is local to the VM that ran the model (e.g. its C: or D: drive on a Windows computer), unless you plan to use the same VM for post-processing of the results. But you can set up network file shares in the cloud that can be connected to your VM as extra drives or mounts, or you can make use of blob storage like Azure Blob, S3 Buckets, etc. Depending on the cloud service provider, there will be relatively user-friendly tools to access these remotely and download your data later.

For particularly massive datasets, some cloud providers also offer services where they can put the data on physical media and ship them to you. However, keep in mind that this takes substantial time to reserve beforehand and then some time to execute after you complete the work. And the service may not be available for smaller volumes you may need.

Finally, at the risk of stating the obvious: perform the download on a good internet connection. Cloud providers charge a small amount per GB downloaded, and in return they offer very good download speeds for your data. But your internet connection may end up limiting how quickly you get your data to your computer.
== Q5: What are the benefits of running a simulation in the cloud rather than locally? ==
Not all benefits apply in all cases, but consider these:

* You can get access to as many cloud VMs (and GPUs) you need to run as many runs you need in parallel, provided you have sufficient licences and quota with the provider.
* If you only need compute infrequently, it's there in the cloud when you need it and you only pay for it when you use it.
* If your workload suddenly increases (which may be a good thing), you can quickly increase the amount of compute with cloud computing, provided you're set up to do so.
* Most cloud providers offer access to a variety of very capable hardware, that may allow you to run models larger or longer running than you could on your own hardware.
* If you collaborate with others from various locations (wherever they are in the world), having the results in the cloud may be a real benefit.

However, there are some potential downsides to consider as well:

* If you make efficient use of hardware you own, the compute is likely cheaper per model run than it would be compared to cloud computing, especially for on-demand compute.
* Although it's not very complicated to set up a VM for cloud runs and to get up and running, it may be complicated to do so in a way that satisfies your company or client's security policies.
* Similarly, just running some models on an interactively accessible VM may be simple, but developing scripts for automated model running may require time and skills that prevent you from doing so yourself.

== Q6: Do I need to add in any extra commands in my control files? ==
If your model is self-contained and could run from its folder on any computer, perhaps not. However, you may want to change where a VM in the cloud tries to write its results, for example. You can achieve that with extra command in your control files, but also consider the use of TUFLOW override control files, which you can tailor to the cloud VMs you're using, without affecting the control files you use for running or testing locally.

To keep costs of storage and transport manageable, as well as saving on some run time, configure your model to write only the outputs you need. This includes selecting the right variables to output, at the appropriate time intervals. Have a look at our [https://www.youtube.com/watch?v=-CsKKjG7jpQ Output Management Advice] webinar (15 minutes) for more tips on that.

Also look at the command line switches mentioned in the answer to Q2.
== Q7: Do I need a different licence to run models on the cloud? ==
Not necessarily, but there are some things to keep in mind. If your existing licences are on a dongle, they would need to be network licences and the server they are installed on would have to be accessible over the network from the cloud VMs you're looking to run models on. If you have sufficient existing network licences you can use in this manner, including licences for special hardware you'd be using on the cloud (like a GPU), you will not need different licences.

You can also set up a dedicated VM to run a small CodeMeter network licence server in the cloud for software network licences. But keep in mind that licences on such a server cannot be moved elsewhere - they are bound to this specific VM. Access to this licence server would be limited to VMs in the cloud, on the same virtual network as the licence server. Or you'd need to have someone with the appropriate IT skills make the licence server accessible from all locations you need access from.

Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.
== Q8: What can go wrong when running models on the cloud? ==
For starters, almost everything that can go wrong when running models locally, although power failure and loss of network connection is exceedingly rare on the cloud.

Common problems arise from the differences in the computer's environment: software you may have installed that batch files rely on, software required to run TUFLOW (CodeMeter, NVIDIA drivers for GPU), access to networked resources you get inputs from, or write results to, etc.

Also, if you're using Batch services from your cloud provider, once a VM completes its tasks, it may disappear. If something went wrong during the run, you may have very limited access to information about what went wrong, so you want to be careful about logging and where logs are written to.

Similarly, but much simpler: of you run models interactively on a desktop VM, once you turn it off, you will no longer have access to its local storage. And once you remove the VM to save on cost, keep in mind that its attached disk storage will be removed as well, so ensure you have your results in a safe place before that.

Finally, access to licences using Codemeter from the cloud VM can sometimes cause some complications. And access for users to the VM or the data may cause some complications, depending on your IT setup.

None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.
== Q9: If I stop the cloud VM after models are finished, can I still download the results? ==
If the results were written to local storage on the VM (like the default C: or D: drive on a Windows VM), you will only be able to access these when the cloud VM is running. If you stopped it, you could restart it to gain access again. Once you delete the VM, data on those volumes will be deleted as well, and cannot be recovered.

To be able to access results in the cloud even when a VM is stopped, or deleted, copy the results to a network share on the cloud. On the VM, you may be able to mount this storage as a network share, or tools will be available to perform a copy to cloud storage, depending on the cloud provider and operating system you are using.
== Q10: Why is my run on the cloud slower than I expected based on the specs? ==
Although cloud hardware may be faster for some use cases, and certainly a lot more expensive to purchase, it may not be guaranteed to run your TUFLOW model faster. This mostly depends on how modern the NVIDIA hardware architecture is, how many CUDA cores it has available and specific metrics of the hardware like the amount of memory, the clock speed of the memory, the clock speed of the cores, and how the GPU is connected to the rest of the hardware. For a good assessment of whether you should expect better performance, refer to our [[Hardware Benchmarking (2018-03-AA)|Hardware Benchmarking]] pages.

If you're wondering why TUFLOW software doesn't benefit from these supposedly faster and more expensive GPUs, consider that a GPU has many different features, and TUFLOW only makes use of an important subset of these. Also, most TUFLOW models are executed using the single-precision floating-point executable, which is faster than the double-precision executable. Desktop GPUs are highly optimised for single-precision compute, because this is what benefits gaming, and as it happens, TUFLOW runs. Data centre GPUs are more optimised for double-precision compute, but most TUFLOW simulations don't benefit in result quality from using this.

Even when the hardware should be faster according to benchmarks, it's possible that you have some other restrictions. For one, if your cloud environment shares GPUs between many users, the part of the GPU available to your model run may only see a small percentage of the performance it would show with exclusive access to the GPU. This is particularly true in Virtual Desktop Infrastructure (VDI) setups. The way TUFLOW uses the GPU is very different from normal graphics processing, and VDI solutions are often not good for model running.

Another common cause of slowing is writing results directly to network shares that may be accessed over network connections that are orders of magnitude slower than local disk access. In these situations, the recommendation is to write results locally (with minimal overhead) on the cloud VM and then copy the results to other storage in one go, when the run completes. Even if you perform this copy while another run starts, you'll find that running first and copying after is a lot faster than writing directly to the network share. To understand why, imagine writing and sending an email one word at a time, or writing it all in one go. The amount of typing you have to do is roughly the same, if you do it cleverly, but clearly the whole process will take longer, and you can imagine the network having to send far more data back and forth. The difference between writing results to the network one part at a time, instead of all at once is analogous.
== Q11: How can I lower the cost of running simulations on the cloud? ==
The first step would be to select the hardware that's best suited to your needs, at the lowest price, from the most affordable provider.

Secondly, if you get cloud hardware on-demand, you're paying the highest rates for the flexibility this affords. You can also reserve instances of specific hardware types, for periods like a year, or three years (depending on the cloud provider), dramatically lowering the price - but then you will have to pay for the entire period for the reserved instances. If your organisation is large enough, it can be worthwhile to have access to a pool of reserved resources, as long as the business achieves high utilisation over time, so that you only pay on-demand prices when you exceed your reserved instances.

If you do end up using on-demand hardware, ensure you only run it when you're actually using it. By automatically turning off VMs when the work is done and copied to appropriate storage, you can save on compute costs - you're not paying for how much power they use, you're paying for the hours they're on. And keep data on cheap storage like blob storage or online file shares, where you pay only for the size you're using, instead of keeping expensive VMs around that have massive virtual hard drives that you're paying for as long as they exist, empty or not.

Don't download data repeatedly, especially if you need access to it frequently. If you only need access to a small part of the data, it may be worth it to do so remotely. But if you need to process entire files, or multiple users need a copy, it will be more economical to download the data to your network once and use it from there.

You may have heard about 'spot pricing' for VMs. This may be suitable if you're running many small simulations in sequence, and if you're not under strict time pressure to deliver results, but in many cases, it won't be ideal, especially if your model is not set up with restart files that get stored away from the VM. We find that the added complexity rarely outweighs the price difference for the hardware, but the discounts on VMs obtained through spot pricing can be substantial.

If you find that the number of licences you need to scale up model running on the cloud is the main limiting factor for cost, contact our [mailto:sales@tuflow.com TUFLOW Sales] to discuss options for your situation.

Finally, read through these questions, and take the advice given to heart. Optimising your model configuration and making the right choices when running on the cloud can save a lot of run time, and thus cost.
== Q12: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==
As of 2019, TUFLOW offer an [[TUFLOW Cloud Simulation Service|on-demand cloud simulation service]] that may suit your needs if your project is sufficiently urgent or large. As of 2023, you may find third parties providing services on the cloud as well, and TUFLOW may support use of its software in such services.
== Q13: Which machine size / hardware type do you recommend for my model runs? ==
Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.

However, some comments that generally apply:

* As with physical hardware, top speed comes at a premium. If you compare model run times between different VM sizes, you may find that running on the slower machines may work out cheaper for a certain amount of work, than using the faster ones. Of course, you will have to consider project lead time, and time spent on licences as well.
* For most cloud providers, the number of vCPU cores scales together with the type and number of available GPUs. And together with vCPUs, the amount of available RAM and storage scales up as well. As a result, you may end up with a lot of unused resources on some machine types.
* If you're considering purchasing cloud infrastructure for permanent use, keep in mind that Virtual Desktop Infrastructure solutions often share resources like GPUs between many users. You may find that a specific type of hardware works really well in a test setup, where you're the only user on it, but performs really poorly when under load from many users. If you purchase access to a cloud VM directly, you will have it all to yourself, but additional infrastructure on top of the VMs may affect your performance greatly.
* Conversely, when selecting a VM type that provides access to only 'half' of a data centre VM, you don't have to worry about negative performance impact. This type of sharing (that your IT can also achieve in your own data centre with NVIDIA MIG) still ensures that you always get full access to a dedicated part of the GPU and performance should be as expected.
== Technical Terms Glossary ==
A brief explanation of some of the technical terms used in this FAQ, and relevant to cloud model running:

* '''Azure Batch''': A cloud computing service provided by Microsoft Azure for running large-scale parallel and batch compute jobs.
* '''AWS Batch''': Amazon Web Services' batch computing service that enables the processing of a large number of batch jobs.
* '''Google Cloud Batch''': A batch computing service provided by Google Cloud, similar in functionality to Azure Batch and AWS Batch.
* '''VM (Virtual Machine)''': A software emulation of a physical computer that runs an operating system and applications just like a physical machine.
* '''Remote Desktop''': A program or feature that allows a user to connect to a computer in another location, see that computer's desktop, and interact with it as if it were local.
* '''SSH (Secure Shell)''': A cryptographic network protocol for operating network services securely over an unsecured network.
* '''VNC (Virtual Network Computing)''': A graphical desktop-sharing system that uses the Remote Frame Buffer protocol to remotely control another computer.
* '''X-Server''': A program that manages and displays graphical user interfaces in a Unix or Linux environment.
* '''CodeMeter''': A software technology developed by WIBU, used by TUFLOW for software licensing and protection.
* '''GPU (Graphics Processing Unit)''': A specialized processor designed to accelerate graphics rendering.
* '''CUDA''': A parallel computing platform and application programming interface model created by Nvidia.
* '''Blob Storage (Binary Large Object Storage)''': A storage service for large amounts of unstructured data.
* '''Azure Blob''': Microsoft Azure's object storage solution for the cloud.
* '''S3 Buckets''': Amazon Web Services' scalable storage buckets in the cloud.
* '''Network File Shares''': Storage locations on a network that multiple users can access to store and retrieve files, as on a regular file system.
* '''Virtual Desktop Infrastructure (VDI)''': Technology that hosts a desktop operating system on a centralized server in a data center.
* '''NVIDIA MIG (Multi-Instance GPU)''': A technology that provides hardware partitioning of NVIDIA GPUs.
* '''Spot Pricing''': A pricing model in cloud computing where available compute capacity can be purchased at potentially lower costs compared to on-demand rates.
* '''On-Demand Compute''': A cloud computing service model where computing resources are made available immediately to the user as needed.

Organisation Cloud Software Execution

2023-12-15T04:03:38Z

Jaap.vandervelde: Added a technical term glossary at the end.

The TUFLOW [https://www.tuflow.com/Download/Licensing/TUFLOW%20Products%20Licence%20Agreement.pdf End User Licence Agreement] was updated in 2018 allowing companies to host their own licences on the cloud. The only restrictions associated with users running TUFLOW simulations on their own company public or private cloud environment are:
<ol>
<li> The licence must be a “Network” type (use of “Local” licences is not permitted on the cloud).
<li> Usage of TUFLOW software on a virtual machine is confined to Authorised Users within the Licensee's Network. This clause means companies cannot on-sell access to TUFLOW licences hosted in the cloud or otherwise (excluding TUFLOW vendor contract arrangements).
</ol>

Configuration of your cloud environment is your own responsibility. There are numerous ways TUFLOW licensing and simulation can be configured in a cloud environment depending on the cloud provider (Microsoft, Google, Amazon, other etc.) and internal company protocols. We recommend engaging a professional with suitable cloud architecture expertise to design your bespoke system. Clients who have already migrated to the cloud have done so in a variety ways:
* Some use a hardware lock (USB) dongle that resides in their office on a physical computer or server. Cloud virtual machines link to the network licence via the IP address of the hardware lock.
* Others use a software lock. Software locks are a digital licence file that is locked to a dedicated host computer, server or virtual machine. When using a software lock please select the host carefully as the software licence will be bound to it. Relocating the licence to a new location will require TUFLOW sales staff to reissue the licence, which incurs a small administration fee.

'''Please Note: Network licence rentals can be used to upscale the available licences on your cloud system when demand requires it.'''
Refer to the [https://www.tuflow.com/Prices.aspx TUFLOW Pricelist] for more information.

This detailed report from the TUFLOW Library discusses some benefits, challenges and solutions relating to cloud computing to help people who are setting up their own system:
[https://downloads.tuflow.com/Licensing/2021_Running_TUFLOW_on_the_Cloud.pdf Running TUFLOW on the Cloud (Whitepaper)] 
[[File:2021_Running_TUFLOW_on_the_Cloud.png]] 
 
= Common Questions Answered (FAQ)=
== Q1: How do I execute a simulation on the cloud? Can I still use batch files? ==
Running a simulation on the cloud can be very similar to running it on any other computer. You can access a VM remotely just like you would any other remote computer, using Remote Desktop, SSH, VNC, an X-Server client, etc. - whatever you are used to and what is set up on the VM. However, that assumes the VM is set up for that type of access and is running when you need to connect to it. If you want to make use of the real benefits of the cloud, like the ability to run on many computers at once, starting them automatically only when needed, doing it through such a process would be very cumbersome. You may want to consider looking at more advanced techniques like [https://azure.microsoft.com/en-au/products/batch Azure Batch], AWS Batch, or [https://cloud.google.com/batch/docs/get-started Google Cloud Batch].

In either case, you will need access to a TUFLOW licence server from VMs running the model. Have a look at "Do I need a different licence to run models on the cloud?" below. And the VMs will always need to have CodeMeter installed, configured to find the licence you plan to use, as well as appropriate drivers for hardware like GPUs.

When running on the cloud, consider that you may not have network access to locations where you would normally store your results. You may need to set up storage in the cloud separate from the VM, but connected to it, to collect your results and still have them available to you once the VM stops running.

If you're using remote access to desktop VMs, you can still use ''batch files'' or scripts like you're used to. If you look into batch services, you will need more involved scripting, and you would typically not use batch files, but split up the work into separate tasks for the cloud platform to schedule on available computers. Keep in mind that this is a substantial and complex task, requiring some development and IT skills. If you plan on this type of cloud use, plan ahead and be ready with a working and tested solution, before you take on a deadline.
== Q2: Do I need a different TUFLOW executable to run models on the cloud? ==
No, you can use the same executable appropriate to the operating system you are on. Keep in mind that running TUFLOW with a licence does require that CodeMeter is installed as well and configured to find the licence. And if you are using a GPU on the cloud, you will need to have the appropriate NVIDIA drivers with CUDA installed, and a GPU licence available.

Although you do use the same executable, it may be advantageous to provide some additional command line options to TUFLOW when you run it on the cloud. Since you typically won't be present and looking at the screen, consider using the `-nc` switch, which prevents user interaction on the console. Also, the familiar `-b` option will prevent the simulation waiting for a key press at the end of the simulation. And finally, given the possible cost of running models at scale, you would do well to test your model with the `-t` switch before sending it to the cloud. In addition to command line options, learn about TUFLOW override files to override configuration that may need to be different on the cloud VM, like the location where TUFLOW should write results.
== Q3: What steps do I need to take to run my model on the cloud? ==
In no particular order:

* Assuming you have chosen a cloud provider you will use, make sure you understand the answers to the previous questions. If some of this is too technical, ensure you go over this with staff with appropriate IT skills and administrative access.
* With regard to the model itself, ensure that it has no references to files on computers that wouldn't be accessible from the cloud VM running the model. Ideally, construct your model configuration so that it can be self-contained within a single folder and would run wherever you put it.
* Ensure you have sufficient TUFLOW licences available and accessible to your cloud VMs to run the number of simulations you plan to run in parallel on the cloud.
* Ensure you have sufficient quota for storage and cloud resources you need to run the number of simulations you plan to run, specifically when using the 'Batch' services mention under Q1.
* Ensure you have the right level of access to make use of the cloud resources you need, and that you're able to use and manage them when you do.
* Ensure that what you're planning on the cloud complies with your company and client's security policies for the work. Think about where the cloud computers are, how data is transferred to and from the cloud, and who has access.
* If you can, pick a region that puts the compute and storage relatively close to your own location, ensuring that your access (or perhaps your clients' access) to them over the internet can achieve good total network speeds.
* Test you model before putting it on the cloud and test your preferred method of running a model on the cloud before scaling it up.
* Make sure your model configuration matches your actual needs before sending it to the cloud. Consider the frequency of writing outputs, whether you need check files, etc.

When in doubt, feel free to contact [mailto:support@tuflow.com TUFLOW Support] and [mailto:sales@tuflow.com TUFLOW Sales] with questions, but keep in mind that we can only offer limited guidance when it comes to the specifics of your chosen cloud provider, and that your company's IT policies may further limit your options.

== Q4: How can I download the simulation results? ==
This depends on your chosen solution.

If you have cloud VMs that have access to your company's internal network, you may be able to copy the results automatically (with a script or batch file) after a simulation completes, and no download would be needed. If you have cloud VMs that you interactively use remotely, you can use whatever tools you would use from any remote machine, like OneDrive, Dropbox, FTP, SSH, to name but a few.

However, all cloud service providers also provide cloud storage, and it may be cheaper and faster to keep unprocessed results in the cloud. Once a run completes, you typically do not want to keep the results on storage that is local to the VM that ran the model (e.g. its C: or D: drive on a Windows computer), unless you plan to use the same VM for post-processing of the results. But you can set up network file shares in the cloud that can be connected to your VM as extra drives or mounts, or you can make use of blob storage like Azure Blob, S3 Buckets, etc. Depending on the cloud service provider, there will be relatively user-friendly tools to access these remotely and download your data later.

For particularly massive datasets, some cloud providers also offer services where they can put the data on physical media and ship them to you. However, keep in mind that this takes substantial time to reserve beforehand and then some time to execute after you complete the work. And the service may not be available for smaller volumes you may need.

Finally, at the risk of stating the obvious: perform the download on a good internet connection. Cloud providers charge a small amount per GB downloaded, and in return they offer very good download speeds for your data. But your internet connection may end up limiting how quickly you get your data to your computer.
== Q5: What are the benefits of running a simulation in the cloud rather than locally? ==
Not all benefits apply in all cases, but consider these:

* You can get access to as many cloud VMs (and GPUs) you need to run as many runs you need in parallel, provided you have sufficient licences and quota with the provider.
* If you only need compute infrequently, it's there in the cloud when you need it and you only pay for it when you use it.
* If your workload suddenly increases (which may be a good thing), you can quickly increase the amount of compute with cloud computing, provided you're set up to do so.
* Most cloud providers offer access to a variety of very capable hardware, that may allow you to run models larger or longer running than you could on your own hardware.
* If you collaborate with others from various locations (wherever they are in the world), having the results in the cloud may be a real benefit.

However, there are some potential downsides to consider as well:

* If you make efficient use of hardware you own, the compute is likely cheaper per model run than it would be compared to cloud computing, especially for on-demand compute.
* Although it's not very complicated to set up a VM for cloud runs and to get up and running, it may be complicated to do so in a way that satisfies your company or client's security policies.
* Similarly, just running some models on an interactively accessible VM may be simple, but developing scripts for automated model running may require time and skills that prevent you from doing so yourself.

== Q6: Do I need to add in any extra commands in my control files? ==
If your model is self-contained and could run from its folder on any computer, perhaps not. However, you may want to change where a VM in the cloud tries to write its results, for example. You can achieve that with extra command in your control files, but also consider the use of TUFLOW override control files, which you can tailor to the cloud VMs you're using, without affecting the control files you use for running or testing locally.

To keep costs of storage and transport manageable, as well as saving on some run time, configure your model to write only the outputs you need. This includes selecting the right variables to output, at the appropriate time intervals. Have a look at our [https://www.youtube.com/watch?v=-CsKKjG7jpQ Output Management Advice] webinar (15 minutes) for more tips on that.

Also look at the command line switches mentioned in the answer to Q2.
== Q7: Do I need a different licence to run models on the cloud? ==
Not necessarily, but there are some things to keep in mind. If your existing licences are on a dongle, they would need to be network licences and the server they are installed on would have to be accessible over the network from the cloud VMs you're looking to run models on. If you have sufficient existing network licences you can use in this manner, including licences for special hardware you'd be using on the cloud (like a GPU), you will not need different licences.

You can also set up a dedicated VM to run a small CodeMeter network licence server in the cloud for software network licences. But keep in mind that licences on such a server cannot be moved elsewhere - they are bound to this specific VM. Access to this licence server would be limited to VMs in the cloud, on the same virtual network as the licence server. Or you'd need to have someone with the appropriate IT skills make the licence server accessible from all locations you need access from.

Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.
== Q8: What can go wrong when running models on the cloud? ==
For starters, almost everything that can go wrong when running models locally, although power failure and loss of network connection is exceedingly rare on the cloud.

Common problems arise from the differences in the computer's environment: software you may have installed that batch files rely on, software required to run TUFLOW (CodeMeter, NVIDIA drivers for GPU), access to networked resources you get inputs from, or write results to, etc.

Also, if you're using Batch services from your cloud provider, once a VM completes its tasks, it may disappear. If something went wrong during the run, you may have very limited access to information about what went wrong, so you want to be careful about logging and where logs are written to.

Similarly, but much simpler: of you run models interactively on a desktop VM, once you turn it off, you will no longer have access to its local storage. And once you remove the VM to save on cost, keep in mind that its attached disk storage will be removed as well, so ensure you have your results in a safe place before that.

Finally, access to licences using Codemeter from the cloud VM can sometimes cause some complications. And access for users to the VM or the data may cause some complications, depending on your IT setup.

None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.
== Q10: If I stop the cloud VM after models are finished, can I still download the results? ==
If the results were written to local storage on the VM (like the default C: or D: drive on a Windows VM), you will only be able to access these when the cloud VM is running. If you stopped it, you could restart it to gain access again. Once you delete the VM, data on those volumes will be deleted as well, and cannot be recovered.

To be able to access results in the cloud even when a VM is stopped, or deleted, copy the results to a network share on the cloud. On the VM, you may be able to mount this storage as a network share, or tools will be available to perform a copy to cloud storage, depending on the cloud provider and operating system you are using.
== Q11: Why is my run on the cloud slower than I expected based on the specs? ==
Although cloud hardware may be faster for some use cases, and certainly a lot more expensive to purchase, it may not be guaranteed to run your TUFLOW model faster. This mostly depends on how modern the NVIDIA hardware architecture is, how many CUDA cores it has available and specific metrics of the hardware like the amount of memory, the clock speed of the memory, the clock speed of the cores, and how the GPU is connected to the rest of the hardware. For a good assessment of whether you should expect better performance, refer to our [[Hardware Benchmarking (2018-03-AA)|Hardware Benchmarking]] pages.

If you're wondering why TUFLOW software doesn't benefit from these supposedly faster and more expensive GPUs, consider that a GPU has many different features, and TUFLOW only makes use of an important subset of these. Also, most TUFLOW models are executed using the single-precision floating-point executable, which is faster than the double-precision executable. Desktop GPUs are highly optimised for single-precision compute, because this is what benefits gaming, and as it happens, TUFLOW runs. Data centre GPUs are more optimised for double-precision compute, but most TUFLOW simulations don't benefit in result quality from using this.

Even when the hardware should be faster according to benchmarks, it's possible that you have some other restrictions. For one, if your cloud environment shares GPUs between many users, the part of the GPU available to your model run may only see a small percentage of the performance it would show with exclusive access to the GPU. This is particularly true in Virtual Desktop Infrastructure (VDI) setups. The way TUFLOW uses the GPU is very different from normal graphics processing, and VDI solutions are often not good for model running.

Another common cause of slowing is writing results directly to network shares that may be accessed over network connections that are orders of magnitude slower than local disk access. In these situations, the recommendation is to write results locally (with minimal overhead) on the cloud VM and then copy the results to other storage in one go, when the run completes. Even if you perform this copy while another run starts, you'll find that running first and copying after is a lot faster than writing directly to the network share. To understand why, imagine writing and sending an email one word at a time, or writing it all in one go. The amount of typing you have to do is roughly the same, if you do it cleverly, but clearly the whole process will take longer, and you can imagine the network having to send far more data back and forth. The difference between writing results to the network one part at a time, instead of all at once is analogous.
== Q12: How can I lower the cost of running simulations on the cloud? ==
The first step would be to select the hardware that's best suited to your needs, at the lowest price, from the most affordable provider.

Secondly, if you get cloud hardware on-demand, you're paying the highest rates for the flexibility this affords. You can also reserve instances of specific hardware types, for periods like a year, or three years (depending on the cloud provider), dramatically lowering the price - but then you will have to pay for the entire period for the reserved instances. If your organisation is large enough, it can be worthwhile to have access to a pool of reserved resources, as long as the business achieves high utilisation over time, so that you only pay on-demand prices when you exceed your reserved instances.

If you do end up using on-demand hardware, ensure you only run it when you're actually using it. By automatically turning off VMs when the work is done and copied to appropriate storage, you can save on compute costs - you're not paying for how much power they use, you're paying for the hours they're on. And keep data on cheap storage like blob storage or online file shares, where you pay only for the size you're using, instead of keeping expensive VMs around that have massive virtual hard drives that you're paying for as long as they exist, empty or not.

Don't download data repeatedly, especially if you need access to it frequently. If you only need access to a small part of the data, it may be worth it to do so remotely. But if you need to process entire files, or multiple users need a copy, it will be more economical to download the data to your network once and use it from there.

You may have heard about 'spot pricing' for VMs. This may be suitable if you're running many small simulations in sequence, and if you're not under strict time pressure to deliver results, but in many cases, it won't be ideal, especially if your model is not set up with restart files that get stored away from the VM. We find that the added complexity rarely outweighs the price difference for the hardware, but the discounts on VMs obtained through spot pricing can be substantial.

If you find that the number of licences you need to scale up model running on the cloud is the main limiting factor for cost, contact our [mailto:sales@tuflow.com TUFLOW Sales] to discuss options for your situation.

Finally, read through these questions, and take the advice given to heart. Optimising your model configuration and making the right choices when running on the cloud can save a lot of run time, and thus cost.
== Q13: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==
As of 2019, TUFLOW offer an [[TUFLOW Cloud Simulation Service|on-demand cloud simulation service]] that may suit your needs if your project is sufficiently urgent or large. As of 2023, you may find third parties providing services on the cloud as well, and TUFLOW may support use of its software in such services.
== Q14: Which machine size / hardware type do you recommend for my model runs? ==
Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.

However, some comments that generally apply:

* As with physical hardware, top speed comes at a premium. If you compare model run times between different VM sizes, you may find that running on the slower machines may work out cheaper for a certain amount of work, than using the faster ones. Of course, you will have to consider project lead time, and time spent on licences as well.
* For most cloud providers, the number of vCPU cores scales together with the type and number of available GPUs. And together with vCPUs, the amount of available RAM and storage scales up as well. As a result, you may end up with a lot of unused resources on some machine types.
* If you're considering purchasing cloud infrastructure for permanent use, keep in mind that Virtual Desktop Infrastructure solutions often share resources like GPUs between many users. You may find that a specific type of hardware works really well in a test setup, where you're the only user on it, but performs really poorly when under load from many users. If you purchase access to a cloud VM directly, you will have it all to yourself, but additional infrastructure on top of the VMs may affect your performance greatly.
* Conversely, when selecting a VM type that provides access to only 'half' of a data centre VM, you don't have to worry about negative performance impact. This type of sharing (that your IT can also achieve in your own data centre with NVIDIA MIG) still ensures that you always get full access to a dedicated part of the GPU and performance should be as expected.
== Technical Terms Glossary ==
A brief explanation of some of the technical terms used in this FAQ, and relevant to cloud model running:

* '''Azure Batch''': A cloud computing service provided by Microsoft Azure for running large-scale parallel and batch compute jobs.
* '''AWS Batch''': Amazon Web Services' batch computing service that enables the processing of a large number of batch jobs.
* '''Google Cloud Batch''': A batch computing service provided by Google Cloud, similar in functionality to Azure Batch and AWS Batch.
* '''VM (Virtual Machine)''': A software emulation of a physical computer that runs an operating system and applications just like a physical machine.
* '''Remote Desktop''': A program or feature that allows a user to connect to a computer in another location, see that computer's desktop, and interact with it as if it were local.
* '''SSH (Secure Shell)''': A cryptographic network protocol for operating network services securely over an unsecured network.
* '''VNC (Virtual Network Computing)''': A graphical desktop-sharing system that uses the Remote Frame Buffer protocol to remotely control another computer.
* '''X-Server''': A program that manages and displays graphical user interfaces in a Unix or Linux environment.
* '''CodeMeter''': A software technology developed by WIBU, used by TUFLOW for software licensing and protection.
* '''GPU (Graphics Processing Unit)''': A specialized processor designed to accelerate graphics rendering.
* '''CUDA''': A parallel computing platform and application programming interface model created by Nvidia.
* '''Blob Storage (Binary Large Object Storage)''': A storage service for large amounts of unstructured data.
* '''Azure Blob''': Microsoft Azure's object storage solution for the cloud.
* '''S3 Buckets''': Amazon Web Services' scalable storage buckets in the cloud.
* '''Network File Shares''': Storage locations on a network that multiple users can access to store and retrieve files, as on a regular file system.
* '''Virtual Desktop Infrastructure (VDI)''': Technology that hosts a desktop operating system on a centralized server in a data center.
* '''NVIDIA MIG (Multi-Instance GPU)''': A technology that provides hardware partitioning of NVIDIA GPUs.
* '''Spot Pricing''': A pricing model in cloud computing where available compute capacity can be purchased at potentially lower costs compared to on-demand rates.
* '''On-Demand Compute''': A cloud computing service model where computing resources are made available immediately to the user as needed.

Organisation Cloud Software Execution

2023-12-15T03:55:55Z

Jaap.vandervelde: Added Q14 on hardware selection

The TUFLOW [https://www.tuflow.com/Download/Licensing/TUFLOW%20Products%20Licence%20Agreement.pdf End User Licence Agreement] was updated in 2018 allowing companies to host their own licences on the cloud. The only restrictions associated with users running TUFLOW simulations on their own company public or private cloud environment are:
<ol>
<li> The licence must be a “Network” type (use of “Local” licences is not permitted on the cloud).
<li> Usage of TUFLOW software on a virtual machine is confined to Authorised Users within the Licensee's Network. This clause means companies cannot on-sell access to TUFLOW licences hosted in the cloud or otherwise (excluding TUFLOW vendor contract arrangements).
</ol>

Configuration of your cloud environment is your own responsibility. There are numerous ways TUFLOW licensing and simulation can be configured in a cloud environment depending on the cloud provider (Microsoft, Google, Amazon, other etc.) and internal company protocols. We recommend engaging a professional with suitable cloud architecture expertise to design your bespoke system. Clients who have already migrated to the cloud have done so in a variety ways:
* Some use a hardware lock (USB) dongle that resides in their office on a physical computer or server. Cloud virtual machines link to the network licence via the IP address of the hardware lock.
* Others use a software lock. Software locks are a digital licence file that is locked to a dedicated host computer, server or virtual machine. When using a software lock please select the host carefully as the software licence will be bound to it. Relocating the licence to a new location will require TUFLOW sales staff to reissue the licence, which incurs a small administration fee.

'''Please Note: Network licence rentals can be used to upscale the available licences on your cloud system when demand requires it.'''
Refer to the [https://www.tuflow.com/Prices.aspx TUFLOW Pricelist] for more information.

This detailed report from the TUFLOW Library discusses some benefits, challenges and solutions relating to cloud computing to help people who are setting up their own system:
[https://downloads.tuflow.com/Licensing/2021_Running_TUFLOW_on_the_Cloud.pdf Running TUFLOW on the Cloud (Whitepaper)] 
[[File:2021_Running_TUFLOW_on_the_Cloud.png]] 
 
= Common Questions Answered (FAQ)=
== Q1: How do I execute a simulation on the cloud? Can I still use batch files? ==
Running a simulation on the cloud can be very similar to running it on any other computer. You can access a VM remotely just like you would any other remote computer, using Remote Desktop, SSH, VNC, an X-Server client, etc. - whatever you are used to and what is set up on the VM. However, that assumes the VM is set up for that type of access and is running when you need to connect to it. If you want to make use of the real benefits of the cloud, like the ability to run on many computers at once, starting them automatically only when needed, doing it through such a process would be very cumbersome. You may want to consider looking at more advanced techniques like [https://azure.microsoft.com/en-au/products/batch Azure Batch], AWS Batch, or [https://cloud.google.com/batch/docs/get-started Google Cloud Batch].

In either case, you will need access to a TUFLOW licence server from VMs running the model. Have a look at "Do I need a different licence to run models on the cloud?" below. And the VMs will always need to have CodeMeter installed, configured to find the licence you plan to use, as well as appropriate drivers for hardware like GPUs.

When running on the cloud, consider that you may not have network access to locations where you would normally store your results. You may need to set up storage in the cloud separate from the VM, but connected to it, to collect your results and still have them available to you once the VM stops running.

If you're using remote access to desktop VMs, you can still use ''batch files'' or scripts like you're used to. If you look into batch services, you will need more involved scripting, and you would typically not use batch files, but split up the work into separate tasks for the cloud platform to schedule on available computers. Keep in mind that this is a substantial and complex task, requiring some development and IT skills. If you plan on this type of cloud use, plan ahead and be ready with a working and tested solution, before you take on a deadline.
== Q2: Do I need a different TUFLOW executable to run models on the cloud? ==
No, you can use the same executable appropriate to the operating system you are on. Keep in mind that running TUFLOW with a licence does require that CodeMeter is installed as well and configured to find the licence. And if you are using a GPU on the cloud, you will need to have the appropriate NVIDIA drivers with CUDA installed, and a GPU licence available.

Although you do use the same executable, it may be advantageous to provide some additional command line options to TUFLOW when you run it on the cloud. Since you typically won't be present and looking at the screen, consider using the `-nc` switch, which prevents user interaction on the console. Also, the familiar `-b` option will prevent the simulation waiting for a key press at the end of the simulation. And finally, given the possible cost of running models at scale, you would do well to test your model with the `-t` switch before sending it to the cloud. In addition to command line options, learn about TUFLOW override files to override configuration that may need to be different on the cloud VM, like the location where TUFLOW should write results.
== Q3: What steps do I need to take to run my model on the cloud? ==
In no particular order:

* Assuming you have chosen a cloud provider you will use, make sure you understand the answers to the previous questions. If some of this is too technical, ensure you go over this with staff with appropriate IT skills and administrative access.
* With regard to the model itself, ensure that it has no references to files on computers that wouldn't be accessible from the cloud VM running the model. Ideally, construct your model configuration so that it can be self-contained within a single folder and would run wherever you put it.
* Ensure you have sufficient TUFLOW licences available and accessible to your cloud VMs to run the number of simulations you plan to run in parallel on the cloud.
* Ensure you have sufficient quota for storage and cloud resources you need to run the number of simulations you plan to run, specifically when using the 'Batch' services mention under Q1.
* Ensure you have the right level of access to make use of the cloud resources you need, and that you're able to use and manage them when you do.
* Ensure that what you're planning on the cloud complies with your company and client's security policies for the work. Think about where the cloud computers are, how data is transferred to and from the cloud, and who has access.
* If you can, pick a region that puts the compute and storage relatively close to your own location, ensuring that your access (or perhaps your clients' access) to them over the internet can achieve good total network speeds.
* Test you model before putting it on the cloud and test your preferred method of running a model on the cloud before scaling it up.
* Make sure your model configuration matches your actual needs before sending it to the cloud. Consider the frequency of writing outputs, whether you need check files, etc.

When in doubt, feel free to contact [mailto:support@tuflow.com TUFLOW Support] and [mailto:sales@tuflow.com TUFLOW Sales] with questions, but keep in mind that we can only offer limited guidance when it comes to the specifics of your chosen cloud provider, and that your company's IT policies may further limit your options.

== Q4: How can I download the simulation results? ==
This depends on your chosen solution.

If you have cloud VMs that have access to your company's internal network, you may be able to copy the results automatically (with a script or batch file) after a simulation completes, and no download would be needed. If you have cloud VMs that you interactively use remotely, you can use whatever tools you would use from any remote machine, like OneDrive, Dropbox, FTP, SSH, to name but a few.

However, all cloud service providers also provide cloud storage, and it may be cheaper and faster to keep unprocessed results in the cloud. Once a run completes, you typically do not want to keep the results on storage that is local to the VM that ran the model (e.g. its C: or D: drive on a Windows computer), unless you plan to use the same VM for post-processing of the results. But you can set up network file shares in the cloud that can be connected to your VM as extra drives or mounts, or you can make use of blob storage like Azure Blob, S3 Buckets, etc. Depending on the cloud service provider, there will be relatively user-friendly tools to access these remotely and download your data later.

For particularly massive datasets, some cloud providers also offer services where they can put the data on physical media and ship them to you. However, keep in mind that this takes substantial time to reserve beforehand and then some time to execute after you complete the work. And the service may not be available for smaller volumes you may need.

Finally, at the risk of stating the obvious: perform the download on a good internet connection. Cloud providers charge a small amount per GB downloaded, and in return they offer very good download speeds for your data. But your internet connection may end up limiting how quickly you get your data to your computer.
== Q5: What are the benefits of running a simulation in the cloud rather than locally? ==
Not all benefits apply in all cases, but consider these:

* You can get access to as many cloud VMs (and GPUs) you need to run as many runs you need in parallel, provided you have sufficient licences and quota with the provider.
* If you only need compute infrequently, it's there in the cloud when you need it and you only pay for it when you use it.
* If your workload suddenly increases (which may be a good thing), you can quickly increase the amount of compute with cloud computing, provided you're set up to do so.
* Most cloud providers offer access to a variety of very capable hardware, that may allow you to run models larger or longer running than you could on your own hardware.
* If you collaborate with others from various locations (wherever they are in the world), having the results in the cloud may be a real benefit.

However, there are some potential downsides to consider as well:

* If you make efficient use of hardware you own, the compute is likely cheaper per model run than it would be compared to cloud computing, especially for on-demand compute.
* Although it's not very complicated to set up a VM for cloud runs and to get up and running, it may be complicated to do so in a way that satisfies your company or client's security policies.
* Similarly, just running some models on an interactively accessible VM may be simple, but developing scripts for automated model running may require time and skills that prevent you from doing so yourself.

== Q6: Do I need to add in any extra commands in my control files? ==
If your model is self-contained and could run from its folder on any computer, perhaps not. However, you may want to change where a VM in the cloud tries to write its results, for example. You can achieve that with extra command in your control files, but also consider the use of TUFLOW override control files, which you can tailor to the cloud VMs you're using, without affecting the control files you use for running or testing locally.

To keep costs of storage and transport manageable, as well as saving on some run time, configure your model to write only the outputs you need. This includes selecting the right variables to output, at the appropriate time intervals. Have a look at our [https://www.youtube.com/watch?v=-CsKKjG7jpQ Output Management Advice] webinar (15 minutes) for more tips on that.

Also look at the command line switches mentioned in the answer to Q2.
== Q7: Do I need a different licence to run models on the cloud? ==
Not necessarily, but there are some things to keep in mind. If your existing licences are on a dongle, they would need to be network licences and the server they are installed on would have to be accessible over the network from the cloud VMs you're looking to run models on. If you have sufficient existing network licences you can use in this manner, including licences for special hardware you'd be using on the cloud (like a GPU), you will not need different licences.

You can also set up a dedicated VM to run a small CodeMeter network licence server in the cloud for software network licences. But keep in mind that licences on such a server cannot be moved elsewhere - they are bound to this specific VM. Access to this licence server would be limited to VMs in the cloud, on the same virtual network as the licence server. Or you'd need to have someone with the appropriate IT skills make the licence server accessible from all locations you need access from.

Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.
== Q8: What can go wrong when running models on the cloud? ==
For starters, almost everything that can go wrong when running models locally, although power failure and loss of network connection is exceedingly rare on the cloud.

Common problems arise from the differences in the computer's environment: software you may have installed that batch files rely on, software required to run TUFLOW (CodeMeter, NVIDIA drivers for GPU), access to networked resources you get inputs from, or write results to, etc.

Also, if you're using Batch services from your cloud provider, once a VM completes its tasks, it may disappear. If something went wrong during the run, you may have very limited access to information about what went wrong, so you want to be careful about logging and where logs are written to.

Similarly, but much simpler: of you run models interactively on a desktop VM, once you turn it off, you will no longer have access to its local storage. And once you remove the VM to save on cost, keep in mind that its attached disk storage will be removed as well, so ensure you have your results in a safe place before that.

Finally, access to licences using Codemeter from the cloud VM can sometimes cause some complications. And access for users to the VM or the data may cause some complications, depending on your IT setup.

None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.
== Q10: If I stop the cloud VM after models are finished, can I still download the results? ==
If the results were written to local storage on the VM (like the default C: or D: drive on a Windows VM), you will only be able to access these when the cloud VM is running. If you stopped it, you could restart it to gain access again. Once you delete the VM, data on those volumes will be deleted as well, and cannot be recovered.

To be able to access results in the cloud even when a VM is stopped, or deleted, copy the results to a network share on the cloud. On the VM, you may be able to mount this storage as a network share, or tools will be available to perform a copy to cloud storage, depending on the cloud provider and operating system you are using.
== Q11: Why is my run on the cloud slower than I expected based on the specs? ==
Although cloud hardware may be faster for some use cases, and certainly a lot more expensive to purchase, it may not be guaranteed to run your TUFLOW model faster. This mostly depends on how modern the NVIDIA hardware architecture is, how many CUDA cores it has available and specific metrics of the hardware like the amount of memory, the clock speed of the memory, the clock speed of the cores, and how the GPU is connected to the rest of the hardware. For a good assessment of whether you should expect better performance, refer to our [[Hardware Benchmarking (2018-03-AA)|Hardware Benchmarking]] pages.

If you're wondering why TUFLOW software doesn't benefit from these supposedly faster and more expensive GPUs, consider that a GPU has many different features, and TUFLOW only makes use of an important subset of these. Also, most TUFLOW models are executed using the single-precision floating-point executable, which is faster than the double-precision executable. Desktop GPUs are highly optimised for single-precision compute, because this is what benefits gaming, and as it happens, TUFLOW runs. Data centre GPUs are more optimised for double-precision compute, but most TUFLOW simulations don't benefit in result quality from using this.

Even when the hardware should be faster according to benchmarks, it's possible that you have some other restrictions. For one, if your cloud environment shares GPUs between many users, the part of the GPU available to your model run may only see a small percentage of the performance it would show with exclusive access to the GPU. This is particularly true in Virtual Desktop Infrastructure (VDI) setups. The way TUFLOW uses the GPU is very different from normal graphics processing, and VDI solutions are often not good for model running.

Another common cause of slowing is writing results directly to network shares that may be accessed over network connections that are orders of magnitude slower than local disk access. In these situations, the recommendation is to write results locally (with minimal overhead) on the cloud VM and then copy the results to other storage in one go, when the run completes. Even if you perform this copy while another run starts, you'll find that running first and copying after is a lot faster than writing directly to the network share. To understand why, imagine writing and sending an email one word at a time, or writing it all in one go. The amount of typing you have to do is roughly the same, if you do it cleverly, but clearly the whole process will take longer, and you can imagine the network having to send far more data back and forth. The difference between writing results to the network one part at a time, instead of all at once is analogous.
== Q12: How can I lower the cost of running simulations on the cloud? ==
The first step would be to select the hardware that's best suited to your needs, at the lowest price, from the most affordable provider.

Secondly, if you get cloud hardware on-demand, you're paying the highest rates for the flexibility this affords. You can also reserve instances of specific hardware types, for periods like a year, or three years (depending on the cloud provider), dramatically lowering the price - but then you will have to pay for the entire period for the reserved instances. If your organisation is large enough, it can be worthwhile to have access to a pool of reserved resources, as long as the business achieves high utilisation over time, so that you only pay on-demand prices when you exceed your reserved instances.

If you do end up using on-demand hardware, ensure you only run it when you're actually using it. By automatically turning off VMs when the work is done and copied to appropriate storage, you can save on compute costs - you're not paying for how much power they use, you're paying for the hours they're on. And keep data on cheap storage like blob storage or online file shares, where you pay only for the size you're using, instead of keeping expensive VMs around that have massive virtual hard drives that you're paying for as long as they exist, empty or not.

Don't download data repeatedly, especially if you need access to it frequently. If you only need access to a small part of the data, it may be worth it to do so remotely. But if you need to process entire files, or multiple users need a copy, it will be more economical to download the data to your network once and use it from there.

You may have heard about 'spot pricing' for VMs. This may be suitable if you're running many small simulations in sequence, and if you're not under strict time pressure to deliver results, but in many cases, it won't be ideal, especially if your model is not set up with restart files that get stored away from the VM. We find that the added complexity rarely outweighs the price difference for the hardware, but the discounts on VMs obtained through spot pricing can be substantial.

If you find that the number of licences you need to scale up model running on the cloud is the main limiting factor for cost, contact our [mailto:sales@tuflow.com TUFLOW Sales] to discuss options for your situation.

Finally, read through these questions, and take the advice given to heart. Optimising your model configuration and making the right choices when running on the cloud can save a lot of run time, and thus cost.
== Q13: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==
As of 2019, TUFLOW offer an [[TUFLOW Cloud Simulation Service|on-demand cloud simulation service]] that may suit your needs if your project is sufficiently urgent or large. As of 2023, you may find third parties providing services on the cloud as well, and TUFLOW may support use of its software in such services.
== Q14: Which machine size / hardware type do you recommend for my model runs? ==
Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.

However, some comments that generally apply:

* As with physical hardware, top speed comes at a premium. If you compare model run times between different VM sizes, you may find that running on the slower machines may work out cheaper for a certain amount of work, than using the faster ones. Of course, you will have to consider project lead time, and time spent on licences as well.
* For most cloud providers, the number of vCPU cores scales together with the type and number of available GPUs. And together with vCPUs, the amount of available RAM and storage scales up as well. As a result, you may end up with a lot of unused resources on some machine types.
* If you're considering purchasing cloud infrastructure for permanent use, keep in mind that Virtual Desktop Infrastructure solutions often share resources like GPUs between many users. You may find that a specific type of hardware works really well in a test setup, where you're the only user on it, but performs really poorly when under load from many users. If you purchase access to a cloud VM directly, you will have it all to yourself, but additional infrastructure on top of the VMs may affect your performance greatly.
* Conversely, when selecting a VM type that provides access to only 'half' of a data centre VM, you don't have to worry about negative performance impact. This type of sharing (that your IT can also achieve in your own data centre with NVIDIA MIG) still ensures that you always get full access to a dedicated part of the GPU and performance should be as expected.

Organisation Cloud Software Execution

2023-12-15T03:40:06Z

Jaap.vandervelde: First set of questions answered, based on list of questions provided by Pavlina via email.

The TUFLOW [https://www.tuflow.com/Download/Licensing/TUFLOW%20Products%20Licence%20Agreement.pdf End User Licence Agreement] was updated in 2018 allowing companies to host their own licences on the cloud. The only restrictions associated with users running TUFLOW simulations on their own company public or private cloud environment are:
<ol>
<li> The licence must be a “Network” type (use of “Local” licences is not permitted on the cloud).
<li> Usage of TUFLOW software on a virtual machine is confined to Authorised Users within the Licensee's Network. This clause means companies cannot on-sell access to TUFLOW licences hosted in the cloud or otherwise (excluding TUFLOW vendor contract arrangements).
</ol>

Configuration of your cloud environment is your own responsibility. There are numerous ways TUFLOW licensing and simulation can be configured in a cloud environment depending on the cloud provider (Microsoft, Google, Amazon, other etc.) and internal company protocols. We recommend engaging a professional with suitable cloud architecture expertise to design your bespoke system. Clients who have already migrated to the cloud have done so in a variety ways:
* Some use a hardware lock (USB) dongle that resides in their office on a physical computer or server. Cloud virtual machines link to the network licence via the IP address of the hardware lock.
* Others use a software lock. Software locks are a digital licence file that is locked to a dedicated host computer, server or virtual machine. When using a software lock please select the host carefully as the software licence will be bound to it. Relocating the licence to a new location will require TUFLOW sales staff to reissue the licence, which incurs a small administration fee.

'''Please Note: Network licence rentals can be used to upscale the available licences on your cloud system when demand requires it.'''
Refer to the [https://www.tuflow.com/Prices.aspx TUFLOW Pricelist] for more information.

This detailed report from the TUFLOW Library discusses some benefits, challenges and solutions relating to cloud computing to help people who are setting up their own system:
[https://downloads.tuflow.com/Licensing/2021_Running_TUFLOW_on_the_Cloud.pdf Running TUFLOW on the Cloud (Whitepaper)] 
[[File:2021_Running_TUFLOW_on_the_Cloud.png]] 
 
= Common Questions Answered (FAQ)=
== Q1: How do I execute a simulation on the cloud? Can I still use batch files? ==
Running a simulation on the cloud can be very similar to running it on any other computer. You can access a VM remotely just like you would any other remote computer, using Remote Desktop, SSH, VNC, an X-Server client, etc. - whatever you are used to and what is set up on the VM. However, that assumes the VM is set up for that type of access and is running when you need to connect to it. If you want to make use of the real benefits of the cloud, like the ability to run on many computers at once, starting them automatically only when needed, doing it through such a process would be very cumbersome. You may want to consider looking at more advanced techniques like [https://azure.microsoft.com/en-au/products/batch Azure Batch], AWS Batch, or [https://cloud.google.com/batch/docs/get-started Google Cloud Batch].

In either case, you will need access to a TUFLOW licence server from VMs running the model. Have a look at "Do I need a different licence to run models on the cloud?" below. And the VMs will always need to have CodeMeter installed, configured to find the licence you plan to use, as well as appropriate drivers for hardware like GPUs.

When running on the cloud, consider that you may not have network access to locations where you would normally store your results. You may need to set up storage in the cloud separate from the VM, but connected to it, to collect your results and still have them available to you once the VM stops running.

If you're using remote access to desktop VMs, you can still use ''batch files'' or scripts like you're used to. If you look into batch services, you will need more involved scripting, and you would typically not use batch files, but split up the work into separate tasks for the cloud platform to schedule on available computers. Keep in mind that this is a substantial and complex task, requiring some development and IT skills. If you plan on this type of cloud use, plan ahead and be ready with a working and tested solution, before you take on a deadline.
== Q2: Do I need a different TUFLOW executable to run models on the cloud? ==
No, you can use the same executable appropriate to the operating system you are on. Keep in mind that running TUFLOW with a licence does require that CodeMeter is installed as well and configured to find the licence. And if you are using a GPU on the cloud, you will need to have the appropriate NVIDIA drivers with CUDA installed, and a GPU licence available.

Although you do use the same executable, it may be advantageous to provide some additional command line options to TUFLOW when you run it on the cloud. Since you typically won't be present and looking at the screen, consider using the `-nc` switch, which prevents user interaction on the console. Also, the familiar `-b` option will prevent the simulation waiting for a key press at the end of the simulation. And finally, given the possible cost of running models at scale, you would do well to test your model with the `-t` switch before sending it to the cloud. In addition to command line options, learn about TUFLOW override files to override configuration that may need to be different on the cloud VM, like the location where TUFLOW should write results.
== Q3: What steps do I need to take to run my model on the cloud? ==
In no particular order:

* Assuming you have chosen a cloud provider you will use, make sure you understand the answers to the previous questions. If some of this is too technical, ensure you go over this with staff with appropriate IT skills and administrative access.
* With regard to the model itself, ensure that it has no references to files on computers that wouldn't be accessible from the cloud VM running the model. Ideally, construct your model configuration so that it can be self-contained within a single folder and would run wherever you put it.
* Ensure you have sufficient TUFLOW licences available and accessible to your cloud VMs to run the number of simulations you plan to run in parallel on the cloud.
* Ensure you have sufficient quota for storage and cloud resources you need to run the number of simulations you plan to run, specifically when using the 'Batch' services mention under Q1.
* Ensure you have the right level of access to make use of the cloud resources you need, and that you're able to use and manage them when you do.
* Ensure that what you're planning on the cloud complies with your company and client's security policies for the work. Think about where the cloud computers are, how data is transferred to and from the cloud, and who has access.
* If you can, pick a region that puts the compute and storage relatively close to your own location, ensuring that your access (or perhaps your clients' access) to them over the internet can achieve good total network speeds.
* Test you model before putting it on the cloud and test your preferred method of running a model on the cloud before scaling it up.
* Make sure your model configuration matches your actual needs before sending it to the cloud. Consider the frequency of writing outputs, whether you need check files, etc.

When in doubt, feel free to contact [mailto:support@tuflow.com TUFLOW Support] and [mailto:sales@tuflow.com TUFLOW Sales] with questions, but keep in mind that we can only offer limited guidance when it comes to the specifics of your chosen cloud provider, and that your company's IT policies may further limit your options.

== Q4: How can I download the simulation results? ==
This depends on your chosen solution.

If you have cloud VMs that have access to your company's internal network, you may be able to copy the results automatically (with a script or batch file) after a simulation completes, and no download would be needed. If you have cloud VMs that you interactively use remotely, you can use whatever tools you would use from any remote machine, like OneDrive, Dropbox, FTP, SSH, to name but a few.

However, all cloud service providers also provide cloud storage, and it may be cheaper and faster to keep unprocessed results in the cloud. Once a run completes, you typically do not want to keep the results on storage that is local to the VM that ran the model (e.g. its C: or D: drive on a Windows computer), unless you plan to use the same VM for post-processing of the results. But you can set up network file shares in the cloud that can be connected to your VM as extra drives or mounts, or you can make use of blob storage like Azure Blob, S3 Buckets, etc. Depending on the cloud service provider, there will be relatively user-friendly tools to access these remotely and download your data later.

For particularly massive datasets, some cloud providers also offer services where they can put the data on physical media and ship them to you. However, keep in mind that this takes substantial time to reserve beforehand and then some time to execute after you complete the work. And the service may not be available for smaller volumes you may need.

Finally, at the risk of stating the obvious: perform the download on a good internet connection. Cloud providers charge a small amount per GB downloaded, and in return they offer very good download speeds for your data. But your internet connection may end up limiting how quickly you get your data to your computer.
== Q5: What are the benefits of running a simulation in the cloud rather than locally? ==
Not all benefits apply in all cases, but consider these:

* You can get access to as many cloud VMs (and GPUs) you need to run as many runs you need in parallel, provided you have sufficient licences and quota with the provider.
* If you only need compute infrequently, it's there in the cloud when you need it and you only pay for it when you use it.
* If your workload suddenly increases (which may be a good thing), you can quickly increase the amount of compute with cloud computing, provided you're set up to do so.
* Most cloud providers offer access to a variety of very capable hardware, that may allow you to run models larger or longer running than you could on your own hardware.
* If you collaborate with others from various locations (wherever they are in the world), having the results in the cloud may be a real benefit.

However, there are some potential downsides to consider as well:

* If you make efficient use of hardware you own, the compute is likely cheaper per model run than it would be compared to cloud computing, especially for on-demand compute.
* Although it's not very complicated to set up a VM for cloud runs and to get up and running, it may be complicated to do so in a way that satisfies your company or client's security policies.
* Similarly, just running some models on an interactively accessible VM may be simple, but developing scripts for automated model running may require time and skills that prevent you from doing so yourself.

== Q6: Do I need to add in any extra commands in my control files? ==
If your model is self-contained and could run from its folder on any computer, perhaps not. However, you may want to change where a VM in the cloud tries to write its results, for example. You can achieve that with extra command in your control files, but also consider the use of TUFLOW override control files, which you can tailor to the cloud VMs you're using, without affecting the control files you use for running or testing locally.

To keep costs of storage and transport manageable, as well as saving on some run time, configure your model to write only the outputs you need. This includes selecting the right variables to output, at the appropriate time intervals. Have a look at our [https://www.youtube.com/watch?v=-CsKKjG7jpQ Output Management Advice] webinar (15 minutes) for more tips on that.

Also look at the command line switches mentioned in the answer to Q2.
== Q7: Do I need a different licence to run models on the cloud? ==
Not necessarily, but there are some things to keep in mind. If your existing licences are on a dongle, they would need to be network licences and the server they are installed on would have to be accessible over the network from the cloud VMs you're looking to run models on. If you have sufficient existing network licences you can use in this manner, including licences for special hardware you'd be using on the cloud (like a GPU), you will not need different licences.

You can also set up a dedicated VM to run a small CodeMeter network licence server in the cloud for software network licences. But keep in mind that licences on such a server cannot be moved elsewhere - they are bound to this specific VM. Access to this licence server would be limited to VMs in the cloud, on the same virtual network as the licence server. Or you'd need to have someone with the appropriate IT skills make the licence server accessible from all locations you need access from.

Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.
== Q8: What can go wrong when running models on the cloud? ==
For starters, almost everything that can go wrong when running models locally, although power failure and loss of network connection is exceedingly rare on the cloud.

Common problems arise from the differences in the computer's environment: software you may have installed that batch files rely on, software required to run TUFLOW (CodeMeter, NVIDIA drivers for GPU), access to networked resources you get inputs from, or write results to, etc.

Also, if you're using Batch services from your cloud provider, once a VM completes its tasks, it may disappear. If something went wrong during the run, you may have very limited access to information about what went wrong, so you want to be careful about logging and where logs are written to.

Similarly, but much simpler: of you run models interactively on a desktop VM, once you turn it off, you will no longer have access to its local storage. And once you remove the VM to save on cost, keep in mind that its attached disk storage will be removed as well, so ensure you have your results in a safe place before that.

Finally, access to licences using Codemeter from the cloud VM can sometimes cause some complications. And access for users to the VM or the data may cause some complications, depending on your IT setup.

None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.
== Q10: If I stop the cloud VM after models are finished, can I still download the results? ==
If the results were written to local storage on the VM (like the default C: or D: drive on a Windows VM), you will only be able to access these when the cloud VM is running. If you stopped it, you could restart it to gain access again. Once you delete the VM, data on those volumes will be deleted as well, and cannot be recovered.

To be able to access results in the cloud even when a VM is stopped, or deleted, copy the results to a network share on the cloud. On the VM, you may be able to mount this storage as a network share, or tools will be available to perform a copy to cloud storage, depending on the cloud provider and operating system you are using.
== Q11: Why is my run on the cloud slower than I expected based on the specs? ==
Although cloud hardware may be faster for some use cases, and certainly a lot more expensive to purchase, it may not be guaranteed to run your TUFLOW model faster. This mostly depends on how modern the NVIDIA hardware architecture is, how many CUDA cores it has available and specific metrics of the hardware like the amount of memory, the clock speed of the memory, the clock speed of the cores, and how the GPU is connected to the rest of the hardware. For a good assessment of whether you should expect better performance, refer to our [[Hardware Benchmarking (2018-03-AA)|Hardware Benchmarking]] pages.

If you're wondering why TUFLOW software doesn't benefit from these supposedly faster and more expensive GPUs, consider that a GPU has many different features, and TUFLOW only makes use of an important subset of these. Also, most TUFLOW models are executed using the single-precision floating-point executable, which is faster than the double-precision executable. Desktop GPUs are highly optimised for single-precision compute, because this is what benefits gaming, and as it happens, TUFLOW runs. Data centre GPUs are more optimised for double-precision compute, but most TUFLOW simulations don't benefit in result quality from using this.

Even when the hardware should be faster according to benchmarks, it's possible that you have some other restrictions. For one, if your cloud environment shares GPUs between many users, the part of the GPU available to your model run may only see a small percentage of the performance it would show with exclusive access to the GPU. This is particularly true in Virtual Desktop Infrastructure (VDI) setups. The way TUFLOW uses the GPU is very different from normal graphics processing, and VDI solutions are often not good for model running.

Another common cause of slowing is writing results directly to network shares that may be accessed over network connections that are orders of magnitude slower than local disk access. In these situations, the recommendation is to write results locally (with minimal overhead) on the cloud VM and then copy the results to other storage in one go, when the run completes. Even if you perform this copy while another run starts, you'll find that running first and copying after is a lot faster than writing directly to the network share. To understand why, imagine writing and sending an email one word at a time, or writing it all in one go. The amount of typing you have to do is roughly the same, if you do it cleverly, but clearly the whole process will take longer, and you can imagine the network having to send far more data back and forth. The difference between writing results to the network one part at a time, instead of all at once is analogous.
== Q12: How can I lower the cost of running simulations on the cloud? ==
The first step would be to select the hardware that's best suited to your needs, at the lowest price, from the most affordable provider.

Secondly, if you get cloud hardware on-demand, you're paying the highest rates for the flexibility this affords. You can also reserve instances of specific hardware types, for periods like a year, or three years (depending on the cloud provider), dramatically lowering the price - but then you will have to pay for the entire period for the reserved instances. If your organisation is large enough, it can be worthwhile to have access to a pool of reserved resources, as long as the business achieves high utilisation over time, so that you only pay on-demand prices when you exceed your reserved instances.

If you do end up using on-demand hardware, ensure you only run it when you're actually using it. By automatically turning off VMs when the work is done and copied to appropriate storage, you can save on compute costs - you're not paying for how much power they use, you're paying for the hours they're on. And keep data on cheap storage like blob storage or online file shares, where you pay only for the size you're using, instead of keeping expensive VMs around that have massive virtual hard drives that you're paying for as long as they exist, empty or not.

Don't download data repeatedly, especially if you need access to it frequently. If you only need access to a small part of the data, it may be worth it to do so remotely. But if you need to process entire files, or multiple users need a copy, it will be more economical to download the data to your network once and use it from there.

You may have heard about 'spot pricing' for VMs. This may be suitable if you're running many small simulations in sequence, and if you're not under strict time pressure to deliver results, but in many cases, it won't be ideal, especially if your model is not set up with restart files that get stored away from the VM. We find that the added complexity rarely outweighs the price difference for the hardware, but the discounts on VMs obtained through spot pricing can be substantial.

If you find that the number of licences you need to scale up model running on the cloud is the main limiting factor for cost, contact our [mailto:sales@tuflow.com TUFLOW Sales] to discuss options for your situation.

Finally, read through these questions, and take the advice given to heart. Optimising your model configuration and making the right choices when running on the cloud can save a lot of run time, and thus cost.
== Q13: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==
As of 2019, TUFLOW offer an [[TUFLOW Cloud Simulation Service|on-demand cloud simulation service]] that may suit your needs if your project is sufficiently urgent or large. As of 2023, you may find third parties providing services on the cloud as well, and TUFLOW may support use of its software in such services.

HPC Running and Converting Models

2023-12-11T01:54:07Z

Jaap.vandervelde: Brought partially correct command line option description in line with tcf command description (which was correct)

= Introduction =
This page contains information about converting an existing TUFLOW Classic or GPU (pre 2017 HPC release) model to a format that can be run using the TUFLOW HPC engine. This page provides a quick summary for experienced TUFLOW users to use as a reference point for updating their models. It is recommended that less experienced TUFLOW users refer to our [[Tutorial_Introduction |TUFLOW Tutorial Modules]] for greater support and guidance on creating a HPC model. 

To convert an existing TUFLOW Classic or GPU Model to run on HPC, an update to the TUFLOW Control File (TCF) is needed. Some features from TUFLOW Classic that are not currently supported in HPC, may prevent the HPC model running successfully. To find out more about unsupported features in HPC be sure to review the [https://tuflow.com/Download/TUFLOW/Releases/2017-09/TUFLOW%20Release%20Notes.2017-09.pdf TUFLOW 2017-09 Release Notes] or the [[HPC Features | HPC Features Wiki Page]]. 

= Converting TUFLOW Classic to HPC (TCF Updates) =
To run an existing TUFLOW Classic simulation with the new HPC engine, the following lines of text need to be added to the TUFLOW Control File (TCF). 
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> <tt> !This command specifies that you want to run TUFLOW using the HPC solution scheme or engine.</tt> 
The following command is also required to run the model using GPU hardware: 
<tt>Hardware </tt> <tt>==</tt><tt> GPU </tt> <tt> !CPU is default. The hardware command instructs TUFLOW HPC to run using GPU hardware. This is typically orders of magnitude faster than on CPU.</tt> 
These two commands are all that's needed to run convert the TUFLOW Classic model to HPC and run using GPU hardware. There are however more commands provided below that give the modeller greater control over the Hardware that HPC uses. 

= Running HPC on Multiple CPU Threads =
As mentioned in the [[HPC_Introduction | HPC Introduction]] page, HPC can be parallelised to run across multiple CPU processors when run on CPU (i.e. not GPU). The following command allows the modeller to dictate the number of core processors to run TUFLOW HPC across. 
<tt>CPU Threads </tt> <tt>==</tt><tt> 8 </tt> <tt> !Default is 4. This instructs TUFLOW to search for and run the model across four different core processors. </tt> 
If the number of processors or TUFLOW licences found by TUFLOW are less than the specified value, then TUFLOW will utilise the maximum number of core processors available within the licence and hardware limitations. 
Alternatively, the number of CPU threads can be specified in the batch file / command line by using the -nt<number of threads> argument. If both control file and command line are used to specify number of threads, the command line option will prevail.

= Running HPC on Multiple GPU Devices =
Much like HPC can be run across multiple CPU processors, HPC can be run across multiple GPU cards. Models can also be instructed to run on a specific GPU card. 
If a machine only has a single GPU card, the GPU Device ID should be 0, this is a default. If a second GPU card was added, the Device ID would be 1 and so on. The GPU IDs can be checked by reviewing the machines ''Device Manager''. 
The most common is to specify the GPU card ID in the batch file / command line by using the -pu<id> argument. 
Example below will run single simulation across the first and second GPU card (ID 0 and 1).
<pre>"TUFLOW_iSP_w64.exe" -pu0 -pu1 "M01_5m_001.tcf"</pre>
Example below will run single simulation on the fourth GPU card (ID 3).
<pre>"TUFLOW_iSP_w64.exe" -pu3 "M01_5m_001.tcf"</pre>

Alternatively, the following TCF command can be used to set the number of GPU devices and which devices to use. 
<tt>GPU Device IDs </tt> <tt>==</tt><tt> 0, 1 </tt> <tt> !This command instructs TUFLOW to run the model on GPU Device 0 and GPU Device 1.</tt> 
If both control file and command line are used to specify devices, the command line option will prevail.

= Converting TUFLOW GPU to HPC (TCF Updates) =
When converting a TUFLOW GPU model across to HPC, first confirm that all features in the GPU model are available in HPC by referring to the [https://tuflow.com/Download/TUFLOW/Releases/2017-09/TUFLOW%20Release%20Notes.2017-09.pdf TUFLOW 2017-09 Release Notes]. 
Delete the following command from the *.tcf file and insert the commands specified above, for converting a TUFLOW Classic model to HPC. 
<s><tt>GPU Solver </tt> <tt>==</tt><tt> ON </tt></s> 

= HPC Scenarios and Updating the Batch File =
Modellers may want to change the hardware that HPC is run on throughout the course of a project. For example, if your company own more CPU than GPU licences it may be beneficial to run the model using CPU hardware during the initial model build phase so your colleagues have access to the higher speed GPU licences for production runs on other projects that are running in parallel. If this is the case, it may be easier to setup a Scenario Logic statement in the TUFLOW Control File (TCF), that allows the modeller to change the hardware being used with a simple switch in the batch file used to run the model.

To setup a scenario for varying hardware options, the following commands can be used in the TCF file:
<tt>Solution Scheme </tt> <tt>==</tt><tt> HPC </tt> 
<tt>Hardware </tt> <tt>==</tt> <tt> <<~s1~>> </tt> <tt> !The scenario will either be "CPU" or "GPU"</tt> 

This basic scenario logic can be configured further within the TCF as shown below: 

<tt>If Scenario </tt> <tt>==</tt> <tt> CPU </tt> 
:: <tt>CPU Threads </tt> <tt>==</tt> <tt> 8 </tt> 
<tt>Else If Scenario </tt> <tt>==</tt> <tt> GPU </tt> 
:: <tt>GPU Device IDs</tt> <tt>==</tt> <tt> 0, 1 </tt> 
<tt>End If </tt> 

If using the above Scenario Logic, the modeller must include a scenario call in the batch file. 
<tt>-s1 <Hardware Type> </tt> 
If you are unfamiliar with using Scenario Logic, please refer to [[Tutorial_M08 |Tutorial Module 08]]. 

Other useful batch file switches include: 
<tt>-nt <number_of_threads> </tt>: This switch is used to set the number of CPU threads used for CPU mode simulations. 
<tt>-pu <GPU Device IDs> </tt>: This switch is used to set the number of GPU devices and which devices to use. 
An example of how this would be implemented into a simple batch file for CPU and GPU are shown below. 

'''CPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 CPU -nt8 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on CPU using 8 CPU threads. 

'''GPU''' 
<tt>TUFLOW_iSP_w64.exe -s1 GPU -pu0 -pu1 FMA_T2_~s1~_001.tcf</tt> 
This example will run TUFLOW HPC on GPU using 2 GPU cards. 
 
 
{{Tips Navigation
|uplink=[[ HPC_Modelling_Guidance | Back to HPC Modelling Guidance]]
}}

Installing Wibu CodeMeter Linux

2022-02-01T23:07:02Z

Jaap.vandervelde: Apparently managed to make the same mistake three times in a row - apologies to anyone confused. 22350, 22352 and 22353 are definitely correct, more in CodeMeter documentation.

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at [https://www.wibu.com/support/user/user-software.html www.wibu.com/support/user/user-software.html].

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. If your hardware supports 64-bit software (which is likely for modern systems), using that version is recommended. From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat, using `yum`, you can install the CodeMeter Runtime with <pre>sudo yum localinstall codemeter.rpm</pre>

On Debian, using `dpkg` and `apt-get`, you can install the CodeMeter Runtime with <pre>sudo dpkg -i codemeter.deb</pre> If that fails due to missing dependencies, you can instead attempt <pre>sudo apt-get -f codemeter.deb</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, you can use: <pre>sudo /etc/init.d/codemeter restart</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22350/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

Similarly, if you want users to be able to access the web admin interface for code meter on the server, you would need to ensure the firewall allows request on port 22352 (for http) and/or 22353 (for https). However, access to the web admin interface from other machines is not required for obtaining a license and in typical configurations, you would be able to access the web admin interface on the host itself (localhost) without additional firewall rules.

Installing Wibu CodeMeter Linux

2022-02-01T07:31:14Z

Jaap.vandervelde:

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at [https://www.wibu.com/support/user/user-software.html www.wibu.com/support/user/user-software.html].

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. If your hardware supports 64-bit software (which is likely for modern systems), using that version is recommended. From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat, using `yum`, you can install the CodeMeter Runtime with <pre>sudo yum localinstall codemeter.rpm</pre>

On Debian, using `dpkg` and `apt-get`, you can install the CodeMeter Runtime with <pre>sudo dpkg -i codemeter.deb</pre> If that fails due to missing dependencies, you can instead attempt <pre>sudo apt-get -f codemeter.deb</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, you can use: <pre>sudo /etc/init.d/codemeter restart</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22350/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

Similarly, if you want users to be able to access the web admin interface for code meter on the server, you would need to ensure the firewall allows request on port 22352 (for http) and/or 223533 (for https). However, access to the web admin interface from other machines is not required for obtaining a license and in typical configurations, you would be able to access the web admin interface on the host itself (localhost) without additional firewall rules.

Installing Wibu CodeMeter Linux

2022-02-01T01:40:39Z

Jaap.vandervelde: changed 'web interface' to 'web admin interface'

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at [https://www.wibu.com/support/user/user-software.html www.wibu.com/support/user/user-software.html].

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. If your hardware supports 64-bit software (which is likely for modern systems), using that version is recommended. From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat, using `yum`, you can install the CodeMeter Runtime with <pre>sudo yum localinstall codemeter.rpm</pre>

On Debian, using `dpkg` and `apt-get`, you can install the CodeMeter Runtime with <pre>sudo dpkg -i codemeter.deb</pre> If that fails due to missing dependencies, you can instead attempt <pre>sudo apt-get -f codemeter.deb</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, you can use: <pre>sudo /etc/init.d/codemeter restart</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22350/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

Similarly, if you want users to be able to access the web admin interface for code meter on the server, you would need to ensure the firewall allows request on port 22352 (for http) and/or 223532 (for https). However, access to the web admin interface from other machines is not required for obtaining a license and in typical configurations, you would be able to access the web admin interface on the host itself (localhost) without additional firewall rules.

Installing Wibu CodeMeter Linux

2022-02-01T01:39:08Z

Jaap.vandervelde: updated port number and added remark about http / https access to web interface

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at [https://www.wibu.com/support/user/user-software.html www.wibu.com/support/user/user-software.html].

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. If your hardware supports 64-bit software (which is likely for modern systems), using that version is recommended. From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat, using `yum`, you can install the CodeMeter Runtime with <pre>sudo yum localinstall codemeter.rpm</pre>

On Debian, using `dpkg` and `apt-get`, you can install the CodeMeter Runtime with <pre>sudo dpkg -i codemeter.deb</pre> If that fails due to missing dependencies, you can instead attempt <pre>sudo apt-get -f codemeter.deb</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, you can use: <pre>sudo /etc/init.d/codemeter restart</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22350/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

Similarly, if you want users to be able to access the web interface for code meter on the server, you would need to ensure the firewall allows request on port 22352 (for http) and/or 223532 (for https). However, access to the web interface from other machines is not required for obtaining a license and in typical configurations, you would be able to access the web interface on the host itself (localhost) without additional firewall rules.

TUFLOW crashing

2021-02-15T06:19:11Z

Jaap.vandervelde: Some rewording around crashes

<tt>'''This Page is under construction''' </tt>

=Introduction=
From time to time TUFLOW simulations can crash. There are multiple reasons why it could happen. This page can be used as a guide to find and rectify the cause of the crash. 
 

=Troubleshooting Tips=
* Use the latest TUFLOW release available at the [https://www.tuflow.com/downloads/ TUFLOW website].
* If using GPU, update the graphics card driver to the latest version from the [https://www.nvidia.com/Download/index.aspx Nvidia website].
* Restart the modelling machine.
* Check the end of .tlf file for an error message.
* Test running the model on a different machine.
* Save all outputs (checks, results and logs) to a local drive and use TUFLOW executable saved on a local drive to determine if network is causing the issue.
* Monitor if the issue is happening to a single model only or every model, at specific time during the simulation or randomly.
 

=TUFLOW simulation DOS window only flicks and disappears=
Problem might be in the filepath of the TUFLOW executable in the batch file. 
'''Suggestion''':
* Check that the executable filepath exists.
* TUFLOW doesn't currently support UNC paths. The folder with the executable has to be opened with a mapped drive. Type "net use <drive>: \\server_name\share_name" in the command line to map desired drive.
 

=TCF does not exist=
The .tcf name and filepath might be incorrect or unsupported UNC paths were used. 
'''Suggestions:'''
* Check the name of the .tcf file and filepath (if used) is correct.
* TUFLOW doesn't currently support UNC paths. The folder with the model has to be opened with a mapped drive. Type "net use <drive>: \\server_name\share_name" in the command line to map desired drive.
 

=TUFLOW crashes during model initialisation=
Crash at the start of the model might be connected to an erroneous input data or an error in the control files. It might be captured as standard TUFLOW error or as a Fortran compiler error leaving messages only in the console window. 
'''Suggestions:'''
* Insert "pause" at the end of the batch file to keep the console window open. The control file/GIS layer written just above the error should be the cause of the issue.
* Let the console window be written to a text file, e.g. “TUFLOW.exe my_model.tcf > dump.txt”. This will redirect console output massages as well as the standard error stream to the “dump.log” file, and likely it will record more error information than the usual TUFLOW log file.
If multiple large models are initialising at the same time, this could cause a memory overload and stop the simulations. 
'''Suggestions:'''
* Display "Peak working set (memory)" in the Task Manager to confirm memory overload, it is not displayed by default.
* Insert "timeout xxx" in the batch file between the runs to allow the models to initialise separately, where xxx is a number of seconds to wait for the next run to start. 
If there is no clear indication of what the cause might be, send a snapshot of the console window and .tlf to support@tuflow.com. 
 

=TUFLOW crashes randomly at any time during the simulation=
This can happen when TUFLOW is writing outputs to a network drive and/or model uses TUFLOW executable located on a network drive and the computer loses connection to the network. There could be no message box when this happens or a window stating that TUFLOW.exe has stopped working and nothing error related will be written to the .tlf file. If multiple models were running simultaneously, all unfinished models would crash. This applies to Windows 10, 8, 7 operating system. With Windows XP, the simulation would only pause and restart itself when the access to the network drive is back on. The difference in the behaviour is unfortunately based on the operating system and as far as we are aware we are unable to do anything within the TUFLOW code to handle this situation. 
'''Suggestions''':
* Use TUFLOW executable saved on a local drive.
* Set a local drive as the output drive for all checks, results and logs. This can be done using <tt>Output Drive</tt> command in the .tcf. All outputs can be copied back to the network drive at the simulation end if required. Robocopy can be added to the end of the .bat file, example below. 

If the issue persist after using all the suggestions, contact support@tuflow.com, attaching the .tlf file and snapshot of the console window. 

<pre>@echo off

set TUFLOWEXE_iSP=O:\TUFLOW\Releases\2020-01\2020-10-AA\TUFLOW_iSP_w64.exe
set RUN_iSP=start "TUFLOW" /wait "%TUFLOWEXE_iSP%" -b

set A=5m 2.5m
set B=EXG DEV
set source_results=D:\TUFLOW\results
set source_log=D:\TUFLOW\runs
set destination_results=O:\TUFLOW\support\results
set destination_log=O:\TUFLOW\support\runs

FOR %%a in (%A%) do (
FOR %%b in (%B%) do (
:: Run model
echo Running Cell Size %%a Model Scenario %%b
%RUN_iSP% -s1 %%a -s2 %%b M10_~s1~_~s2~_003.tcf

:: Move results folder to different location
robocopy "%source_results%" "%destination_results%" /e /move

:: Move log folder to different location
robocopy "%source_log%" "%destination_log%" /e /move
timeout 5
)
)
pause</pre>

=TUFLOW is crashing at the same/similar time of the day/week=
Something might be preventing the simulation from writing to network drive such as scheduled backup, updates, restart, deduplication or other scheduled processes. TUFLOW is not releasing the licence at the end of the simulation, rather CodeMeter system is determining that the TUFLOW application is no longer running and is therefore releasing the licence - this would show as “Handle xxx automatically released. The application is no longer available.” in the cmDust file. 
'''Suggestions:'''
* Ensure storage locations that results are written to have ample free space. Depending on your infrastructure, reported free space may not be accurate, or performance of storage may substantially degrade as it nears being full.
* Check with IT whether such processes are occurring and if reasonable limits/preferences/priorities can be set to reduce (disk/network) resource use, to allow other processes to run in parallel.
* Run models locally if it is known the runs will coincide with such processes. More information on running models locally [[TUFLOW_crashing#TUFLOW_crashes_randomly_at_any_time_during_the_simulation | here]].
 

=TUFLOW crashes at the end of the simulation before writing out maximum results=
The output drive might not have enough free space to write out the full results. If multiple TUFLOW simulations run in parallel, the free space might be filling up faster than expected. There can also be other processes filling up the drive, e.g. other software, backups, other users copying data. The target drive should never be planned to be filled to the brim, as performance will suffer for all processes. 
'''Suggestions:'''
* Make sure there is enough free space on the output drive.
If the output drive does have more than enough space, insert "pause" at the end of the batch file to keep the console window open and send a snapshot of this window and .tlf to support@tuflow.com. 
 

=TUFLOW can't find a valid licence=
Confirmation that licence is the issue can be mostly found in the .tlf.

==Unmaintained dongle==
Once a year (usually after mid-year) a new TUFLOW release will need the licence to be updated. This will show in the .tlf file as "Unmaintained since <year>". Follow [[WIBU_Licence_Update_Request | WIBU Licence Update Request]] to get the licence updated.

==Running very old TUFLOW releases==
When using an old legacy model with the original TUFLOW release there might be an error "Could not find standalone or network dongle server". Such version of TUFLOW can only run with the old blue softlok licence dongle. If only the metal Wibu dongle is available, DB version of the same year release can be used. We do have some of the old dongles still in possession and can rent it out if required. 
More information on TUFLOW licence dongles and which releases are affected: [[TUFLOW_Licensing | TUFLOW Licensing]]

==No TUFLOW licence settings files found==
Some users might mistake this sentence in the .tlf file as there is an issue with the licence. The real cause of the crash would be noted in the last couple of lines of the .tlf. The "No TUFLOW licence settings files found" sentence is followed by "Default settings applied" and the default settings are listed on the next three lines, e.g. WIBU Retry Time, WIBU Retry Count, WIBU Dongles Only. Only if these settings are required to be different, the licence control file (.lcf) would be created.

==Technical licence issues==
[[Wibu_Dongles#Troubleshooting | Wibu Dongles Troubleshooting]]

Wibu Dongles

2020-06-15T04:16:06Z

Jaap.vandervelde: Added a reference to a (new) Linux installation page

=Introduction=
This page contains a brief introduction to the Wibu dongles.
 
 
=Installation=
==Installing CodeMeter RunTime Kit==
The first step in using the Wibu licence is to install the CodeMeter Runtime Kit. This needs to be installed for any computers that will be running TUFLOW (from either local or network licence) as well as for the network licence server. 
If you are installing on a Linux computer from the command line, refer to [[Installing_Wibu_CodeMeter_Linux|Installing Wibu CodeMeter Linux]] 
The latest version can be downloaded from CodeMeter site: 
[https://www.wibu.com/support/user/downloads-user-software.html https://www.wibu.com/support/user/downloads-user-software.html]
 
The correct file to download is the '''CodeMeter Runtime Kit for Windows''' 
[[File:CodeMeter RuntimeKit Download.jpg|400px]]
 
 
Once installed the configuration depends on if the TUFLOW licence is a Local or Network licence.
* If this is the first time the licence has been used, or your existing licence has expired. You will need to update your licence file. Please progress to the [[#Request_a_licence_update| Request a licence update]] section
* If there is already an active licence associated with the dongle:
:* For a local licence, the dongle can now be inserted into the machine and TUFLOW simulations can be started.
:* For a network licence, continue to the [[#Configuring_Network_Server | configure network server]] and [[#Configuring_Access_to_Network Licence | configure network access]] sections below.

===Silent Install===
It is possible to do a silent install of the CodeMeter Runtime kit. CodeMeter support staff have advised that this can be done with the following parameters: 
<tt>CodeMeterRuntime.exe /ComponentArgs "*":"/qn"</tt>

==Configuring Network Server==
If the TUFLOW licence is a network licence, the computer hosting the dongle will need to be configured as a TUFLOW server. This is required even if the simulations are to be performed on the server. Instructions for configuring the network licence are detailed in the following page: 
*[[WIBU_Configure_Network_Server_2016| WIBU Configure Network Server - Post 2016 Codemeter (recommended)]]
*[[WIBU_Configure_Network_Server | WIBU Configure Network Server - Pre 2016 Codemeter]]

==Configuring Access to Network Licence==
To access TUFLOW licences on a remote network server, the CodeMeter runtime kit needs to be installed on the client machine. Once installed, CodeMeter needs to be configured to use the network licence.
Instructions for configuring the network licence are detailed in the following page: 
*[[WIBU_Configure_Network_Client_2016| WIBU Configure Network Client - Post 2016 Codemeter (recommended)]]
*[[WIBU_Configure_Network_Client | WIBU Configure Network Client - Pre 2016 Codemeter]]
 

=Updating=
There are a number of reasons that the Wibu licence may need to be updated, for example:
* To add additional modules
* To update to new support year
* To add rental licences
For each change to the dongle, it will be necessary to provide a licence update request file to the TUFLOW staff. 
The procedure is the same for local and network licences, the request will need to be generated from the computer which has the dongle plugged in.
==Request a licence update==
The instructions for creating a licence request differ slightly depending whether the dongle has not previously been coded for TUFLOW simulations or if the dongle has not been provided by BMT. 
'''Hardware Licence (USB)''' 
* Unless specified otherwise by the TUFLOW staff, this option is the correct one to chose (please click the link to the right): [[WIBU_Licence_Update_Request | Wibu licence update request (normal)]]
* If you have been provided with a blank dongle or are using a non BMT dongle the TUFLOW producer code needs to be added when requesting the licence update: [[WIBU_Licence_Update_Request_Uncoded | Wibu licence update request (uncoded or blank dongle)]] 
'''Software Licence (File)''' 
* If you would like a software licence instead of a hardware licence: [[WIBU_Software_Licence_Update_Request | Wibu software licence update request]]
After creating the licence update request, please email the created file ('''.WibuCmRaC''') to sales@tuflow.com.

==Import a licence update==
Once a licence update has been created, an update file will be provide to you via email. This update file will have the extension '''.WibuCmRaU'''. To import the file please follow the steps below, the same method is used for network and local licences.
[[WIBU_Licence_Update_Import | Importing a Wibu licence update]] 
When an update is applied, this modifies the content of the dongle, it does not need to be applied on each computer that will be used for TUFLOW modelling!
 
 
=Troubleshooting=
==Dongle Not Working Correctly==
If the drivers have been installed, the colour of the CodeMeter icon in the taskbar indicates if a dongle is being detected correctly. 
[[File:CM CM Stick Grey.jpg|20px]] --- Grey, No CM stick detected. 
[[File:CM CM Stick Green.jpg|20px]] --- Green, CM stick detected. 
 
A range of other colors are also available but not frequently used: 
[[File:CM CM Stick Yellow.jpg|20px]] --- Yellow, CM stick enabled until unplugged (password protected). 
[[File:CM CM Stick Red.jpg|20px]] --- Red, CM stick disabled (password protected). 
[[File:CM CM Stick Blue.jpg|20px]] --- Blue, Multiple CM sticks. 
 
If the CodeMeter icon reamins grey (not detected) when the dongle is inserted, please follow the steps below: 
[[WIBU_Dongle_Not_Detected | WIBU Dongle Not Detected]]
 
If the dongle is correctly detected (the icon changes colour to green), but you are unable to run a TUFLOW simulation, please follow the steps below: 
[[WIBU_Dongle_Not_Running | WIBU Dongle Not Running TUFLOW]]
 
If you are having trouble accessing a network dongle from a remote computer, please follow the steps below: 
[[WIBU_Network_Dongle_Connectivity | WIBU Network Dongle Issues]]
 
 
=Diagnostics=
==cmDust==
When the CodeMeter runtime kit is installed a diagnostics utility call '''cmDust''' is also installed. Instructions for creating a diagnostics file can be found on [[WIBU_create_cmDust | create CM Dust diagnostics file]] page.

==Enabling Logging==
Codemeter allows you to write extended log files to you local drive. To setup these features please follow the instruction on our [[Codemeter_Enable_Logging | Enable Codemeter Logging]] page.

== Enabling Network Server License Monitoring==
Codemeter allows you to conduct real-time licence network monitoring. To setup these features please see our [[Network_Server_License_Monitoring | Network License Monitoring]] page

Installing Wibu CodeMeter Linux

2020-06-15T04:13:12Z

Jaap.vandervelde: Page created with basic installation instructions for Red Hat and Debian variants.

This article provide a basic set of instructions to install the Wibu CodeMeter Runtime on a Linux host through the command line interface (CLI). For more information about using Wibu dongles or software licenses, refer to [[Wibu_Dongles|Wibu Dongles]].

The Linux commands used on this wiki should work on most modern Linux distributions, but were tested on CentOS and Debian. Note that these instructions are provided as a courtesy to users new to Linux, please ensure you understand what the commands mean before you run them and be aware of the [[Tuflow:General_disclaimer|general disclaimer]].

==Getting the CodeMeter Runtime==

The appropriate version of the CodeMeter Runtime can be obtained from the Wibu website at [https://www.wibu.com/support/user/user-software.html www.wibu.com/support/user/user-software.html].

If you are using Debian, Ubuntu, Mint or another Linux distribution in the Debian family of distributions, you should obtain a copy of the `.deb` installer for your hardware. If you are using Red Hat (RHEL), Fedora, CentOS or another Linux distribution in the Red Hat family of distributions, you should obtain a copy of the `.rpm` installer for your hardware. If your hardware supports 64-bit software (which is likely for modern systems), using that version is recommended. From here on, we'll refer to 'Debian' or 'Red Hat' to mean any distribution in that family.

Depending on your level of access to the machine running Linux and whether or not it is running a graphical user interface, you may have some trouble getting the file onto your machine. You can download the file directly from the command line with: <pre>wget -O codemeter.rpm <direct link></pre> where "<direct link>" is the 'direct link' provided on the Wibu download page for the version you are downloading.

The download page also provides an MD5 checksum. You can run <pre>md5sum codemeter.rpm</pre> and verify that the file you downloaded was downloaded correctly by comparing this checksum.

If your Linux distribution does not provide `wget`, you can obtain a copy on Debian with `sudo apt-get install wget` and on Red Hat with `sudo yum install wget`.

==Installing the CodeMeter Runtime==

On Red Hat, using `yum`, you can install the CodeMeter Runtime with <pre>sudo yum localinstall codemeter.rpm</pre>

On Debian, using `dpkg` and `apt-get`, you can install the CodeMeter Runtime with <pre>sudo dpkg -i codemeter.deb</pre> If that fails due to missing dependencies, you can instead attempt <pre>sudo apt-get -f codemeter.deb</pre>

Once these commands complete (on either Debian or Red Hat), you can start, stop and restart the services with `systemctl`: <pre>sudo systemctl restart codemeter.service</pre>

Alternatively, if `systemctl` is not available to you, you can use: <pre>sudo /etc/init.d/codemeter restart</pre>

==Configuring the CodeMeter Runtime==

Refer to the CodeMeter manual for instructions on configuring CodeMeter.

However, if you are installing CodeMeter as a client for network licenses, the following is an example of a section you can add to the `/etc/wibu/CodeMeter/Server.ini`: <pre>[ServerSearchList]
UseBroadcast=1

[ServerSearchList\Server1]
Address=<ip number of your license host></pre>
You can add multiple `ServerSearchList\Server<n>` sections, one for each license host you have, with the IP address of the license host. Once you update and save the configuration file, restart the CodeMeter service and your licenses from the network server should then be available locally.

If you are setting up a license host, which you wish to access from another machine, you will need to install the CodeMeter Runtime on that machine as well and you need to ensure the firewall allows requests to the license host on port 22350.

On Red Hat, you can achieve this with:<pre>sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-port=22352/tcp --permanent
sudo firewall-cmd --reload</pre>
This assumes you see the `public` zone after the first command.

On Debian, you can run:<pre>sudo iptables -A INPUT -p tcp -m tcp --dport 22350 -j ACCEPT</pre>

WIBU Software Licence Update Request

2020-06-11T06:09:35Z

Jaap.vandervelde: Added a reference to a (new) Linux software license page

Software licences are an alternative option to hardware USB licences. Please select the license host carefully as the software based dongle will be bound to it. If over time you decide you want to move to another computer we will need to re-issue you with a new software license (which will incur a small administration fee).

<ol>
<li> Email sales@tuflow.com to request a software licence. You will be sent an empty licence container file (*.wibucmlif).
<li> Install [[Wibu_Dongles#Installing_CodeMeter_RunTime_Kit | Codemeter Control Centre]] 
If your license host is a Linux host, please refer to [[WIBU_Software_Licence_Linux | WIBI Software License Linux]] for the rest of the process
<li> Open Codemeter Control Centre (from the start menu) and drag and drop the provided .wibucmlif onto it. This will import an empty licence container onto the computer (it will show with a grey icon in the licence tab).
<li> With the empty licence container selected click the “Licence Update” option, as per the image below. [[File:Software_Licence_001.PNG|600px]]
<li> Select “Next” at the next dialogue. [[File:Software_Licence_002.PNG|600px]]
<li> Select “Create Licence Request”. [[File:Software_Licence_003.PNG|600px]]
<li> Save the licence request file to your computer. [[File:Software_Licence_004.PNG|600px]]
<li> Email the licence request file (.WibuCmRaC) file to sales@tuflow.com
</ol>