Organisation Cloud Software Execution: Difference between revisions
Content deleted Content added
Added a technical term glossary at the end. |
Numbering error |
||
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.
==
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.
==
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:
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.
==
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:
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.
==
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.
==
Hardware selection is very specific to the modelling requirements of each organisation and project. There is no one-size-fits-all recommendation to make.
| |||