Organisation Cloud Software Execution - Revision history

Pavlina Monhartova at 05:11, 24 July 2025

2025-07-24T05:11:50Z

← Older revision		Revision as of 15:11, 24 July 2025
Line 81:		Line 81:

	== Why is my run on the cloud slower than I expected based on the specs? ==		== 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 <u>[[Hardware Benchmarking ~~(2018-03-AA)~~\|Hardware Benchmarking]]</u> pages.<br>		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 <u>[[Hardware Benchmarking \| Hardware Benchmarking]]</u> pages.<br>
	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.<br>		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.<br>
	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.<br>		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.<br>

Pavlina Monhartova: /* Why is my run on the cloud slower than I expected based on the specs? */

2025-07-23T00:06:00Z

Why is my run on the cloud slower than I expected based on the specs?

← Older revision		Revision as of 10:06, 23 July 2025
Line 81:		Line 81:

	== Why is my run on the cloud slower than I expected based on the specs? ==		== 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 <u>[Hardware Benchmarking (2018-03-AA)\|Hardware Benchmarking]]</u> pages.<br>		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 <u>[[Hardware Benchmarking (2018-03-AA)\|Hardware Benchmarking]]</u> pages.<br>
	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.<br>		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.<br>
	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.<br>		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.<br>

Pavlina Monhartova: /* Why is my run on the cloud slower than I expected based on the specs? */

2025-07-23T00:05:46Z

Why is my run on the cloud slower than I expected based on the specs?

← Older revision		Revision as of 10:05, 23 July 2025
Line 81:		Line 81:

	== Why is my run on the cloud slower than I expected based on the specs? ==		== 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.<br>		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 <u>[Hardware Benchmarking (2018-03-AA)\|Hardware Benchmarking]]</u> pages.<br>
	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.<br>		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.<br>
	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.<br>		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.<br>

Chris Huxley: /* Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? */

2025-03-21T05:30:29Z

Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves?

← Older revision		Revision as of 15:30, 21 March 2025
Line 94:		Line 94:
	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.<br>		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.<br>
	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.<br>		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.<br>

	== 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.<br>

	== Which machine size / hardware type do you recommend for my model runs? ==		== Which machine size / hardware type do you recommend for my model runs? ==

Chris Huxley: /* Do I need a different licence to run models on the cloud? */

2025-03-16T23:19:21Z

Do I need a different licence to run models on the cloud?

← Older revision		Revision as of 09:19, 17 March 2025
Line 66:		Line 66:
	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.<br>		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.<br>
	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.<br>		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.<br>
	Alternatively, you may be able to make use of web licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.<br>		Alternatively, you may be able to make use of Cloud direct web network licences, please contact [mailto:sales@tuflow.com TUFLOW Sales] for more information on that.<br>

	== What can go wrong when running models on the cloud? ==		== What can go wrong when running models on the cloud? ==

Pavlina Monhartova: /* Common Questions Answered (FAQ) */

2023-12-17T21:44:58Z

Common Questions Answered (FAQ)

Show changes

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

2023-12-15T04:06:55Z

Technical Terms Glossary: Alphabetical ordering

@@ Line 134: / Line 134: @@
 * '''Azure Batch''': A cloud computing service provided by Microsoft Azure for running large-scale parallel and batch compute jobs.
-* '''Google Cloud Batch''': A batch computing service provided by Google Cloud, similar in functionality to Azure Batch and AWS Batch.
+*'''AWS Batch''': Amazon Web Services' batch computing service that enables the processing of a large number of batch jobs.
 * '''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.
 * '''X-Server''': A program that manages and displays graphical user interfaces in a Unix or Linux environment.

Jaap.vandervelde: Numbering error

2023-12-15T04:04:21Z

Numbering error

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

2023-12-15T04:03:38Z

Added a technical term glossary at the end.

← Older revision		Revision as of 14:03, 15 December 2023
Line 130:		Line 130:
	* 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.		* 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.		* 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.

Jaap.vandervelde: Added Q14 on hardware selection

2023-12-15T03:55:55Z

Added Q14 on hardware selection

← Older revision		Revision as of 13:55, 15 December 2023
Line 121:		Line 121:
	== Q13: Is there a developed service to run large numbers of model runs on the cloud, if we cannot set it up ourselves? ==		== 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.		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.

← Older revision		Revision as of 14:04, 15 December 2023
Line 93:		Line 93:

	None of these should stop you from trying, but ensure everything works like you expect, before scaling up to many model runs at once.		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? ==		== 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.		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.		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? ==		== 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.		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.

Line 105:		Line 105:

	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.		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? ==		== 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.		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.

Line 119:		Line 119:

	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.		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? ==		== 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.		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? ==		== 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.		Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.