User Scenarios For Triana

Ultimately, users should be able to use the Grid transparently within Triana using an automatic distribution scheme. A user should need only to provide a Triana algorithm (task graph) and a maximum time for completion. Mechanisms plugged into Triana should then determine from this task graph the best way that the algorithm can be distributed onto the Grid given this user constraint. To do this, each unit within Triana will implement a monitoring API that will allow it to be quizzed about certain properties, for example, the number of flops required to complete its task (which is related to the input dimension), the amount of memory required and other information such as disk space requirements and network load. This information therefore can be used collectively to estimate the requirements from a complete algorithm (or part of an algorithm). Furtermore, we plan to provide a benchmarking API for estimating the JavaFlops on a machine. We are not interested in how fast (i.e. CPU speed) a particular machine is or even what operating system it is running, we simply need to know how fast that machine will be for running Java. Giving this combination of information, an optimization algorithm can be written to map a Triana network onto the Grid by splitting it up in the optimal way for the available resources. Users therefore, do not need to be involved in the distribution or parallelization of their code. However, there will be a manual mode also where the user's can specify the distribution themselves.

Below are a couple of user scenarios for which collaborators wish to use Triana for now.They are both examples of High Throughput computing for which we see an immediate benefit for Triana within the Grid context. Building an infrastructure within Triana to do this would be beneficial in a multitude of scientific areas.

Case 1: Galaxy Formation Simulation, Post Processing and Visualisation Using Triana –
               A Distributed Visual Programming Environment

Galaxy and star formation simulation codes generate binary data file that represents a series particles in three dimensions and their associate properties as a snap shots in time. The user of the code would like tovisualise this data as an animation in two dimensions with the ability to vary the point of view and project that particular two dimensional slice and re-run the animation.

Due to the nature of the data, each frame or snap shot is a representation at a particular point in time of the total data set, it is possible to distribute ach time slice or frame over a number of processes and calculate the different views based on the point of view in parallel.

In this scenario, the data file is loaded by a single Data Reader Unit within Triana, although the data file could be copied and distributed and this task done in parallel as well. The loaded data is then separated into frames, distributed amongst the various Triana servers distributed on the available network and processed to calculate the column density using smooth particle hydrodynamics.

A Triana visualisation unit on the users local machine is used to control the entire process and run the animation once the processing is complete. Each distributed Triana server returns it's processed data in order and the frames are animated. If the user wants a different view of the data the visualisation unit has controls that allow the manipulation of the view, messages are then sent to all the distributed servers so that the new data slice through each time frame can be calculated and returned.

Case 2:  Inspiral Search for Coallescing Binaries

Compact binary stars orbiting each other in a close orbit are among the most powerful sources of gravitational waves. The gravitational waves emitted in the process have twice the frequency of the binary and carry away its energy. This results in the gradual shrinking of the orbit. As the orbital radius decreases, a characteristic chirp waveform is produced whose amplitude and frequency increase with time until eventually the two bodies merge together. Laser interferometric detectors, such as GEO600 should be able to detect the waves from the last few minutes before the collision

For this search, we need to have a computing resource capable of speeds in the range of 5 and 10 Gigaflops to keep up in real time with an on-line search. The gravitational wave signal is sampled at 8kHz and sampled at 24-bit (stored in 4 bytes). However, the meaningful frequency range is up to 1 KHz and therefore a sampled representation of this contains 2,000 samples per second. The real-time data set is divided into chunks of 15 minutes in duration (i.e. 900 seconds) which results in a 7.2MB of data (4 x 900 x 2000) being processed at a time. This data is transmitted to a node and it is processed. The node initialises i.e. generates its templates (a trivial computational step) and then it performs fast correlation on the data set with each template in a library of between 5,000 and 10,000 templates. This process takes about 5 hours on a 2 GHz PC running a C program. Therefore, 20 PC’s would need to be employed full-time to keep up with the data.

Within a Grid scenario the number of PCs would need to be increased due to various types of downtime e.g. connection lost, user intervenes, computational bandwidth not reached etc. However, since it is a massively parallel problem we believe it can be solved within such an environment by simply distributing the code to as many computers that are available until the results are being returned with the specified time interval. The latency of such a system is not important and it can lag behind by several hours if necessary. We could employ a check-pointing mechanism to migrate if necessary. It may turn out that the Grid implementation may require 10 times the nodes than that of a dedicated cluster but it still could potentially keep up without the need to invest in a massively parallel machine to do the job.