A Distributed Simulation Framework for Conformal Radiotherapy
G. Yaikhom, J. P. Giddy, D. W. Walker and P. Downes
School of Computer Science, Cardiff University, Cardiff, UK
{g.yaikhom, j.p.giddy, d.w.walker, p.downes}@cs.cardiff.ac.uk
E. Spezi and D. G. Lewis
Department of Medical Physics, Velindre Cancer Centre, Cardiff, UK
{emiliano.spezi, geraint.lewis}@velindre-tr.wales.nhs.uk
Abstract
This paper describes the RTGrid distributed simulation
framework for conformal radiotherapy. We introduce novel
approaches through which several distributed computing
technologies are made accessible to Monte Carlo simulations for radiotherapy dose calculations. Currently, radiotherapy treatment planning is typically performed on PCs
and workstations which lack the computational power to
run Monte Carlo simulations quickly enough to be useful
to clinicians. Therefore, although Monte Carlo simulation
techniques offer highly accurate doses, they are seldom chosen for clinical deployment. The RTGrid project is investigating both the capability and capacity modes of exploiting
grid computing for radiotherapy treatment planning using
Monte Carlo simulations.
1. Introduction
Radiotherapy treatment planning makes use of software
that strikes a balance between execution time and the accuracy of dose calculation that are derived in the radiotherapy treatment plan. It would be preferable to use Monte
Carlo (MC) simulations to plan radiotherapy treatments in
order to determine more accurately the radiation dose to the
tumour and neighbouring healthy tissue and organs. However, the MC approach is computationally intensive and it
typically takes days to run a simulation for one patient. The
RTGrid project is investigating the use of distributed computing resources to reduce the runtime of the MC simulations to no more than a few hours, with the aim of making
this approach clinically deployable. Of particular interest is
the radiotherapy treatment of anatomically inhomogeneous
areas of the body such as the lungs, head, and neck, for
which the current planning systems are not sufficiently accurate, and where the use of MC techniques is likely to have
a significant impact on the determination of more accurate
doses; and, therefore, increase the understanding of doseresponse relationships [10].
Currently, radiotherapy treatment planning is typically
performed on PCs and workstations which lack the computational power to run MC simulations quickly enough to
be useful to clinicians. Thus, although MC simulation techniques offer high dose-accuracy, they are seldom chosen for
clinical deployment. With grid-based distributed computing systems, however, it is feasible to provide access to a
large pool of computing resources, and thus present the possibility of performing these sorts of complex computations
within a shorter period of time. The Grid can be used for radiotherapy treatment planning in two ways: (1) a single MC
simulation can be split up into loosely-coupled sub-tasks
which can then be executed in parallel on grid resources
and clusters; and, (2) multiple simulations can be run in
parallel to achieve high processing throughput. In the latter
case, different simulations might be performed with different input parameters to optimise the treatment of a single
patient; or, the simulations might be for completely different patients. The RTGrid project is investigating both the
capability and capacity modes of exploiting grid computing
for radiotherapy treatment planning using MC simulations.
In a hospital, the clinical scientists responsible for
preparing simulation-based radiotherapy treatment plans do
not have any experience with the use of grid computing
systems. They, therefore, require a simple graphical user
interface that provides secure access to the underlying software and hardware used to perform the MC simulations. In
the RTGrid system, the component web portal provides interfaces for authenticating users, specifying simulations in
terms of computational ‘experiments’, monitoring the executions of these experiments, and viewing the results produced by these experiments.
This paper describes the RTGrid simulation framework
and its portal interface, and introduces some novel ap-
proaches through which several distributed computing technologies are made accessible to MC simulation for radiotherapy dose calculations. The RTGrid portal has been successfully deployed for use by research and clinical scientists
at the Velindre Cancer Centre, Cardiff.
The remainder of this paper is organised as follows. In
Section 2, we describe the problem domain: radiotherapy
treatment planning. Section 3 describes the system architecture underlying the RTGrid simulation framework. The
data model is discussed in Section 3.1. In Section 3.2, the
simulation management system and portal are discussed in
detail. Future work and possible applications of the framework to other domains are discussed in Section 4. Finally,
we conclude this paper in Section 5.
2
Scientists
1. They allow the accurate characterisation of the radiation source and its interactions everywhere within the
Clinicians
Web Services on Apache AXIS
RTGrid Database on MySQL server
Experiment Manager
Distributed Resources (Condor and NGS)
Figure 1. RTGrid System Architecture.
complex anatomy of the patient [3]. Thus, the dose
in and around non-water-equivalent regions (such as
the lungs, head, and neck) can be calculated more accurately and, therefore, increases the reliability with
which dose-response relationships are determined.
Radiotherapy Treatment Planning
Radiotherapy, surgery, and chemotherapy, singly or in
combination, are the three mainstays of cancer treatment.
The rapid evolution of the technology used to deliver radiotherapy has gone hand-in-hand with the development
of ever more accurate dose calculation methods. Modernday radical radiotherapy involves complex multi-field treatments using computer-controlled linear accelerators, delivering high-voltage X-ray photon beams. The development
of multi-slice computerised tomography imaging has had a
dual benefit in (1) allowing accurate visualisation of patient
anatomy, and (2) providing a basis for 3D dose computation. Complementary imaging modalities, such as MRI and
PET, can also provide enhanced visualisation of tumour volumes in certain cases.
The introduction of field-defining devices, such as multileaf collimators, has allowed the development of conformal radiotherapy involving sophisticated shaping of threedimensional dose distributions to conform closely to the tumour volume, while minimising the dose to the healthy surrounding anatomy. The rationale is that this approach allows tumour ‘dose escalation’, increasing the probability of
local tumour control (and hence patient survival) without
the prohibitive constraints of significant radiation damage
to surrounding normal tissues.
Radiotherapy dose calculation methods have evolved
greatly over the three decades since the introduction of
computerised planning using ‘beam libraries’ of data measured in a water medium, through the use of convolution/superposition methods based on pre-computed elemental dose deposition ‘kernels’ [1], to the early stages of
deployment of event-by-event MC simulation of radiation
transport [12]. MC methods have major advantages over
the other dose calculation techniques.
RTGrid Web Portal
2. Increasing complexity of the problem to be modelled
(i.e. the treatment technique) does not significantly affect the complexity of the MC model itself [4]. However, full clinical utilisation of MC is hampered by
the long calculation times in addition to the significant
amount of computational resources that are required to
make this approach practical for routine radiotherapy
planning.
Radiotherapy treatment planning systems are generally
developed by commercial vendors and licensed for clinical
use by the relevant national or international regulatory authorities. The next generation of such systems is likely to
incorporate some form of MC simulation of radiation transport, but with certain variance reduction techniques [7] including approximations made in the dose calculation models to speed up the process. An alternative approach is
to use more exact simulations, together with parallel and
distributed computing methods to reduce calculation times.
Whatever the dose calculation method involved in the clinical treatment plan, it is a requirement on the part of the
clinical scientist(s) responsible for the production and quality control of those plans to ensure that each is verified using independent dose calculations [9]. Given the increasing
complexity of treatment techniques and the variety of calculation algorithms becoming available, it is most important
to be able to rely on the most accurate dose calculation platforms for plan verification.
3
RTGrid System Architecture
The primary objectives of the RTGrid project are: firstly,
to make dose calculation with MC simulations deployable
in a clinical situation, and secondly, to provide a flexible
framework that allows the integration of new simulation
code bases and computational resources, as they become
available.
Based on these two objectives, the architecture of the
RTGrid simulation framework is broadly divided into four
main components: 1) the web portal, which provides a web
interface for accessing the RTGrid backend, 2) the web services, which serve requests received from the portal, 3) the
experiment manager, which manages the actual simulation,
and 4) the computational resources, where the simulations
are eventually run. This architecture is shown in Figure 1.
All communication between the web services and the experiment manager occurs through a database (the RTGrid
database). This provides a persistence layer and decouples
the experiment management from the presentation layers.
Before we describe each of these components in detail,
let us first discuss the data model which represents the conceptual entities of the RTGrid system.
3.1
Data Model
The RTGrid database contains four primary entities: experiment profiles, computational resources, simulation experiments and RTGrid users. An experiment profile provides a skeleton for describing the steps to run a particular
class of simulations. Profiles can be parameterised, using
an extension mechanism, to allow configuration for a particular simulation case. A user combines a profile and a
resource in order to create an experiment. This structure
provides a large degree of flexibility to the profile designer,
while restricting clinical users to a well-defined set of triedand-tested simulation templates.
3.1.1
Experiment Profiles
An experiment profile is a generic template for creating new
experiments. When a simulation management framework,
such as the RTGrid, is designed, one of the crucial decisions that must be made is the manner in which users will
be allowed to configure their simulations.
During the requirements analysis phase, with Velindre
Cancer Centre as our target environment, we found that, in
general, there are two main classes of users of such frameworks. The first class of users are the clinical scientists who
run the treatment planning system. Since this group of staff
do not need to know how the underlying simulation system
works, they should be granted limited access to simulation
configurations. The second class of users are the research
scientists, who need more control over the simulations, as
they have to experiment with different settings before finalising experiment templates. To cater to these varying requirements, the RTGrid system uses profiles.
An experiment profile consists of three main components: 1) profile scripts—a set of files (shell scripts and job
Experiment Manager
JSDL
Shell Scripts
Profile Extension XML Description
Simulation Code Base and Data
Experiment
Radiotherapy Dose
Figure 2. Components of a Profile.
description) that describe the simulation stages, 2) the simulation code base and relevant data that will be used at each
of the simulation stages, and 3) the profile extension, which
specialises the generic template by allowing users to pass
specific parameters to the profile scripts. The components
and their relationships are shown in Figure 2.
A basic profile consists of a Job Submission Description Language (JSDL) [2] document that provides a generic
description of a job, including a command to be run on a
remote system and files to be staged in and out. In addition,
pre- and post-processing scripts exist to create the input files
and to collate the output files.
Although the JSDL document can capture most of the
simulation invariants, it may be desirable to allow users
of the profile to change certain simulation variants (for instance, a profile may allow users to specify the number of
primary particles to be simulated). In the RTGrid framework, such parametric specialisation of the profile scripts is
achieved by using a profile extension.
A profile extension is an XML description, which is defined when a profile is created. It describes various parameters that can be passed to the profile scripts, thus altering the behaviour of the scripts according to the requirements of a particular experiment. For instance, we
show in Figure 3 a sample profile extension. This XML
description defines three controls, each enclosed within a
<Control></Control> tag pair. The type attribute of the
<Control> tag specifies the type of control (for example,
SELECTION for a drop-down menu). Depending on the control, several other attributes may also be specified (for example, display properties, such as the number of columns,
column, that should be used to display the choices). Then,
within each <Control></Control> tag pair, entities that are
part of the control are defined. For instance, the label,
<Label>, that should be displayed next to the control; the
name, <Name>, of the parameter that should be associated
with the control; any default, <Default>, value that should
be displayed; and so on. In Figure 4(b), we show a sample
profile extension, as displayed to an experiment creator.
For clarity and continuity, let us defer further discussion
of the profile extension until Section 3.2.3, where it will be
<?xml version="1.0" encoding="UTF-8"?>
<Extension>
<Control type="SELECTION">
<Label>Input geometry defined by:</Label>
<Name>Geometry</Name><Default>DICOM</Default>
<Option>
<Label>egsphant file</Label>
<Value>egsphant</Value></Option>
<Option>
<Label>DICOM files</Label>
<Value>DICOM</Value></Option>
</Control>
<Control type="TEXT">
<Label>File(s) location:</Label>
<Name>fileLocation</Name><Size>50</Size>
<Default>./egsnrc/dosxyzrc/</Default>
</Control>
<Control column="2" type="CHOICE">
<Label>Output method</Label>
<Name>FileOutput</Name><Default>3ddose</Default>
<Option>
<Label>3ddose file(s)</Label>
<Value>3ddose</Value></Option>
<Option>
<Label>RTDOSE DICOM file(s)</Label>
<Value>RTDOSE</Value></Option>
</Control>
</Extension>
Figure 3. Sample Profile Extension XML.
described in relation to the portal.
The experiment profile approach has several advantages.
Firstly, the profile scripts have to be written only once. Secondly, because of the generic nature of the scripts, the simulation framework does not impose any restriction on the
kinds of simulation code base that can be used within the
framework; thus, allowing the integration of a wide variety of simulation code bases within the same framework.
Thirdly, once the profiles have been defined, they can be
reused to instantiate a wide variety of experiments by simply changing the parameters that are passed to the profile
scripts. Most notably, this mechanism can be used to select
a particular patient record from a Digital Imaging and Communications in Medicine1 (DICOM) server. Finally, since
the same profile can be reused for instantiating several simulations, the approach ensures flexibility while limiting the
chance of introducing errors.
3.1.2
Computational Resources
Computational resources are parallel and distributed systems where computation-intensive jobs may be submitted
for execution. Distributed resources include batch queuing systems, such as Condor [8]; grid middleware-based resources, such as Globus [5] enabled resources; or resource
1 The DICOM standard [11] was created by the National Electrical
Manufacturers Association (NEMA) to aid the distribution and viewing
of medical images, such as CT scans, MRIs and ultrasound.
brokers, such as GridWay [15]. The RTGrid architecture
has been designed in such a way that will allow addition
of new resources into the system as and when they become
available.
In the RTGrid system, a remote resource is specified by
an identifier similar to a Uniform Resource Identifier (URI).
This defines the details that are required to contact a remote
resource. For instance, the Cardiff University Condor pool
is specified as condor://localhost/INTEL/LINUX; whereas access to the NGS resources at Oxford is specified as globus://
grid-compute.oesc.ox.ac.uk/jobmanager-pbs.
Since the user has the choice of selecting the right resources when they create new experiments, they have the
advantage of executing experiments with sensitive data only
in secure restricted domains. Clinical and research scientists in Velindre Cancer Centre can therefore choose the
Velindre Condor pool, where jobs are executed within the
security infrastructure of the National Health Service network. Where the computations involve less sensitive data,
the same users might benefit from a larger resource pool
available through wide-area grid services, such as computational resources provided by the UK National Grid Service.
3.1.3
Simulation Experiments
Simulation experiments are created when a user combines a
profile and a resource. The experiment represents the state
of the workflow for running a set of jobs on a resource.
While profiles and resources are static descriptions of what
to run and where to run, an experiment represents a running
instance.
Experiments are effectively parameterised through the
profile extension, which allows users to vary the experiment
in a controlled manner, by varying, for example, the patient
ID in a DICOM repository, in order to perform an experiment relevant to a particular patient.
3.1.4
RTGrid Users
The RTGrid user entity provides the basis for access control within the system. The identity of a user is established through a username/password combination or
through certificate-based authentication. This identity is
then used to determine the level of access granted to the
user for managing profiles, resources, and experiments.
Except for the users with administrative permissions, all
users are allowed access to a subset of the profiles and resources that are appropriate to their needs. By limiting the
capabilities of these users to the templates defined within
the available profiles, the RTGrid system reduces the possibility of committing minor, yet hard-to-detect, errors while
creating a simulation experiment. Where specialisation of
the templates is deemed suitable, extensions to the templates are provided in a well-defined data entry interface
which is displayed to the user when the specific template is
chosen. Furthermore, since the profiles can only be modified by users with administrative permissions, any error
detected in the simulation experiments can be easily diagnosed and resolved by analysing the particular template
upon which the experiment was based. This means that
when a profile has been corrected or improved, all the experiments that are derived from it benefit from the changes
without making any explicit changes to any particular experiment.
Users with administrative permissions are usually research scientists who work directly with the simulation code
base. They are experts in the field, and understand the intricate details of the simulation framework. They design the
simulation templates by performing several novel experiments with different configurations and settings of the basic
code base. It is the research scientists who identify which
part of the simulation may be specialised with user defined
parameters, and which parts are common to all the experiments. Based on their findings, they write the execution
scripts, job descriptions and then define relevant profile extensions which will be translated later into a user interface.
Once a profile has been defined and added into the RTGrid
system, it is made accessible to other users.
By default, experiments created by a user are not shared
with other users. However, where the user wishes to share
the experiment, he or she is allowed to do so by specifying
the users when the experiment is being created. This may
also be done later. In the RTGrid system, it is possible for
a user to share experiments with read access, or with both
read and write access.
3.2
System Components
3.2.1
Experiment Manager
In the RTGrid backend, a master process runs continuously,
monitoring the state of the entries in the experiments table
of the RTGrid database. When a user starts an experiment,
this master process spawns a separate experiment manager
process to run the experiment. The experiment manager
runs the jobs in the experiment according to the description found in the profile and other relevant parameters that
were specified by the user when the experiment was being
created.
The experiment manager process first runs the profile
pre.sh script. This pre-processing script populates the experiment directory with the required input files. Where an
input file differs between jobs, the files can be given a different name including a job identifier. The job identifiers
are stored in a file called JOBS. The experiment manager
then determines the number of jobs to launch from the number of lines in this file. Wherever a parameter placeholder
Type
User
Experiment
Profile
Resource
Description
Allows administrators to add, delete, or
modify user information in the RTGrid
database. It also allows users to manage their account (for example, changing
their password).
Allows certified users to create, delete, or
update experiments that are accessible to
them. Services in this category also allow users to check simulation status, as
well as browse and download files from
the simulation environment.
Allows users with administrative privileges to add, delete, or modify profiles in
the RTGrid system.
Allows users with administrative privileges to add or remove resources from the
RTGrid system.
Table 1. RTGrid web services.
appears in the JSDL document, the experiment manager replaces this with the job identifier. Additional parameters are
used to identify the architecture and the operating system of
the resources where the jobs that belong to the experiment
must be executed. Such parameters are used by the experiment manager to select appropriate executable components
from the simulation code base, and also to set the environment for the particular architecture.
Once a job has been submitted to the appropriate resource, the experiment manager monitors its progress and
updates the database regularly so that the current status
of the jobs is reflected when a status is requested from
the database. When all the jobs in the experiment have
concluded successfully, the experiment manager runs the
post.sh script in order to collate all of the output files that
were generated by the jobs. The experiment is then flagged
as ‘done by updating the database. Finally, the experiment
manager process exits. Where some of the jobs have failed,
the experiment manager flags the experiment as ‘failed’.
After setting the relevant error messages in the database,
the experiment manager exits.
To submit jobs to a resource, the experiment manager
loads a job manager module that is specific to the type of
resource requested by the experiment. In the RTGrid system, we have implemented job modules for both Condor
and Globus infrastructures. Job manager modules provide a
consistent job submission interface to the experiment manager. Thus, new resource infrastructures may be added into
the RTGrid system by defining appropriate job manager
modules. This makes the RTGrid system highly extensible, as job managers can be plugged into the system without
modifying the remaining components of the system.
3.2.2
Web Services
The RTGrid web services provide access to the RTGrid
backend. These services (see Table 1) are implemented over
Apache Axis framework,2 and can be accessed through the
SOAP (Simple Object Access Protocol) [14] interfaces that
are advertised through WSDL (Web Services Description
Language) [13]. The services allow control and monitoring
of the entities in the RTGrid database, which corresponds to
the RTGrid data model discussed in Section 3.1.
3.2.3
Web Portal
The RTGrid web portal is implemented over the Gridsphere
portal framework.3 It provides four JSR-168 [6] compliant
portlets: 1) the experiments portlet, 2) the profiles portlet,
3) the resources portlet, and 4) the user management portlet. Each of these portlets is designed to cater to different
aspects of simulation management.
The experiments portlet allows portal users to request
services related to the management of simulation experiments. By using these interfaces, a certified user can create
new experiments, analyse the status of current experiments,
or retrieve output data (the radiotherapy dose) from experiments that have successfully concluded. The resources
portlet, on the other hand, allows system administrators to
add or remove computational resources from the RTGrid
framework. Similarly, the user management portlet provides interfaces for managing the users.
2 http://ws.apache.org/axis/,
Version 1.4.
Version 2.2.9.
3 http://www.gridsphere.org/,
XML
Database
Yes
No
Failed
valid?
parse
ext.xml
Name/Value pairs
The design of job manager modules is often non-trivial,
due to the requirement to provide consistent behaviour between modules. For instance, Condor creates an individual
working directory for each job, but file transfers are always
carried out to or from this top-level directory. On the other
hand, Globus does not provide an individual working directory for each job, but does allow files to be transferred to
subdirectories if they already exist.
The requirement to provide alternative behaviour to the
default behaviour of each resource type typically requires
the submission of a specially constructed Unix shell or Windows batch script to be run as the remote job. This script
performs the necessary actions to setup the correct environment on the remote node, runs the user command, and then
ensures that cleanup actions will take place smoothly. As an
added advantage, the script allows more detailed status information to be returned to the Experiment Manager, such
as the exit status of the user’s command. This type of information is invaluable in tracking down errors that occur
many layers beneath what is observable to the user.
XML to HTML
Display HTML
Create Experiment
HTML to XML
upload
Profile Creation
Experiment Creation
Figure 5. Parameters from Extension.
Although some of the functionalities provided by the
above portlets are in fact standard requirements, as far as
experiment management is concerned, the novel and defining feature of the RTGrid framework is the concept of an
experiment profile (highlighted previously in Section 3.1.1),
which is accessed through the profiles portlet.
When a new experiment is created in the experiments
portlet, a profile must be chosen to identify the template
that should be used. At this stage, if the chosen profile is
associated with a profile extension, the portlet displays a
set of controls based on the XML description. For instance,
Figure 4(b) shows a sample profile extension. If the controls
are defined with default values, these values are displayed to
the user. The user can either accept these values, or change
them accordingly.
When the experiment creation request is sent to the web
service, the values of the controls in the profile extension
are captured in another XML description, where the parameters are stored as name/value pairs. This XML description
is experiment specific. Eventually, when the experiment
manager invokes the profile scripts, this XML description
is parsed and the retrieved parameters are passed to the profile scripts (as shown in Figure 5).
In Figure 4, we show the four primary phases of creating
and running an experiment:
• Firstly, a research scientist creates a profile by uploading the profile components (shell scripts, JDSL job descriptions, and the profile extension). See Figure 4(a).
• Secondly, a clinical scientist selects the profile in the
experiment creation portlet. This displays the profile
extension interface, which is associated with the profile. Once the appropriate values have been set, the
experiment is created. See Figure 4(b).
• Thirdly, in the list of experiments that are displayed,
the user starts the experiment by pressing the ‘start’
link in the progress column. The column now displays
a progress bar. See Figure 4(c).
(a)
(b)
(c)
(d)
Figure 4. These screenshots were taken from the RTGrid portal. The four primary activities displayed
are as follows: (a) Shows the creation of a new profile. Relevant data files and scripts are uploaded.
A profile extension has also been uploaded (displayed in the preview panel); (b) Shows the creation
of an experiment by choosing a profile. The associated profile extension is displayed; (c) Shows the
list of experiments where any newly created experiment can be started; (d) Shows the details of an
experiment that is currently being executed (job statistics and file browser).
• Finally, when a request for the details of an experiment
is made, the portal displays the job statistics and a file
browser for exploring the contents of the execution directory which is associated with the experiment. The
file browser allows users to download the output files
(e.g., the radiotherapy dose). See Figure 4(d).
4
Future Work
The RTGrid portal has been successfully deployed at the
Velindre Cancer Centre, and is currently being used to run
MC simulations. Research and clinical scientists are currently designing and trying out new profiles so that they may
be made available to other users. Several research institutes
have also shown interest in the project, and we are currently
working on releasing the RTGrid system to other users.
For the future, we are working on two primary objectives: (a) to conduct performance benchmarks in order to
demonstrate the advantages that the use of distributed resources has brought to radiotherapy simulations; and (b) to
extend the RTGrid system to support interfacing with commercial Treatment Planning Systems (TPSs) that are widely
deployed in a clinical environment. Most clinical users are
more familiar with TPS software than with the RTGrid portal; hence, it will be advantageous for them to be able to
submit jobs to remote resources without leaving the TPS.
Although this will require cooperation from the commercial
providers of TPS, we are working on alternative approaches
where the RTGrid system monitors a DICOM server, which
is allowed to communicate with a TPS. When a clinician
updates the DICOM server with new patient details, the RTGrid system will automatically create a new experiment by
using one of the default profiles that have been designed to
work with TPS based DICOM information. Through these
extensions, we hope that clinical users will find the RTGrid
simulation framework easier to use.
5
Conclusion
In this paper, we have highlighted computation-time issues that have prevented the adoption of radiotherapy treatment planning that is based on MC simulations, although
these simulations offer a high dose-accuracy. To solve the
critical issues, the RTGrid project has introduced a novel
distributed simulation framework, which brings together
several distributed computing technologies that will allow
MC simulations to be deployed to distributed resources,
such as clusters and the Grid. The main contribution of
the RTGrid project is that the simulation framework serves
a dual purpose: assisting research scientists to test several
MC simulation code bases and settings, and allowing clinicians to use these settings from the same infrastructure,
through the convenience of a web based portal.
Acknowledgement
The RTGrid project is supported by the EPSRC under
grant number EP/C538641/1.
References
[1] A. Ahnesjo and M. M. Aspradakis. Dose calculations for
external photon beams in radiotherapy. Physics in Medicine
and Biology, 44:R99–R155, 1999.
[2] A. Anjomshoaa, F. Brisard, M. Drescher, D. Fellows, A. Ly,
S. McGough, D. Pulsipher, and A. Savva. Job Submission Description Language (JSDL) specification, version
1.0. Recommendations Document GFD-R.056, Global Grid
Forum, Nov 2005.
[3] M. R. Arnfield, C. H. Siantar, J. Siebers, P.Garmon, L.Cox,
and R.Mohan. The impact of electron transport on the accuracy of computed dose. Medical Physics, 27(6):1266–1274,
2000.
[4] G. S. Fishman. Monte Carlo: Concepts, Algorithms and
Applications. Springer, 1996.
[5] I. Foster. Globus Toolkit version 4: Software for serviceoriented systems. In IFIP International Conference on Network and Parallel Computing, volume LNCS 3779, pages
2–13. Springer-Verlag, 2006.
[6] Java Community Process.
Java Specification Requests (JSR) 168:
Portlet Specification.
http://www.jcp.org/en/jsr/detail?id=168, 2003.
[7] I. Kawrakow and M. Fippel. Investigation of variance reduction techniques for Monte Carlo dose calculation using
XVMC. Physics in Medicine and Biology, 45:2163–2183,
2000.
[8] M. Litzkow, M. Livny, and M. Mutka. Condor - a hunter of
idle workstations. In Proceedings of the 8th International
Conference of Distributed Computing Systems, June 1988.
[9] W. P. M. Mayles, R. Lake, A. McKenzie, E. M. Macauly,
H. M. Morgan, T. J. Jordan, and S. K. Powley, editors.
Physics Aspects of Quality Control in Radiotherapy (Report
No. 81). Institute of Physics and Engineering in Medicine,
1999.
[10] R. Mohan. Why Monte Carlo? In D. D. Leavitt and
D. Starkschall, editors, Proc. XII Int. Conf. on the Use of
Computers in Radiation Therapy, pages 16–18, Salt Lake
City, 1997. Medical Physics Publishing.
[11] National Electrical Manufacturers Association. Digital
Imaging and Communications in Medicine (DICOM) standard. ftp://medical.nema.org/medical/dicom/2008, 2008.
[12] F. Verhaegen and J. Seuntjens. Monte Carlo modelling of
external radiotherapy photon beams. Physics in Medicine
and Biology, 48:R107–R164, 2003.
[13] W3C XML Protocol Working Group. Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl/,
2001.
[14] W3C XML Protocol Working Group. Simple Object Access
Protocol (SOAP). http://www.w3.org/TR/soap/, 2007.
[15] R. Yahyapour and P. Wieder. Grid scheduling use cases. Informational Document GFD-I.064, Global Grid Forum, Mar
2006.