Infrastructure and RAPT/Grid Performance

Infrastructure

The GEMSS Grid employs a service-oriented client/server architecture (as shown in the figure), and illustrates a client side component manager that contains a number of plug-in Grid modules, and a server side Grid provision framework that is based on Web services and Apache AXIS. GEMSS works in sympathy with Firewalls - there is no need to open special ports through them. Two high performance computing (HPC) resources have been available within GEMSS, one with 64 CPU's (Germany) and one with 16 CPU's (Austria). A basic HTTPS security transport layer is provided for web service invocation, and built on top of this is support for the WS Security standard and a proprietary end-to-end security protocol. A project wide public key infrastructure (PKI) is in place, and this provides X.509 certificates that identify our users. The PKI underpins the WS Security, end-to-end security and authentication aspects within GEMSS. An experimental security logging system acts as a last line of defence. The economic aspects of the GEMSS service also mean that the user must demonstrate the authority to pay for use of the Grid resources. Both aspects are relevant to the Quality of Service (QoS) component that clarifies the contractual responsibilities of client and service provider in running the job. The middleware includes additional QoS features that permit advanced reservation and estimates of job completion time and a compute resource negotiator is available that gives the user freedom to choose the Grid platform on which the job should be run.

GEMSS Employs a service oriented architecture

Months of evaluation (with submission of over 600 RAPT jobs) have confirmed that Grid-enabled RAPT is robust and able to produce clinically relevant results of acceptable accuracy (within 2-3%) in under an hour (at least 30 processors are needed - compute time is a function of photon statistics and available processors). Grid reliability is important and averaged over 95% for the month of January 2005. Investigation of RAPT scalability shows almost linear performance gains for up to 30 processors (see the figure).

It is clear (even with Grid assistance) that iterative planning with GammaPlan cannot be replaced by RAPT since the latter is insufficiently responsive to provide rapid dose distributions for the iterative planning process (a speed increase of several orders of magnitude is required if RAPT is to compete with the 'real time' response of GammaPlan). With solve times of less than one hour however, clinical experience demonstrates that Grid-enabled RAPT has a valuable role to play in confirming the dose distribution determined by GammaPlan, particularly in those circumstances that contravene the assumptions inherent within GammaPlan. This means that for the large majority of cases, comparison of dose data computed by GammaPlan and RAPT show consistently good agreement (essential if RAPT is to gain any credibility in the clinical domain), but in the presence of bone/air close to the isocentre, striking differences result. Under these conditions RAPT has the opportunity to have a significant impact upon patient management.

RAPT scales well with up to 30 processors

Solution 'accuracy' as a function of compute times in RAPT