-
Notifications
You must be signed in to change notification settings - Fork 1
Standalone drive
The TsuDAT1 system was designed to run as a standalone drive connected to either Windows or Linux machines. The drive contains the raw PTHA data, data derived from the raw data (to speed up the application), a wxPython application and all required support software to run the application (Python, etc).
The disk has an autorun.inf file that runs a .BAT file that configures the Windows environment to use the software on the disk rather than any already installed on the host machine. There is also a Linux-style autorun file with an autorun.sh file that assumes the host Linux machine has all the required software already installed.
The TsuDAT2 system is more "heavyweight" than TsuDAT1 so requires a rethink for the external disk solution. There are two possible approaches:
- installer
- boot
- vmware
There will be a Windows installer that installs all required software onto the host machine. All data will remain on the external drive, so the installed software needs to be configured to find all required data on the external drive. (OPTION: copy all/some data to host machine)
The services should not be started automatically as the user of the host machine doesn't need them running continuously. There must be some easy way to start the services required to run TsuDAT2. This includes starting a browser with the correct URL for TsuDAT2. There also needs to be a simple way to stop the services when the TsuDAT2 interface is no longer required.
Is it possible to turn off the services without stopping a running ANUGA simulation?
Is it reasonable to enforce a "one ANUGA run" policy if the simulation is running on the local machine? Or should the user just be warned before starting a second, simultaneous run? Or can runs be queued?
How does the run reporting system work if the runs are on the local Windows machine?
The boot solution has the host machine being booted from the external drive. This would run Linux with all required services/software installed and running. There would be an automatic login with a browser started and pointed at the correct local URL.
The installer solution doesn't require a user to use a probably unknown operating system. The interface would run through the user's usual browser, adding even more comfort. The boot solution would put the user into a probably unknown operating system, but would again be run through a browser, limiting user discomfort.
The installer solution has a cost as extra software and services would be installed. This assumes that there is adequate free disk space. The boot solution requires no extra disk space on the host internal disk(s).
The installer solution allows the host machine to be used for other tasks while an ANUGA simulation is running. It remains unclear just how useful the machine would be due to ANUGA using RAM and disk resources. The boot solution would not allow most users to use the machine for other purposes during an ANUGA run, which can take days.
A further option is that of providing a VMWare image and running that in the VMWare player on the host machine. This approach combines the installer and boot options - it is like the boot option but doesn't take over the host machine. There only needs to be one image as VMWare images are portable between Max/Win/Linux.