TR 51

SoftIAM: Integrated assessment modelling
using distributed software components
Dr. Rachel Warren, Santiago de la Nava Santos, S.,Dr. Rupert Ford,

Graham Riley, Michael Bane, Christopher Barton, and Len Freeman
2006
Tyndall Centre for Climate Change Research Technical Report 51

SoftIAM: Integrated assessment modelling using
distributed software components
Tyndall Centre Technical Report No. 51
This is the final report from Tyndall research project IT2.15 (SoftIAM: Integrated
assessment modelling using distributed software components).The following researchers worked
on this project:
Dr. Rachel Warren1, Santiago de la Nava Santos, S.1, Dr. Rupert Ford2, Graham Riley2, Michael
Bane3, Christopher Barton,1, and Len Freeman2
1
Tyndall Centre for Climate Change Research, School of Environmental Sciences, University of East Anglia, Norwich
NR4 7TJ
2
Centre for Novel Computing, School of Computer Science, University of Manchester, Oxford Road, Manchester M13
9PL
3
Atmospheric Science Group, School of Earth, Atmospheric and Environmental Sciences, (SEASES), University of
Manchester M60 1QD

OVERVIEW
Abstract
softIAM has underpinned the success of the theme 1 flagship project to create the
Community Integrated Assessment System (CIAS). The CIAS integrated assessment model
was designed to be a flexible, coupled, modular computer model in which communication
between modules were to be located at different institutions, on different computer platforms
and written in different computer languages. The advanced softIAM technology had to be
developed to make this possible. The technology was developed through a collaboration
between the Tyndall Centre and the Centre for Novel Computing (CNC) in the University of
Manchester. The first aim of the project was to further develop the existing CNC bespoke
framework generator (BFG) for application within softIAM. The second and third aims were
to develop the softIAM software and Web Portal. The fourth aim was to apply the system to
create the implementations of CIAS required by the Tyndall flagship project, and, finally, the
fifth aim was to deploy these across multiple institutions. All of these aims were achieved, and
the user can now use the portal to execute several configurations of the CIAS integrated
assessment model. In particular CIAS has been demonstrated operating when deployed
between the Potsdam Institute in Germany, the CNC in the UK and the UEA in the UK. CIAS
currently incorporates modules from UEA, Cambridge University and the Potsdam Institute
and is being used by UEA to perform coupled scientific (integrated assessment) studies.
Keywords
Coupled modelling; bespoke framework generator; SoftIAM software engineering; CIAS
integrated assessment model; community integrated assessment system
Objectives
The main objective of softIAM was to deliver the software infrastructure necessary for the
operation of the Community Integrated Assessment System’s integrated assessment model, CIAS.
Specifically:
• to adapt and extend the Bespoke Framework Generator (BFG) for use in softIAM,
and hence CIAS
• to develop the softIAM technology to use the BFG and to support the initialisation,
compiling, staging and running of coupled models and visualisation of the resultant
output.
• to develop the softIAM Portal, a web interface to allow users to run CIAS from a
network of institutions in different countries
• to enable the Tyndall flagship project “Integrating Frameworks” to produce a
working version of CIAS containing economic, climate and impact modules
• to demonstrate the operation of this system across international boundaries.
Work undertaken
The Bespoke Framework Generator (BFG) was extended to support the initial and
emerging requirements of CIAS. Three new deployment targets were implemented (Globus, Web
Services and distributed MPI). These provide softIAM with the flexibility required to run the
CIAS coupled models with modules running on different machines, potentially in different
institutions, using different operating systems. The Globus solution was successfully tested
running between institutions (Manchester and UEA) using the Grid. The Web Services-based
solution was successfully tested running between institutions and between (Windows and Linux)
operating systems. The distributed MPI solution, a development of the Globus target, is now the
primary solution used by softIAM. This version uses a recent implementation of MPI which
provides the benefits of the previous two solutions (Globus and web services) with less complex
infrastructure requirements and improved communication performance. BFG was also modified
to allow it to be more easily integrated into the softIAM system. Further, (schema) validation
checks of the (xml) input data were added to check for errors and therefore make the system more
easy to use in production.
The softIAM technology was developed to use BFG as the coupling system and also to
allow the initial input data for a coupled model to be specified, the coupled model to be compiled
and run, on the appropriate hardware resources, and the resultant output visualised by the user.
A softIAM Web portal was developed to provide a simple user-interface for access to all
available functionalities of CIAS, whilst masking the details of softIAM infrastructure. From the
portal the user may select and run coupled, integrated models of CIAS, download results, archive
inputs and outputs, and plot graphs. Results typically detail the climate outcomes or impacts of
various economic policies or emissions scenarios.
During the softIAM project, a collaboration was set up with the Potsdam Institute in
Germany. The team resulting from this collaboration worked together to demonstrate an initial
deployment of CIAS operating between the Potsdam Institute, the CNC and UEA. The Potsdam
Institute use a home-grown communications library called TDT to couple their modules. BFG
was further extended to be able to use TDT as a deployment target. This implementation of BFG
allowed Potsdam modules and CIAS modules to interoperate in a coupled model using BFG and
was tested using modules distributed at the three sites in a single coupled scenario.
Results
The three technical layers discussed above (BFG, softIAM technology and softIAM Web
Portal) were used to demonstrate the first implementation of CIAS, a coupling between an
emissions database and a simple climate model. A full deployment of CIAS was then created, in
which an economic module, an emissions module, two alternative climate modules and an
impacts module may be linked together into a coupled integrated assessment model. This has
enabled researchers to generate scientific results for two journal papers using CIAS and to
demonstrate the interoperability of CIAS between two institutions in different countries.
Relevance to Tyndall Centre research strategy & overall Centre objectives

The softIAM project enables the operation of the CIAS model, whose creation is the main
goal of the flagship project. The flagship project incorporates also the thinking behind the
scientific coupling of the modules, and the use of the CIAS model to produce policy-relevant
results. The softIAM project is also dependent on the Tyndall projects which deliver some of the
CIAS model components, for example, the economics module E3MG (IT1.19) and the
intermediate complexity climate module BCM GOLDSTEIN (IT1.31). CIAS has now
produced intial results showing that stabilisation targets of 450 to 550 ppm CO2 can be reached
with small percentages of GDP growth by 2100. The Tyndall flagship project has engaged
successfully with DEFRA Global Atmosphere Division as a stakeholder. The softIAM project
has, therefore, been instrumental in (a) the success of the flagship project as a whole, through the
production of an integrated model and through the application of the model to address questions
of interest to key stakeholders. It has, therefore, (b) been key in helping the Centre achieve one
of its aims: to research, assess and communicate from a trans-disciplinary perspective the options
to mitigate climate change. It thus considers the achievability of long-term strategic objectives of
international climate policy (see http://tyndall.e-
collaboration.co.uk/research/research_strategy_short.pdf). The groundwork has also been laid
for CIAS to be used to consider the necessities to adapt to climate change and to integrate the
resulting insights into the context of sustainable development.
Potential for further work

In phase 2 of the Tyndall Centre, CIAS will need to grow beyond the linear scenario analysis
which is its current capability, so that it can support the analysis of feedbacks and complex
interactions to take full advantage of the “integrated assessment” process. To allow these more
complex interactions the BFG coupling system needs to be extended to support the
implementation of more complex control flow in the execution of modules in a coupled model.
The extension of CIAS to enable interaction with other institutions and other coupling initiatives,
such as the National Environment Assessment Agency in the Netherlands, the PRISM project, the
Genie project, and others, will also require the BFG to be extended to support new modelling
languages and new coupling frameworks (for example, to interoperate with PRISM-compliant
modules). Also, the BFG single model interface will be extended (beyond the current ‘put’ and
‘get’ model used to exchange coupling data between modules) to support the range of different
mechanisms used by modules that exist in the community. Continued operation of CIAS requires
ongoing updating of the softIAM software and portal to match the growing array of component
modules. Necessary future work also includes ongoing maintenance and user support, together
with the management of upgrades as new software packages are released commercially. Finally,
as the CIAS system matures it will be able to begin tackling issues such as: interoperability
between modules written for other frameworks, how to support a restart mechanism, the inclusion
of modules which exploit parallelism in their execution, the ability to include data
transformations in exchanges between modules, the (on-line) visualisation of scientific results
and, finally, the computational efficiency of the coupled model, particularly when deployed in
more dynamic computational environments, such as the Grid.
Communication highlights including major publications and outputs

Academic Papers
• R.W. Ford and G.D. Riley, Towards the Flexible Composition and Deployment of
Coupled Models. In proc. Tenth ECMWF Workshop on the Use of High Performance
Computing in Meteorology; Realizing TeraComputing. ECMWF, Reading, England, 4-8
November 2002. World Scientific, pp. 189--195, 2003. ISBN: 981-238-376-X
• Ford, R. W., Riley, G. D., Bane, M. K., Armstrong, C. W. and Freeman, T. L. (2005)
GCF: a General Coupling Framework , Concurrency and Computation: Practice and
Experience, to appear (2005).
• Warren, R., Bane, M., Barker, T., Barton, C., Ford, R., Kohler, J., Mitchell, T., Pan,
H., Raper, S, Riley, G., de la Nava Santos, S., Winne, S., and Anderson, D. Development
of the Community Integrated Assesssment System (CIAS), a multi-institutional modular
integrated assessment approach for modelling climate change, and of SoftIAM, its
supporting software submitted to Environmental Modelling & Software.
Related Research
The success of the softIAM project has influenced UEA’s and Manchester’s ability to win further
projects (and to obtain continuation funding). Two such projects are:
• IntBioSim: Integrated Biological Simulation, led by Prof. Mark Sansom at Oxford. Multi-
level modelling of biological systems from the atomistic to the continuum (i.e. quantum
mechanical models coupled to molecular dynamics models, coupled to computational
fluid dynamics models)
• GENIEfy: Earth System Modelling, led by Tim Lenton at UEA (Tyndall).
The experience in softIAM has also influenced the work that has been undertaken by the CNC in
the Met Office’s FLUME project which is developing a new, flexible, software infrastructure for
the Unified Model (UM).
Web-sites
http://www.cs.manchester.ac.uk/cnc/projects/fca
http://www.cs.manchester.ac.uk/cnc/projects/bfg
http://www.cs.manchester.ac.uk/cnc/projects/softiam
Dissemination Demonstration of CIAS in operation at international integrated assessment

workshop held by FEEM, Venice, Italy, 2003.
TECHNICAL REPORT
Introduction
Concern about the serious impacts of climate change has been paralleled by a concern
that mitigation would be economically damaging. Studies have therefore begun (for
example Richels & Edmonds, 1995, Rotmans, 1990, Rotmans, Hulme & Downing, 1994,
Schneider & Toth, 2003) to (1) analyse different scenarios for emissions between 2000
and 2100, in terms of their environmental consequences (2) analyse the costs of
stabilisation of greenhouse gas concentrations in the atmosphere (3) analyse the impacts
of climate change and hence the benefits of climate change mitigation (for example Parry
et al., 2001). Such study of mitigation and adaptation requires an interdisciplinary
approach, so integrated assessment (IA) models of climate change have been assembled
(Alcamo, 1984, Dowlatabadi, 1995, Kainuma et al., 2003, Matsuoka et al., 1995,
Morgan and Dowlatabadi, 1996, Plambeck et al., 1997, Prinn et al., 1999, Rotmans,
1990, Rotmans et al., 1994). Most of the models are built at a single institution, which
inevitably cannot address all the disciplines of relevance, are consequently rooted in
particular scientific paradigms, assumptions or sets of beliefs, and are inflexible in
structure and design, so that mismatches between modelling capability and evolving
policy requirements are difficult to eliminate. Further, the policy maker may also
become bewildered by a wide array of somewhat different modelling outputs from
different integrated assessment models built at different institutions, detailing contrasting
estimates of the costs and benefits of alternative mitigation policies. To overcome these
drawbacks and obstacles the Tyndall Centre’s theme 1 flagship project, a Community
Integrated Assessment System (CIAS), has been set up to promote flexibility, robustness
studies and multi-institution collaboration in integrated assessment. The design
principles of CIAS are that:
• The system is flexible and multi-modular to allow a range of policy questions to
be addressed, thus facilitating iterative interaction with stakeholders.
• The system is distributed, that is deployed across a wide range of institutions
within Europe, allowing the system to benefit from the best available international
expertise which it integrates into a single modelling framework available to all
participants
• The system can take advantage of (but is not limited to) state of the art Grid
technologies (Foster et al., 2001) which allow models to communicate with each
other remotely regardless of operating system or computer language.
• The system is jointly owned by a community of institutions which contribute
individual models or the underpinning software. The system’s name directly
reflects this community approach.
• The system addresses the global climate policy problem, taking into account
issues of sustainable development where appropriate; and its design is, and will
continue to be, guided by the needs of the user/stakeholder community as well as
by modellers.
A principal advantage of the system is that it will allow the composition of many
individual model combinations, allowing the robustness of integrated modelling results to
the use of different models to be examined. This will be particularly important when (i)
comparing the use of individual modules of different levels of complexity and detail (ii)
comparing the use of individual modules from different institutions which have similar
complexity but are based on different modelling paradigms or value judgements
originating from the different institutions. In addition, a full uncertainty analysis
technique can be applied to the system holistically. Thus for each policy question
demanded of CIAS:
• the scientist can:
9 understand the degree to which increasing complexity of component
models enhances understanding or increases/decreases uncertainty
9 understand the robustness of results to paradigm shifts
• the policy maker can receive a clear picture of:
9 the consistency or otherwise of integrated modelling results
9 the degree to which model output is dependent upon the value judgements
lying behind modelling paradigms
In order to deliver the above requirements of a flexible coupled integrated

assessment model between a number of institutions using different computer platforms a
sophisticated state of the art technology is required. This technology was provided to
CIAS through the softIAM project upon which the rest of this document reports.
The flexible coupling capability is provided by an application of the Bespoke
Framework Generator described in section ‘The Bespoke Framework Generator’. In
addition, the user of CIAS must be able to determine the particular CIAS coupled model
they wish to use and receive a (distributed) implementation of the model for execution.
This facility is provided by the SoftIAM framework, which is largely supported by the
bespoke framework generator.
Main project deliverable:

SoftIAM, the CIAS software infrastructure
The software infrastructure SoftIAM was developed to implement CIAS. This
implementation has been thoroughly tested with a variety of coupled models. This
implementation is the main deliverable of the softIAM project.
The flexibility of the system means that several different coupled integrated models
(all of which are CIAS) exist. This section describes how SoftIAM is used to assemble a
particular, user selected, coupled integrated CIAS model from a series of component code
modules and execute it 1 to produce outputs from the integrated model.
Note that the term module will be used to refer to an individual piece of code which
can be combined with other modules to form a coupled model. The term model refers to
the more abstract scientific computation which may be implemented by a module. An
overview of the SoftIAM infrastructure for CIAS is given in Figure 1.
At the heart of SoftIAM is the Bespoke Framework Generator (BFG), a framework
code generation system which provides flexibility in the composition of individual
modules to form various alternative coupled models (i.e. integrated assessment models)
and flexibility in their deployment onto the available software and hardware resources.
BFG is key to satisfying the design principles of CIAS (previously described), and is also
an important component of SoftIAM; it is discussed in more detail in the following
section. SoftIAM supports the following user-oriented activities required to run the CIAS
coupled models: (The technology supporting these activities is also described in more
detail in the following section.)
• User interaction with the system through a graphical interface, called the
SoftIAM portal, located on one of the machines in a participating institution
(Figure 1). We will refer to this as the “SoftIAM portal machine”. SoftIAM
simplifies the process of specifying a coupled model, running the coupled
model and viewing the results.
1
Prior to the operation of SoftIAM the scientific validity of the coupling between the modules to make an
integrated model is ensured by participating scientists. SoftIAM is not used to create integrated assessment
modules that have not been scientifically validated.
SoftIAM
Infrastructure
BFG
Framework
code
generation
SoftIAM
Portal Build/Run
control
File control:
input data/
code/results
staging etc.
Distributed computing resources (computers at various

institutions)
Module DCD metadata and code (source and/or binary)
Figure1: SoftIAM infrastructure
• The specification (and in some cases the setting) of appropriate individual
module input data for a particular run of a coupled model via the Portal.
• The ability to set module parameters via the Portal. Thus SoftIAM configures
individual modules where appropriate.
• The staging of module input data, module output data and module code. As
CIAS is a distributed system, SoftIAM ensures that input data is transferred to
the appropriate computational resources on which they are to be run (if data is
not already in the required place). SoftIAM also transfers the required output
from the run of the coupled model back to the user from the potentially (and
typically) remote computational resources. Note, the module source code must
be located on the same machine on
which the executable for that module is to be built and run unless
module codes are provided as binary libraries or cross-compilation is possible.
• The building of the coupled model. Again, as CIAS is a distributed system the
“wrapper” (or framework) code generated by the BFG system needs to be
compiled and linked with the module codes on the remote computational
resources.
• The invocation of the coupled model. As the coupled model may be distributed
over a number of computational resources the running of the generated
executables is coordinated in an appropriate manner by softIAM.
Software Technologies used in SoftIAM

This section describes in further detail the technologies which underpin the
implementation of the SoftIAM infrastructure used in CIAS.
The Bespoke Framework Generator
The Centre for Novel Computing (CNC) in the School of Computer
Science at the University of Manchester, UK, had developed a basic methodology to
support the flexible composition and deployment of individual models into coupled
models. This approach is called the Flexible Coupling Approach (FCA)
(http://www.cs.manchester.ac.uk/cnc/projects/fca). For application in softIAM, this
basic methodology required considerable further development and modification. This
section describes how the fully developed FCA is used within softIAM. The next section
describes the work which was carried out to fully develop the FCA for use in CIAS under
the softIAM project.
To create instances of a coupled integrated model within CIAS, the scientist must
first deduce the flows of information required to couple the component modules. Having
done this, use of FCA requires the construction of XML files which give a description of
the (data) interface of each module which is to be composed with other modules in a
coupled integrated model. The interface prescribes the data which a module can provide
to other modules and the data which it needs from other modules in order for it to
execute. The interface is used during the composition of individual modules into a
coupled model. The composition is performed at an abstract level, independent of the
implementation details of particular modules (application codes) which satisfy the
interfaces. At this level, a module may be thought of as being implemented by a code
module which contains code simulating only the internal science of the module. That is,
the implementation of a module is free from details of how the module is to be called in a
particular coupled model (i.e. no control code is provided; the implementation may be
thought of as a Fortran or C subroutine, for example, which is to be called from an, as
yet, unspecified main program code) and there is no specification regarding the
mechanism the modules will use to exchange coupling data (as specified in their
interfaces). Details of how the modules are to behave in the coupled model are, however,
completely specified at the end of the composition process, by which time all connections
between modules are known. In particular the timestep values of individual modules are
known from their description (so called transformer models may have to be included in
the composition to match the input and output rates of data exchanged between models –
see Section ‘Details of the Bespoke Framework Generator’). With the addition of
information about which modules are to run first in the coupled model, the behaviour of
the coupled model is thus completely specified. These issues are discussed at greater
length later in Section ‘Details of the Bespoke Framework Generator’.
In FCA, the processes of describing module interfaces and composing modules
together to form a coupled model are separated from the concerns of deployment issues,
such as how to allocate models to executables and where (on which computing resources)
to run the resulting executables. The overall process is termed DCD - for Description,
Composition and Deployment.
Associated with this Description, Composition and Deployment (DCD) approach is
metadata which captures the relevant information from each of the three phases. Given
this metadata, a code generation/configuration system can create appropriate
code/files/scripts to couple the individual modules using the most appropriate coupling
framework or communication system in the specified manner. Thus, the BFG produces a
bespoke (set of) framework code appropriate to the coupled model specified by the user.
Details of the Bespoke Framework Generator
The Bespoke Framework Generator (BFG) is an implementation of the FCA
methodology for time-stepping coupled models. The BFG is available for download from
http://www.cs.manchester.ac.uk/cnc/projects/bfg and further details may be found in Ford
et al. (in press). In the BFG, metadata is written in XML [W3C. Extensible markup
language (XML) 1.0 (second edition) W3C Recommendation, October 2000] and is
structured in the "describe-compose-deploy" hierarchy mentioned previously to reflect

the separate tasks of describing the scientific interface of a model, composing a coupled
model from several individual modules, and deploying the coupled model onto the
appropriate hardware and software resources. The description metadata, which details a
module’s interface, is at a high level, suitable for climate scientists, and includes
information such as which fields (e.g. temperature, in degrees Kelvin, or Carbon dioxide
concentration, in parts per million by volume) the module requires (inputs) and which it
can provide (potential outputs). The composition metadata describes how the individual
modules are to be connected - which output fields from one module are connected to
which input fields of one or more other modules. The description metadata includes
information about the time scale of an iteration of a module and the composition
metadata captures the total run duration of the coupled model. The BFG uses this data
during its code generation phase to create the coupled model according to the required
scientific specification. Individual modules that are to be coupled together will typically
operate at different temporal and spatial scales. Rather than requiring the user to modify
individual codes to make them compatible, the BFG approach is for the user to provide,
possibly from a library, appropriate transformation modules which, for example, may
accumulate input from a short time scale module and output the latest data to a longer
time scale module. These transformations act as the “glue” between modules. The
advantage of this approach is that the scientific modules do not need to be modified from
one composition to another. Note, the BFG treats transformations in the same manner as
it treats individual modules.
The description and composition metadata therefore contain all the information
required to specify a coupled model reflecting the required science of the coupled
application. To ensure flexibility, the BFG also requires metadata about how the coupled
model is to be deployed. This information is used to construct the appropriate
communications code. For example, running a coupled model over different institutions,
as required for CIAS, can be performed using the Grid (Foster et al.2001) and the BFG
will generate the required mapping of modules to executables and the appropriate MPI
communication code, for example, to support deployment on the Grid (using MPICH-G2
for the Grid middleware Globus (Foster et al.1997)).
A module must obey a small set of rules for it to be compliant with the version of
BFG used in the SoftIAM infrastructure: it must be a subroutine or function and use
put(outputData,id) to provide the variable outputData and
get(inputData,id) to receive data into the variable inputData. The BFG has
taken the decision to limit variable support to scalar and array variables (whose size and
type is encapsulated in the description metadata 2 ). This approach was taken for two
reasons. First, most scientific computation is array-based and, second, all languages
support scalar and array types. The id variable is also used in the description metadata to
label the corresponding field. The id variable is the link between the metadata and the
module source codes.
The separation of metadata from a module’s source code and the ability to use the
module code unchanged in any composition and deployment allows high levels of
flexibility and reusability. The composition and deployment of a coupled model can be
performed with just single module object code (for the correct operating system) and
these can be altered without having to re-compile the module’s source code.
2
In order to cater for different memory storage sizes for variables (e.g. on different operating systems) it is
also necessary to capture low-level details such as the size of basic types in the metadata.
The current implementation of the BFG uses XML Schema [W3C. XML schema
version 1.0. W3C Recommendation, May 2001] to define allowable and required
contents of the user supplied XML documents 3 and uses XSLT [W3C. XSL
transformations (XSLT) version 1.0. W3C Recommendation, November 1999] to process
these to generate the required framework code. The BFG software consists of a
constraints engine (to ensure all user supplied XML documents are valid) and a code
generation engine (to generate the framework code in the user specified programming
language). The BFG supports models written in Fortran or C (depending on the chosen
deployment target), and the supported targets are:
(i) sequential, which generates a single executable coupled model with modules running
in sequence, with communication via shared buffers. This deployment requires no
software other than a Fortran compiler.
(ii) single machine MPI, which generates a single (SPMD-style) executable coupled
model,
(iii) distributed MPI, which allows an arbitrary mapping of modules to executables and
can be used for deployment on the Grid.
(iv) TDT (a communication library from PIK, http://www.pik-potsdam.de/software/tdt)
using sockets.
(v) TDT using SSH, this allows communication through firewalls.
(vi) Oasis3 coupler, this is a proof of concept implementation which uses Fortran 90
modules
3
See http://www.cs.manchester.ac.uk/cnc/schema/bfg.
(vii) Web Services, which uses Tomcat (http://jakarta.apache.org/tomcat/) and Axis
(http://ws.apache.org/axis/) and generates webservices that communicate with each other
(using HTTP and SOAP) and call the underlying model code.
Further, investigations have shown that it is possible to extend BFG support (in a
limited manner) to include modules which are written directly using TDT, thus opening
up the possibilities of inter-framework coupling. In summary, the benefits of using BFG
include:
(i) individual modules only need to be described once. Once a module conforms to the
system it may be used without change in any composition or deployment.
(ii) scientific code is separated from coupling code. This helps scientists to concentrate on
science rather than computer science.
(iii) it is simple to create new compositions and to change from one deployment to
another. This is all specified in xml and can be performed in a graphical environment, if
needed.
(iv) it is possible to choose different coupling frameworks/communication systems with
no change to individual modules or model compositions.
(v) the system is future proof, in that the development of new frameworks, or changes to
existing frameworks, will not affect individual modules or their compositions. For
example the Grid technologies have evolved and are continuing to evolve. The BFG
approach isolates the user from changes due to technological advancement.

(vi) the system supports interoperability between coupling frameworks. There are a
number of coupling frameworks and similar technologies being developed. The BFG
approach promises the ability to allow modules to be made available (exported) to
different frameworks. Conversely, to a limited extent, it allows for modules written to
conform to other frameworks to be made available (imported) to BFG.
(vii) the BFG metadata will be used in the Met Office’s next generation software system
(being developed in their Flume project). This means that Met Office models will be able
to be used within the system with relative ease.
The CIAS system design requirements relevant to module coupling (see Section
‘The Community Integrated Assessment System (CIAS) Approach’) are first, the ability
to flexibly compose different modules and model scenarios, secondly, to support models
which are distributed across institutions, including Grid deployment and thirdly, to be
able to incorporate existing modules written in different languages into the system. The
BFG was chosen as the coupling technology for the SoftIAM infrastructure because it
meets these requirements as well as providing a number of other benefits which have
been outlined in this section.
How BFG was developed under softIAM
In the first instance, a Globus MPI target communication infrastructure was added to
BFG in order to support the execution of models across multiple institutions using the
Grid. This target was chosen as, at the time, the use of Globus was considered (by the
general community) to be the most promising technology to support such distributed
computation. The feasibility of this approach was proved with a test case running a
coupled simulation with some CIAS modules running at UEA and others at Manchester.
Although this approach was successful, the softIAM team considered Globus to be a
rather heavyweight solution for CIAS – for example, it additionally required certain
modifications to firewalls in order to run. A more lightweight, ‘distributed MPI’
approach, using ssh to avoid firewall issues, was considered to be more suitable. This
new (distributed MPI) approach required no change to the BFG system as the Globus
MPI target produced the required distributed MPI code (the Globus specific configuration
file was simply ignored).
In order to help reduce bugs in the softIAM system, and to improve the usability of BFG,
a validation phase was added to the BFG software. This phase checks that the xml input,
provided by the user, into the system is valid (i.e. that it conforms to the relevant schema)
and therefore helps check for errors in the input data provided to BFG.
As new modules and coupling scenarios were added to the softIAM system a new
requirement emerged which was to be able to run some modules on machines running a
Windows operating system and others modules run on machines running Linux within
the same coupled model. Unfortunately, at the time there was no implementation of MPI
available which supported this requirement. It should be noted that this was a limitation
of the MPI implementations, not BFG.
It was therefore decided to implement a Web Services-based solution as a BFG target.
This solution was chosen as Web Services were known to support communication
between institutions (across multiple administrative domains, as well as communication
between machines running different operating systems. This approach was successful and
was integrated into the SoftIAM system. SoftIAM is therefore able to choose between
these two communication targets (and any other previously existing targets such as
‘sequential’).
However, in the meantime, a new implementation of MPI became available (MPICH2)
which allowed direct MPI communications between machines running windows and
machines running Linux. This solution was (and still is) preferred for softIAM as MPI
communication is much more efficient than SOAP-based communication mechanism
supported by Web services.
As the project progressed, the Tyndall Centre became interested in using modules
developed by the Potsdam Institute in Germany (PIK) within CIAS. PIK already had a set
of modules which used their “home grown” communication framework called TDT. The
CNC had lengthy and productive discussions with PIK exploring how CIAS and PIK
models might interoperate. The CNC’s preferred approach would be for PIK modules to
be written to conform to the BFG single module rules and for BFG to have TDT
implemented as a BFG target. This approach would allow PIK modules to use any of the
available BFG targets, including TDT. To demonstrate the feasibility of this approach a
TDT BFG target was implemented. In practice, the use of BFG with TDT as a target
allows (with some limitations) modules written directly in TDT to interoperate with BFG
modules. Therefore it is possible to use CIAS modules and TDT modules within a
coupled model in softIAM - if TDT is used as the target communication mechanism. This
approach was successfully tested by running combinations of BFG- and TDT-compliant
modules in coupled configurations running between PIK, Manchester and UEA.
Finally, UEA identified the fact that future coupling scenarios would require more
complex control flow than the BFG system can support – the BFG in use in softIAM only
supports relatively simple time stepping models. The possibility of extending BFG to
support future complex control flow requirements was evaluated and prototype solutions
were tested. The results of these tests will help direct the future evolution of BFG2, the
next generation of the CNC’s coupling software.
Other SoftIAM Technologies
SoftIAM can support modules hosted on any machine architecture and
operating system combinations which also host an installation of the
SoftIAM software, a Secure Shell (SSH) server (http://www.ietf.org/html.charters/secsh-
charter.html), a Java 2 Standard Edition (J2SE) (http://java.sun.com) and an installation
of MPICH 2 (http://www.unix.mcs.anl.gov/mpi/mpich2).
J2SE is used by the internal scripting engine and data
visualization of the SoftIAM software. The SSH server allows the
scripting engine of the SoftIAM software to securely stage module
configuration and input data, build the model’s source code, if necessary, start modules
running, and return the results of integrated model runs to a remote client. MPICH 2 is
used by the BFG component of the SoftIAM software for passing data between the
various modules which comprise the integrated model. MPICH 2 is also the underlying
mechanism for starting and running the generated coupled model. However, SoftIAM
hides this from the end user in order to provide a consistent interface and remove the
necessity for remote clients to have an installation of MPICH 2. An integrated model as
a whole can be controlled from a remote client. This client only needs an installation of
the SoftIAM software and a J2SE. SoftIAM requires that the build, deploy and run
requirements for individual modules and the overall coupled model are described in XML
in a SoftIAM conformant format. For example, the following XML defines a module
comprising three source files and how to compile them:
<src>
<fileList>
<file>ModuleIclipsIm.f90</file>
<file>LoaderIclipsIm.f90</file>
<file>ReadDataIclipsIm.f90</file>
</fileList>
</src>
<language>
<target>
<ext>.o</ext>
</target>
<compiler>
<name>ifc</name>
<args>-c @SRC_FILES@</args>
</compiler>
<linker>
<name>ar</name>
<args>-rsv libiclips-im.a @OBJ_FILES@</args>
</linker>
</language>
The following piece of XML defines how to generate BFG components for the
compiled module and how to execute this part of the coupled model. In this case, BFG is
using MPI as the communication protocol:
<BFG>
<mpi>
<type>fortran</type>
<args>-n 1 -host beo1.uea.ac.uk -dir @.@ iclips-im.exe</args>
<implementation>
<name>ModuleIclipsIm</name>
</implementation>
<language>
<target>
<ext>.o</ext>
</target>
<compiler>
<name>mpif90</name>
</compiler>
<linker>
<name>mpif90</name>
<args>-oiclips-im.exe @OBJ_FILES@ -liclips-im
@LIBRARY_PATHS@</args>
<libraryPaths>
<directive>-L</directive>
<dirList>
<dir>@.@</dir>
</dirList>
</libraryPaths>
</linker>
</language>
</mpi>
</BFG>
On pages 55 to 56 we show how SoftIAM coupling XML then references 3 separate
modules and allows SoftIAM to use this meta-data to process each module and then run
the final coupled model.

SoftIAM is implemented as a thin wrapper around ANT (http://ant.apache.org)
which uses the information provided in XML files in order to carry out the build, stage
and run tasks. The system takes advantage of ANT secure shell tasks to carry out
operations on remote machines.
SoftIAM is a command line tool but a web based interface called the SoftIAM
Portal has also been developed. The SoftIAM Portal is a STRUTS-based
(http://struts.apache.org) Web application which provides a graphical user interface for
carrying out coupled modelling. For any particular coupled model user interface
components are dynamically generated for the various modules which form the coupled
model. The information required to generate these user interface components is provided
by the XML files associated with the individual modules. For instance, the following
piece of XML allows the SoftIAM Portal to generate an HTML <select> component with
two <option> elements:
<parameterList>
<parameter>
<name>Emission Scenarios</name>
<type>java.lang.String</type>
<choiceList>
<choice>
<name>Type 1 Scenarios</name>
<value>type1.ems</value>
</choice>
<choice>
<name>Type 2 Scenarios</name>
</choice>
</choiceList>
<regex>^./(.*)$</regex>
<filename>esm.properties</filename>
<displayOrder>1</displayOrder>
</parameter>
</parameterList>
The <regex> tag contains a regular expression which the portal will use to update
the file referred to in the <filename> tag. The <type> tag is used to ensure that the data
submitted by the portal user conforms to certain rules, in this case that a
"java.lang.String" type can be constructed from it. The file referred to in the <filename>
tag is expected to be a configuration file which is specific to an individual module within
the coupled model. Similarly, the following XML allows the SoftIAM Portal to generate
a HTML text <input> component:
<parameterList>
<parameter>
<name>Climate Sensitivity (Celsius - delta)</name>
<type>java.math.BigDecimal</type>
<regex>^(?:.*\n){1}^[ ]*([-|+]?\d*.?\d*)[ ]*\*[
]*SENSITIVITY.*$</regex>
<filename>scm.properties</filename>
</parameter>
</parameterList>
<resultList>
<result>
<filename>results.out</filename>
</result>
</resultList>
Finally, the piece of XML enclosed within the <resultList> tags allows the SoftIAM
Portal to generate module-specific HTML which allows a user to download the result
files associated with the module. In this specific case, the module produces a file called
"results.out" which the portal user can download by clicking on a (generated) button.
The implementation of CIAS
CIAS is implemented by SoftIAM which contains different technical layers
designed to execute the available couplings:
• The lower layer is BFG that needs some XML files defining the different modules
and how we are coupling them together. If the user wants to execute a coupling,
first (s)he must compile the modules linking to BFG libraries, write the
configuration files for each module, copy each one at the correct machine,
generate a command to execute the coupling and finally after the execution get
the results from the machines of the cluster.
• The middle layer is the SoftIAM command. At this level, we have some extra xml
files as well as the BFG xml files. This new information automatizes some of the
tasks that the user has to do working with the first layer only. At this layer, the
system compiles the modules of the coupling, uploads and downloads the
configuration files to the correct machine, executes the coupling and downloads
the results. The user only have to know how to configure the different modules,
the syntax of SoftIAM command and the sequence of commands to execute.
• The higher layer provides a graphical interface, the SoftIAM portal, which hides
previous layers. At this level, the user does not know how the coupling is
executed, the system allow him to deploy, configure, run and download results
without knowing any detail of SoftIAM infrastructure. Now, the user only has to
provide the desired values for the parameters to configure and interpret the
results. In future versions of SoftIAM, a result analysis tool will be included at
this layer to help with the result interpretation.
The following describes a generic sequence of an execution of a coupling from the
portal:
After log-in, the user is presented with a series of use-case diagrams showing how
the modules are coupled together, and information about the modules and their inputs and
outputs. When the user selects a particular coupling the system shows a detailed
description of each module in it, and the possibility to deploy or undeploy this coupling.
If the user deploys a coupling, SoftIAM then:
(i) Compiles each module in the machine where the module is being executed.
(ii) Generates the general coupling framework components in each machine
where a module is being executed.
(iii) Downloads for all the modules the description XML files, the configuration
files and log files of the compilation, to the SoftIAM portal machine. (See
Figure 1).
Next the user is given the opportunity to configure the modules. This involves
selection of key parameters, for example in the case of ECON, the magnitude and years
of application of Carbon taxes; in the case of ESM, the emissions of greenhouse gases;
and in the case of SCM, the climate sensitivity and ocean diffusivity. A default case
applies if the user does not configure the modules.

Following configuration the user can run the coupling shown in the use case
diagram that (s)he selected. SoftIAM then uploads the configuration files to the
corresponding machines and starts to execute the coupling. Once execution is complete
results are sent to output files in the SoftIAM portal machine which may be displayed on
the screen or saved to the hard drive by the user. The interface is currently being
extended to include graphical display of outputs.
If the user decides to undeploy the coupling, the system removes all the
executables, configuration and results of this coupling in the user account.
The metadata contained in all the SoftIAM and BFG XML files leads the behaviour
of the system. The following chapters describe all those files and the information
provided by them.
BFG XML files
There are some XML files in BFG to define the modules and the couplings, the
followings are the most important:
• http://www.cs.man.ac.uk/cnc/schema/gcf/define.xsd defines the schema of an
interface that is implemented by a module. The compulsory “root” element (ie
node of the schema tree) is defineInterface which consists of four child elements
which must be given and in the order name (the name of the interface), version
(the version of the interface), behaviour and one or more fields elements. The
behaviour element consists of, in any order, a type and a compatibility element.
These will be used in future versions of BFG to ensure the suitability of an
interface within a coupled model. Each field element consists of a name, id and
direction element, in that order. Studying the schema itself will show that id has to
be an integer and direction has to be “in” or “out”. Thus, this data contains the
information about which fields are required and provided by this interface. (See
figure 2).
• http://www.cs.man.ac.uk/cnc/schema/gcf/source.xsd gives a description of a
module's source details. This includes information about the author but also the
programming, language and what platforms the module has run on. This latter
information will be used during the deployment stage to ensure a module is only
run on a platform for which it is suited. The source schema also includes
information about each field, whether is a scalar or an array, its dimension and the
type of variable. This information is used by BFG to construct the correct
implementation of the put() and get() subprogram units. (See figure 3 and 4).
• http://www.cs.man.ac.uk/cnc/schema/gcf/executable.xsd is a description of the
execution details of the module. The user has to provide, for a given platform, the
size in bytes or bits of each datatype and the location of the code live. BFG
originated with, but is not limited to, coupled models comprising a selection of
time stepping modules. Therefore, for each module, the user also has to provide
the module's simulation timestep. BFG will use this information, together with the
overall coupled model's simulation time (determined in the composition XML
document), to auto-generate the control loops to ensure each module is called the
correct number of times. (See figure 5)
• http://www.cs.man.ac.uk/cnc/schema/gcf/compose.xsd document sets the coupled
model's overall simulation run time (runDuration) and the connections between
modules by the connect element(s). For each connect element, the module which
provides data (providesModel) and that which requires this data (requiresModel)
are defined. For each field coupling, the user also has to define the provides/id
and the requires/id, where the field relating to the value of id is given from the
fields/id element in the source schema. (See figure 6).
name
version
1..∞
type
defineInterface behaviour
compatibility
name
id
fields
1..∞ direction
Figure 2: define.xsd
name
version
author
1..∞
group
company
source
language
machine
model
runsOn
1..∞ os
compiler
1..∞
fields
1..∞
Figure 3: source.xsd. Top level details
id
index
direction
size
fieldunits
fields
array dimension dimensionunits
1..∞
vartype
source
type
scalar
source
Figure 4: source.xsd. Fields details

• http://www.cs.man.ac.uk/cnc/schema/gcf/deploy.xsd document describes how and
where to deploy units on to hardware using the deploymentUnit element(s) and
which framework to use. The framework is a triplet of a fabric, language (which
determines the programming language of the auto-generated controller and put()
and get() routines, and comms which defines the underlying implementation of
the put() and get() routines. (See figure 7).
• http://www.cs.man.ac.uk/cnc/schema/gcf/coupled.xsd is used as a "root"
document which contains the name of all the other XML documents, and it is this
that is passed as a parameter to BFG. (See figure 8).
name
version value
timestep units
executable
machineName
location directory
name
type
datasize value
1..∞
size
units
Figure 5: executable.xsd
value
runDuration
units
compose name
providesModel
version
connect requiresModel
0..∞
provides id
fieldConnect
0..∞
requires id
Figure 6: compose.xsd
machineName
name
deploimentUnit
1..∞ model
1..∞
version
deploy
fabric
framework
language
comms
Figure 7: deploy.xsd
interface
component
1..∞ source
model
coupled executable
compose
run
deploy
run
Figure 8: coupled.xsd
SoftIAM XML files
SoftIAM needs extra information to carry out all the tasks. That information is
contained two different XML files, one for the module and other for the coupling. Both
of them contain useful information for the SoftIAM command and portal.
Modules XML file
The XML schema for Softiam.xml file in a module is module.xsd (See Figures 9,
10, 11 and 12). This schema defines external datafile, configuration files and result files
of the module as well as how to compile and execute the module. At this file, we also
find information of parameters configurable from the portal. The following list
summarizes all the options for this file:
• module: This element is the root element at module.xsd and encapsulates all the
possible elements of the schema (name, description, configurationDescription,

image, platformList, dataList, configList, resultList, build, actionList, src,
language, bfg, parameterList, parameterArrayList).
• name: Is the name that will appear for this module at the portal.
• description: Is a text describing the module. As the name, it appears at the portal
to describe the module.
• configurationDescription: This text describes how to configure the parameters of
the module. The text appears at the portal when the user proceeds to configure the
module.
• image: This field indicates the image that describes the workflow of the module.
It is showed at the web portal when a user configures the module.
• platformList: This parameter contains a list of platform elements that contains the
platforms where the module can be executed. Those platforms are windows, unix,
aix, hpux, irix, linux, macosx and solaris.
• dataList: This parameter contains a list of data elements which represent external
data files that modules need to download before the execution. Each data element
contains the name of the file and the machine where the file is stored. If the file is
a zip file, it is decompressed by SoftIAM at the module deployment directory.
• configList: This parameter contains config elements that represent the
configuration files of the module. These files are internal to the module, so they
are in the jar file that contains the module. (See ‘SoftIAM structure’ section).
• resultList: Inside this element is a list of result elements. Each result element
represents result file of the module. SoftIAM command and portal allow to
download these files after an execution of a coupling.

name
description
configurationDescption
0..1
image
0..1
platformList platform file

1..∞
dataList data machine

0..1 1..∞
configList config filename

0..1 1..∞
resultList result filename

0..1 1..∞
module
build dist
0..1
actionList action
0..1 1..∞ clean
src fileList
0..1
file
0..∞
language
0..1
mpi
bfg
webservice
parameterList parameter
0..1 0..∞
parameterArrayList parameterArray
0..1 0..∞
Figure 9: module.xsd (I)

shell
script
dist 0..1 file
args
clean 0..1
shell
command
0..1
executeList execute
target ext
intermediate ext
0..1
name
language
compiler args
directive
includePaths
0..1
dirList dir
0..∞
name
linker args
directive
libraryPaths
0..1
dirList dir
0..∞
Figure 10: module.xsd (II)

type
args
mpi
implementation name
language
(See language reference at figure 10)
name
implementation
file
webservice
language
(See language reference at figure 10)
name
type
parameter readonly
0..1
downloadable
0..1
regex
filename name
displayOrder value
0..1
restrictionList restriction displayOrder

0..1 0..∞ 0..1
constrainedParameter
0..1
Figure 11: module.xsd (III)

name
constrainedParameter
value
name
type
parameterArray files
columns
readonly
0..1
regex
filename
displayOrder name
0..1
restrictionList restriction value

0..1 0..∞
displayOrder
0..1
Figure 12: module.xsd (IV)
• build: Here users can indicate an ant action script that should contain the targets
dist, clean. This action script is executed prior the user deploys (dist command) or
undeploys (clean command) a coupling. The target executed depends on the
action the user is doing.

• actionList: This parameter allows the user to define shell scripts to execute before
deploy or undeploy a coupling. Inside this tag can be actions that must contain a
dist or a clean element. This example shows how this element works:
<actionList>
<action>
<dist>
<script>
<shell>
<name>cmd</name>
<args>/c</args>
</shell>
<file>setup.bat</file>
<args>Module A</args>
</script>
<command>
<shell>
<name>cmd</name>
<args>/c</args>
</shell>
<executeList>
<execute>echo Module A dist action running</execute>
</executeList>
</command>
</dist>
</action>
<action>
<clean>
<command>
<shell>
<name>cmd</name>
<args>/c</args>
</shell>
<executeList>
<execute>echo Module A clean action running</execute>
<execute>echo Module A doing something else during the clean action</execute>
</executeList>
</command>
</clean>
</action>
</actionList>
This actionList contains two actions one to perform the deployment of the
coupling (dist) and another to undeploy the coupling (clean). To define the scripts
to execute the system provides two possibilities to use the element script or the
element command, both elements are very similar:

9 script: this one need to define a shell (in the example the shell is ‘cmd’
because is for a windows system, for a unix platform we can use ‘sh’) and
arguments for the shell (‘/c’ is needed for windows shell to indicate the
command that has to execute). After the definition of the shell, the user
must define the file that contain the script to execute (‘setup.bat’) and the
arguments we want to pass it (‘Module A’). So the final command
executed at the system is ‘cmd /c setup.bat Module A’.
9 command: The difference with the script element is that this one allows to
execute a sequence of commands. As for the script element the user must
define a shell and its arguments. After this an executionList is defined.
That list contains execution elements that are commands with their
arguments. In the example, the commands executed for the clean action
are first ‘cmd /c echo Module A clean action running’ and then ‘cmd /c
echo Module A doing something else during the clean action’.
• src: This element contains the list of source files of the module. This list is used to
compile the module.
• language: This element leads the compilation of the module, to perform this task
we must include some information inside this element: the target files extension
(for example, it could be .obj), the intermediate file extensions, the compiler and
arguments needed by the compiler, the liker and arguments needed by the linker.
This example explain almost all the options of this element:
<language>
<target>
<ext>.obj</ext>
</target>
<compiler>
<name>ifort</name>
<args>/nologo /c /iface:cref /iface:nomixed_str_len_arg @INCLUDE_PATHS@
@SRC_FILES@</args>
<includePaths>
<directive>/I</directive>
<dirList>
<dir>@MPICH2_HOME@\include</dir>
</dirList>
</includePaths>
</compiler>
<linker>
<name>link</name>
<args>/NOLOGO @LIBRARY_PATHS@ /OUT:dummy-a.exe @OBJ_FILES@ dummy-a.lib
fmpich2.lib</args>
<libraryPaths>
<directive>/LIBPATH:</directive>
<dirList>
<dir>@MPICH2_HOME@\lib</dir>
</dirList>
</libraryPaths>
</linker>
</language>
At the example the targets of the compiler are ‘obj’ files. ‘ifort’ is the copiler
used, the arguments for the compiler are indicated inside the compiler element,
exists the possibility to indicate the library paths for the compilation (we must
indicate the directive we will use at the compiler’s command to add the
directories where the libraries are) . To define the compiler command, we use the
variables @INCLUDE_PATHS@ that is generated using the includePaths
element, @SRC_FILES@ that is generated using src element (explained
previously) and @MPICH2_HOME@ (this is an external variable that shows the
directory where the system has installed MPICH2). The command generated to
compile the module is ‘ifort /nologo /c /iface:cref /iface:nomixed_str_len_arg
/I“C:/ProgramFiles/MPICH2/include” “soucefile1.f” “sourcefile2.f” …’. The
steps to define the linker are very similar, the only difference is that we use the
element librariePaths instead includePaths. The linker command generated at the

example is ‘link /NOLOGO /LIBPATH:“C:/ProgramFiles/MPICH2/include”
/OUT:dummy-a.exe “sourcefile1.obj” “sourcefile2.obj” … “dummy-a.lib”
“fmpich2.lib”’.
• bfg: This element contain all the information to allow a module to be coupled in
the model. The elements inside bfg tag could be mpi or webservice depending on
which communication framework we want to use. The way to define the process
of coupling is different for mpi and webservices. This is an example for mpi:
<bfg>
<mpi>
<args>-n 1 -host localhost -dir @.@ dummy-a.exe</args>
<implementation>
<name>ModuleDummyA</name>
</implementation>
<language>
<target>
<ext>.obj</ext>
</target>
<compiler>
<name>ifort</name>
<args>/nologo /c /iface:cref /iface:nomixed_str_len_arg @INCLUDE_PATHS@
@SRC_FILES@</args>
<includePaths>
<dirList>
<dir>@MPICH2_HOME@\include</dir>
</dirList>
</includePaths>
</compiler>
<linker>
<name>link</name>
<args>/NOLOGO @LIBRARY_PATHS@ /OUT:dummy-a.exe @OBJ_FILES@ dummy-
a.lib fmpich2.lib</args>
<libraryPaths>
<directive>/LIBPATH:</directive>
<dirList>
<dir>@MPICH2_HOME@\lib</dir>
</dirList>
</libraryPaths>
</linker>
</language>
</mpi>
</bfg>
The type element defines the language of bfg generated code (it must be fortran or
C). The args at this level are used for the mpiexec command, which is called
when the coupling is executed. The implementation element indicates the
function inside the source code of the module that starts the execution of the
module. It is required because bfg calls that function in the middleware code that
is generated. After all those elements there are a language element that works like
the element explained previously. The difference is that this one is to compile the
middleware source code and link it with the module and bfg libraries. In this case,
the variable @SRC_FILES@ contains the files generated by bfg for the
communication middleware.
Following there is an example of a module using webservices:
<bfg>
<webservice>
<implementation>
<name>@USERNAME@ModuleDummyA</name>
<file>ModuleDummyA.f90</file>
</implementation>
<language>
<target>
<ext>.obj</ext>
</target>
<compiler>
<name>cl</name>
<args>/c /D_SYMBOLCASE=UPPERCASE /D_NOAPPENDUNDERSCORE
@INCLUDE_PATHS@ @SRC_FILES@</args>
<includePaths>
<dirList>
<dir>@JAVA_HOME@\include</dir>
<dir>@JAVA_HOME@\include\win32</dir>
</dirList>
</includePaths>
</compiler>
<linker>
<name>link</name>
<args>/DLL /OUT:@LIBRARY_NAME@.dll @OBJ_FILES@ dummy-a.lib</args>
</linker>
</language>
</webservice>
</bfg>
In this case, the elements type and args disappear. The element implementation
includes more information than in mpi implementation: the name that is the
function that will be called by the implementation of the webservice, and the file
that indicates the name of the source file of the module that contains that function.
After those elements there is a language element with the same structure than in
mpi implementation (only change the compiler and linker used because we use
java to implement the webservice).
• parameterList: The purpose of this element is to allow the user to configure the
modules of a coupling from the graphical interface. The information provided at
the xml file is: The name of the parameter (this name is showed at the portal when
the user configures the parameters), the type of the parameter (it must be
java.lang.String or java.lang.BigDecimal), if the parameter is readonly, if the
parameter is downloadable (this option allow the user to download configurable
datafiles needed by the module), the regular expression that allow to find and
modify the value of the parameter in a file (the regular expression must contain
only one capturing group, see Java’s Patterns reference), the file that contains this
parameter, the order in the list of parameters, and restrictions for the parameter’s
values. The restrictions contain values for this parameter, but could contain values
for other parameters when we select a specific option for this parameter.
Following there is an example of a parameter with restricted values:
<parameter>
<name>Values</name>
<regex>^(.*)$</regex>
<filename>dummy-a.properties</filename>
<restrictionList>
<restriction>
<name>Type 1 Values</name>
</restriction>
<restriction>
</restriction>
</restrictionList>
</parameter>
This example shows a parameter called Values, which only can has the values
type1.ems (this value is written at the configuration file when the user select at the
web the option ‘Type 1 Values’) and type2.ems (this value is written at the
configuration file when the user select at the web the option ‘Type 2 Values’).
Following there is another example with restriction over other parameters:
<parameter>
<name>GCM Tuning</name>
<regex>^(?:.*\n){36}^[ ]*(.*)[ ]*\*[ ]*GCM.*$</regex>
<filename>MAGMOD.CFG</filename>
<restrictionList>
<restriction>
<name>Custom</name>
<value>Custom</value>
</restriction>
<restriction>
<name>GFDL</name>
<value>GFDL</value>
<constrainedParameterList>
<constrainedParameter>
<name>Measure of CO2 Doubling Forcing (W 1/m²)</name>
<value>5.352</value>
</constrainedParameter>
<name>Climate Sensitivity (°C) (0.5 - 5.5)</name>
<value>4.2</value>
<name>Mixed Layer Depth (m)</name>
<value>60</value>
</restriction>
<restriction>
<name>HadCM3</name>
<value>HadCM3</value>
<constrainedParameterList>
<name>Measure of CO2 Doubling Forcing (W 1/m²)</name>
<value>5.396</value>
<name>Climate Sensitivity (°C) (0.5 - 5.5)</name>
<value>3.0</value>
</restriction>
</restrictionList>
</parameter>
In this case, there is a parameter that only could get the values Custom,GFDL and
HadCM3, but depending on which one is selected other parameters could change
their values. When we select Custom no other parameters are modified (this
restriction hasn’t constrainedParameter), but when we select GDFL or HadCM3
other parameter get the value indicated at the constrainedParameter element. For
example, if we select HadCM3 the parameter ‘Measure of CO2 Doubling Forcing
(W 1/m²)’ takes the value 5.396 and the parameter ‘Climate Sensitivity
(°C) (0.5 - 5.5)’ takes the value 3.0, both parameters must be defined at the
parameterList element.
• parameterArrayList: This element represent a more specific parameter than
previous. This element is used to define a configurable array of values. The sub
elements inside it are the same than in the previous element with some
differences: this parameters can not be downloadable, the restrictions does not
allow constrainedParameters, there must be a element files and a element
columns, and the number of capturing groups at the regexp element must be
files*columns (see Java’s Patterns reference). This kind of elements is showed at
the portal as an array (files*columns) of text fields.

This is an example of a Softiam.xml file for module.xsd schema:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://namespaces.softiam.org/module
@LOCAL_SOFTIAM_HOME@/build/module.xsd"
xmlns="http://namespaces.softiam.org/module">






<name>Module Dummy A</name>
<description>A dummy module.</description>
<configurationDescription>Select from the drop down list.</configurationDescription>

<platformList>
<platform>unix</platform>
</platformList>



<configList>
<config>
</config>
</configList>



<build>build.xml</build>

<actionList>
<action>
<dist>
<script>
<shell>
<name>sh</name>
</shell>
<file>setup.sh</file>
<args>Module A</args>
</script>
<command>
<shell>
<name>sh</name>
</shell>
<executeList>
<execute>echo Module A dist action running</execute>
</executeList>
</command>
</dist>
</action>
<action>
<clean>
<command>
<shell>
<name>sh</name>
</shell>
<executeList>
<execute>echo Module A clean action running</execute>
<execute>echo Module A doing something else during the clean action</execute>
</executeList>
</command>
</clean>
</action>
</actionList>

<src>
<fileList>
<file>ModuleDummyA.f90</file>
<file>SourceDummyA.f90</file>
</fileList>
</src>

<language>
<target>
<ext>.o</ext>
</target>
<compiler>
<name>ifc</name>
</compiler>
<linker>
<name>ar</name>
<args>-rsv libdummy-a.a @OBJ_FILES@</args>
</linker>
</language>

<bfg>
<mpi>
<args>-n 1 -host localhost -dir @.@ dummy-a.exe</args>
<implementation>
<name>ModuleDummyA</name>
</implementation>
<language>
<target>
<ext>.o</ext>
</target>
<compiler>
<name>mpif90</name>
</compiler>
<linker>
<name>mpif90</name>
<args>-odummy-a.exe @OBJ_FILES@ -ldummy-a @LIBRARY_PATHS@</args>
<libraryPaths>
<directive>-L</directive>
<dirList>
<dir>@.@</dir>
</dirList>
</libraryPaths>
</linker>
</language>
</mpi>
</bfg>

<parameterList>
<parameter>
<name>Values</name>
<regex>^(.*)$</regex>
<restrictionList>
<restriction>
</restriction>
<restriction>
</restriction>
</restrictionList>
</parameter>
</parameterList>
</module>
Couplings XML file
The XML schema for Softiam.xml file in a coupling is coupling.xsd (See Figure 13
and 14). This schema defines the list of modules that are coupled, the restrictions between
the parameters of each module and the files where the modules are contained. The
following list summarizes all the options for this file:
• coupling: This element is the root element at coupling.xsd and encapsulates all the
possible elements of the schema (name, description, image, moduleList,
parameterCompatibilityList, bfg).
• name: Is the name that will appear for this coupling at the portal.
• description: Is a text describing the coupling. As the name, it appears at the portal
to describe the coupling.
• image: This field indicates the image that describes the workflow of the coupling.
It is showed at the web portal when a user selects a coupling to deploy.
• moduleList: This field contains the list of modules that are executed by this
coupling. Each module defines the jar file that contains the definition and source
code of the module, the machine where that file is (this information is contained
by the element name), the platform of the machine (windows, unix, aix, hpux,
irix, linux, macosx, solaris) and the secure shell style (windows or unix) to
execute remote commands.

• parameterCompatibilityList: This element allows the user to define restriction
between parameters of differents modules, so the first step is to define the
modules and parameters affected by the restrictions, to do this the element
module1Name, module2Name, parameter1Name and parameters2Name are used.
After the selection of the modules and parameters, we have to decide the type of
restriction. There are two possibilities: the first one is the simpleCompatibility,
which allows to define the restrictions equal, not equal, lessEqual, less,
moreEqual and more; the other possibility is the complexCompatibility that
allows to define groups of compatible values. Following is an example of a
simpleCompatibility:
<parameterCompatibilityList>
<parameterCompatibility>
<module1Name>MAGICC Climate (Tyndall Centre)</module1Name>
<parameter1Name>GCM Tuning</parameter1Name>
<module2Name>ICLIPS (PIK)</module2Name>
<parameter2Name>Change in Indicators</parameter2Name>
<simpleCompatibility>less</simpleCompatibility>
</parameterCompatibility>
</parameterCompatibilityList>
In this example if the parameter ‘GCM Tuning’ of the module ‘MAGICC Climate
(Tyndall Centre)’ is not less than the parameter ‘Change indicators’ at the module
‘ICLIPS (PIK)’ the portal shows an error to the user when executes the coupling.
Next example is a case of complexCompatibility:
<parameterCompatibilityList>
<parameterCompatibility>
<module1Name>MAGICC Climate (Tyndall Centre)</module1Name>
<parameter1Name>GCM Tuning</parameter1Name>
<module2Name>ICLIPS (PIK)</module2Name>
<parameter2Name>Change in Indicators</parameter2Name>
<complexCompatibility>
<valueCompatibility>
<valueList1>
<value>HadCM2</value>
</valueList1>
<valueList2>
<value>allHadcm2</value>
</valueList2>
</valueCompatibility>
<valueList1>
<value>ECHAM4</value>
</valueList1>
<valueList2>
<value>allEcham2</value>
</valueList2>
<valueList1>
<value>Custom</value>
</valueList1>
<valueList2>
<value>allFiles</value>
</valueList2>
</complexCompatibility>
</parameterCompatibility>
</parameterCompatibilityList>
At this example, there are only three correct configurations for the parameters.
Those configurations are:
1. The parameter ‘GCM Tuning’ of the module ‘MAGICC Climate
(Tyndall Centre)’ equal to ‘HadCM2’ and the parameter ‘Change in
Indicators’ of the module ‘ICLIPS (PIK)’ equal to ‘allHadcm2’.
(Tyndall Centre)’ equal to ‘ECHAM4’ and the parameter ‘Change in
Indicators’ of the module ‘ICLIPS (PIK)’ equal to ‘allEcham2’.
(Tyndall Centre)’ equal to ‘Custom’ and the parameter ‘Change in
Indicators’ of the module ‘ICLIPS (PIK)’ equal to ‘allFiles’.

• bfg: This parameter indicates the type of communication framework used by the
modules of the coupling (mpi or webservices) and the xml file that provides the
information of the coupled.xsd bfg’s schema (usually coupled.xml).
name
description
file
image
name
coupling moduleList module machine
0..∞
platform
ssh-style
module1Name
parameter1Name
parameterCompatibilityList parameterCompatibility
0..1 1..∞
module2Name
parameter2Name
file
simpleCompatibility
mpi complexCompatibility
bfg
webservice file
Figure 13: coupled.xsd (I)

valueList1 value
1..∞
complexCompatibility valueCompatibility
1..∞
valueList2 value
1..∞
Figure 14: coupled.xsd (II)
This is an example of Softiam.xml file for coupled.xsd schema which couples together
three modules named IPCC_ESM, MAGICC_SCM and SCENGEN_DSM:
<?xml version="1.0" encoding="UTF-8"?>
<coupling xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://namespaces.softiam.org/coupling
@LOCAL_SOFTIAM_HOME@/build/coupling.xsd"
xmlns="http://namespaces.softiam.org/coupling">
<name>IPCC_ESM Magicc_SCM Scengen_DSM</name>

<description>This models provides a method of creating spatially specific IPCC approved climate
predictions matching a range of emission scenarios.</description>
<image>softiam.gif</image>
<moduleList>
<module>
<machine>
<file>MPI_WINDOWS_ipcc-esm.jar</file>
<name>tynsoftiam.zicer.uea.ac.uk</name>
<platform>windows</platform>
<ssh-style>unix</ssh-style>
</machine>
</module>
<module>
<machine>
<file>MPI_WINDOWS_magicc-scm.jar</file>
</machine>
</module>
<module>
<machine>
<file>MPI_WINDOWS_scengen-dsm.jar</file>
</machine>
</module>
</moduleList>
<bfg>
<mpi>
<file>coupled.xml</file>
</mpi>
</bfg>
</coupling>
SoftIAM structure
When SoftIAM is installed in a computer, the installation generates a softiam-
<version> directory. This directory contains all necessary components to create, deploy
and execute couplings. Following is the directory tree of the installation:
softiam-<version>
bin
build
doc
etc
lib
public
modules
couplings
util
Figure 15: SoftIAM structure

The ‘bin’ directory contains all the executable commands of SoftIAM (UNIX and
Windows ‘softiam’ command) and the deployment file to create a SoftIAM node. The
directory ‘build’ has the ant script commands used internally by SoftIAM to perform all
the tasks. At ‘doc’ directory the user can find the documentation of the system. Tools and
libraries needed by SoftIAM are in ‘etc’, ‘lib’ and ‘util’. Finally, ‘public’ directory
contains all the modules and couplings that the machine can execute.
Inside the directory ‘modules’ we can find the ‘.jar’ files that contain the source
code, configuration files, softiam and bfg xml files of each module. Following is the
description of the modules’ jar files:
module.jar
Source code, config

files, ant build files,
build scripts
softiam.xml
Figure 16: module jar file
The softiam.xml file, at the module jar file, fits the schema module.xsd (See figures
9, 10, 11 and 12).
The directory ‘couplings’ contains all the ‘.jar’ files of the couplings. That ‘.jar’
files contain the bfg xml files and a softiam.xml file that fits coupling.xsd (See figures 13
and 14).
coupling.jar
module_i_dir
1..∞
executable.xml
interface.xml
run.xml
source.xml
compose.xml
coupled.xml
deploy.xml
run.xml
softiam.xml
Figure 17: coupling jar file
The schema for each file is as follows:
• module_i_dir/executable.xml: executable.xsd (See figure 5)
• module_i_dir/interface.xml: define.xsd (See figure 2)
• module_i_source.xml: source.xsd (See fire 3 and 4)
• module_i_run.xml: SoftIAM does not use it at current version
• compose.xml: compose.xsd (See figure 6)

• coupled.xml: coupled.xsd (See figure 8)
• deploy.xml: deploy.xsd (See figure 7)
• run.xml: SoftIAM does not use it at current version
Each coupling jar file has one module-i-dir for each module used at the coupling.
SoftIAM Command
SoftIAM command allows the user to perform all the task of the system. Following
is the output of the command with –help option:
SoftIAM Command Line Tool
Usage:
softiam -help
softiam -admin
softiam -gui
softiam -data-analysis
softiam -username <ID> -password <***> [-trace] [-l] -coupling <NAME>

[ACTION]
Actions: run|dist|clean|help
qrun|qdist
getConfigs|putConfigs|getResults
This command always executes on the LOCALHOST

softiam -username <ID> -password <***> [-trace] [-l]
-module <NAME> -coupling-context <NAME> [ACTION]
Actions: dist|clean|help
softiam -username <ID> -password <***> [-trace] [-l]

-module <NAME> -coupling <NAME> -datafile <NAME> [ACTION]
Actions: getDatafile
Options
-help: Displays this information
-admin: Displays usage information associated with
administrating SoftIAM and SoftIAM Portal
-gui: Starts couplings and modules test interface
-data-analysis: Starts data analysis user interface

-username: Any unique identifier which does not contain a space
and is also valid text for the name of a directory
It will be used to generate a user specific workspace
Workspaces allow many users to experiment independently
with the same modules
-password: Supplies the softiam password required in order to access
remote modules and data
-trace: Forces softiam to be more verbose
-l: Forces the output to be written to the log file
-coupling: A SoftIAM coupling

-module: A SoftIAM module
-coupling-context: A SoftIAM coupling context in which a SoftIAM module
is built and run
-datafile: A datafile used by a module of a coupling
And this is the output using –admin option:
Administration of SoftIAM and SoftIAM Portal
Usage:
softiam -deploy
softiam -dist
softiam -clean
softiam -config-machine <webservices|mpi>
softiam -add-user -username <ID> -password <***>
softiam -delete-user -username <ID>
softiam -list
softiam -unpack
softiam -pack
softiam -unpack-coupling <NAME>
softiam -unpack-module <NAME>
softiam -pack-coupling <NAME>
softiam -pack-module <NAME>
Options
-deploy: Deploys SoftIAM and the SoftIAM Portal
-dist: Generates the SoftIAM and SoftIAM Portal distributions
-clean: Removes ALL files including the generated
SoftIAM and SoftIAM Portal distributions
-config-machine: Configures a machine so that it can host
webservice or MPI modules
-add-user: Add a user to the SoftIAM Portal application
-delete-user: Delete a user from the SoftIAM Portal application
-list: Lists all available SoftIAM couplings and modules
-unpack: Unpacks all available SoftIAM couplings and modules
-pack: Packs all available SoftIAM couplings and modules
-unpack-coupling: Unpacks a SoftIAM coupling
-unpack-module: Unpacks a SoftIAM module
-pack-coupling: Packs a SoftIAM coupling
-pack-module: Packs a SoftIAM module
Most of the options are self explanatory, but following is the usage of the command
for the most important tasks (deploy and execute couplings):
softiam -username <ID> -password <***> [-trace] [-l] -coupling <NAME> [ACTION]
Actions: run|dist|clean|help
qrun|qdist
getConfigs|putConfigs|getResults
The command with this format allows the deployment, configuration and execution
of couplings. The steps to execute a coupling are:
1. If a coupling is not deployed we must deploy it, to do this we use the command:
softiam -username <ID> -password <***> [-trace] [-l] -coupling <NAME> dist
Where the ID is the user that executes the command, the password is the general
password to execute couplings in SoftIAM and the name is the name of the jar file
that contains the coupling (in the coupling directory) we want to execute. This
command downloads the configuration file to our localmachine to configure the
execution.
2. Once we have the configuration files modified we have to execute the coupling:
softiam -username <ID> -password <***> [-trace] [-l] -coupling <NAME> run
This command uploads the configuration files, executes the coupling and finally
downloads the results.

3. Is we want to undeploy the coupling (remove results, configurations and
compilation of modules), we use this command:
softiam -username <ID> -password <***> [-trace] [-l] -coupling <NAME> clean
We can see that the command have five more actions to execute. These options are:
• qdist: This action is identical to ‘dist’ except that no configuration files are
downloaded from distributions hosted on remote machines.
• qrun: This action is identical to ‘run’ except that no result files are uploaded to
distributions hosted on remote machines.
• getConfig: This action download configuration files from distributions hosted on
remote machines.
• putConfig: This action upload configuration files to distributions hosted on
remote machines.
• getResults: This action download result files from distributions hosted on remote
machines.
These are some example commands and the sequence of actions performed by
SoftIAM in the execution:
• softiam -username ID -password *** -trace -coupling EXAMPLE_MPI_dummy-
a_dummy-b_UNIX.jar dist
1. Build the dummy A library on the machine where this module lives.
2. Make available any data required by the dummy A library.
3. Build the dummy B library on the machine where this module lives.
4. Make available any data required by the dummy B library.

5. Generate the coupling code required to compose an integrated assessment
model out of the dummy A and B libraries.
6. Link the coupling code and the dummy A and B libraries into executables on
their respective machines.
7. Download the configuration files associated with the dummy A and B
modules to the machine where the user is running SoftIAM.
a. This is to give the user the chance to access and change the module
specific configuration files prior to a model run.
a_dummy-b_UNIX.jar run
1. Upload the configuration files associated with the generated dummy A and B
modules to the machines where these modules live, from the machine where
the user is running SoftIAM.
2. Start off the previously generated dummy A and B executables.
3. Download the result files associated with the dummy A and B modules to the
machine where the user is running SoftIAM.
a_dummy-b_UNIX.jar clean
1. Removes all intermediate files associated with the dummy A and B modules
on the machines where these modules live.

2. Removes all executable, data, configuration and result files associated with
the dummy A and B modules on the machines where these modules live.
3. Removes all information from the machine where the user is running
SoftIAM, associated with generating and running the coupling composed of
the dummy A and B modules.
SoftIAM Portal
The SoftIAM Portal is a Web based application (WAR) for interfacing with
SoftIAM. (See http://beo1.uea.ac.uk:8080/softiam/). It is implemented with the STRUTS
application framework. The portal provides a graphical user interface for carrying out
coupled modelling. For any particular coupled model, user interface components are
dynamically generated for the various modules which form the coupled model. The
information required to generate these user interface components is provided by SoftIAM
component XML files associated with the individual modules and couplings. Following
is a description of the functionality of the portal:
• Logon screen: At this screen users have to type their username and password to
enter the system. Once the user is logged on SoftIAM generate a work directory
for that user (if the directory does not exist). (See figure 18).
• Coupled Models screen: At this point the user selects the coupled model to
execute. The portal shows a flowchart of the model selected at the popup menu.
When the user clicks the ‘Display’ button the portal show the description of the
coupling and the modules that compose it. (See figure 19).
• Deployment screen: This screen shows the description of the coupling and each
module in the coupling. The user can undeploy the coupling (this is equivalent to
execute softiam -username <ID> -password <***> [-trace] [-l] -coupling
<NAME> clean) or deploy it (this is equivalent to execute softiam -username
<ID> -password <***> [-trace] [-l] -coupling <NAME> clean). (See figure 20).
Figure 18: Logon screen
Figure 19: Coupled Model screen

Figure 20: Deployment screen
• Execution screen: From this screen the user can configure and execute the
module. To configure a module of the coupling, the user selects the desired
module at the popup menu and then clicks on the ‘Configure’ button. If there are
restrictions between modules this screen allows to check that restrictions pressing
the button ‘Restrictions Info’, but the button does not appear if there is no
restriction defined. (See chapter ‘Couplings XML file’ for the definition of
‘parameterCompatibilityList’ elements). The user can also execute the module
clicking on ‘Run’ button, once the module has been executed the button
‘Download Results’ allows to see the results of the execution. (See figure 21).
Figure 21: Execution screen

• Configuration screen: To configure the modules of the couplings we use this
screen. At this screen we can select a value for all the parameters and
parameterArrays defined at the softiam.xml file of the module (See chapter
‘Module XML file’ for more information about parameters and parameterArrays
elements). If a parameter is defined as downloadable at the xml file the portal
shows a ‘Download’ button for that parameter. When the user click that button the
system download the file associated to the option selected or typed for the
parameter. To configure the module the user has to select the correct values for
the parameters and then press ‘Submit’ button.
Figure 22: Configuration screen
• Restrictions Info screen: The screen shows all the restrictions between the
parameters of each module defined at softiam.xml file of the module. (See chapter
‘Couplings XML file’ for more info about ‘parameterCompatibilityList’
elements). This screen is only an information screen. The user can not perform
any action at it. (See figure 23).
• Results Download screen: From this screen the user can download all the results
files and the configuration selected at the Configuration screen for each module.
(See figure 24). The results files are defined at the softiam.xml file of the module
jar file. (See chapter ‘Module XML file’ for more information about ‘resultList’
elements).
Figure 23: Restrictions Info screen
Figure 24: Results Download screen

The Prototype Model
Figure 25 illustrates the scientific design of the prototype Community Integrated
Assessment System which softIAM supports. It consists of models contributed by three
institutions: the University of Cambridge Faculty of Economics, which contributed the
ECONomic component, E3MG; the Tyndall Centre HQ at the University of East Anglia
which contributed the emissions module (ESM), the simple climate model (SCM), the
downscaler (DSM), and the SoftIAM Portal through which CIAS may be run; and the
Potsdam Institute for Climate Change in Germany, which contributed the ICLIPS impacts
tool; whilst the underlying computational structure (bespoke framework generator) is
contributed by the Centre for Novel Computing at the University of Manchester. Thus 4
institutions are participating in CIAS at this early stage.
Figure 25: The CIAS Prototype Structure

Component model descriptions
(a) ECON
The ECONomic model, E3MG is an econometric simulation model of the global E3
system, estimated on annual data 1971-2002 and projecting annually to 2020 and every
10 years to 2100. It is designed to address the issues of energy security and climate
stabilisation both in the medium and long terms, with particular emphasis on dynamics,
uncertainty and the design and use of economic instruments, such as emission allowance
trading schemes. It is a disequilibrium model with an open structure such that labour,
foreign exchange and public financial markets are not necessarily closed. It is very
disaggregated, with 20 world regions (including the 13 nation states with the highest CO2
emissions in 2000), 12 energy carriers, 19 energy users, 28 energy technologies, 14
atmospheric emissions and 42 industrial sectors, with comparable detail for the rest of the
economy. The methodology of the model can be described as post-Keynesian, following
that of the European model E3ME developed by Cambridge Econometrics (see
www.camecon.co.uk/e3me/intro.htm, Barker 1999) except that at the global level various
markets are closed, e.g. total exports equal total imports at a sectoral level allowing for
imbalances in the data. The model is in the process of development. Exogenous inputs
in the current version of the model (E3MG2.1) include GDP (largely), the world oil price,
regional gas and coal prices, energy supplies, population, participation rates, exchange
and interest rates and population. E3MG models technical change endogenously through
consideration of learning curves through regional investment in technology, technological
progress indicators in sectoral energy and export demand equations, and the effect of
extra investment in new technologies on consumption and output in the world economy.
It also contains a bottom-up model - an annual, dynamic technology model, referred
to here as the ETM model (Anderson and Winne, 2004). This is based on the concept of
a price effect on the elasticity of substitution between competing technologies.
E3MG simulates the effects of carbon taxes and permit trading upon the demand for
and technologies used to generate, energy. To do so the model simulates the economic
instruments of CO2 emission allowances (auctioned or grandfathered), energy and carbon
taxes, employment taxes, and other direct and indirect taxes. As a result of these
measures, carbon emissions can be reduced in the model by technology switching,
switching to lower carbon fuels, by increases in energy efficiency, or by changes in
demand.
E3MG outputs simulations of CO2 and other greenhouse emissions and GDP levels
interpolated to a 5-yearly basis to 2100. Energy emissions of other polluting gases, and
the structure of GDP in terms of industrial outputs and expenditure components are also
provided. Further details may be found in Barker et al.(2005).
(b) ESM
The ESM model contains a list of scenarios for CO2, CH4, N2O, SO2, CFCs and
PFCs. Emissions of CFCs and PFCs are fixed between 1765 and 2100 and for the other
gases between 1765 and 1990, whilst the user may select scenarios for the non-CO2
greenhouse gases between 1990 and 2100 at 5 – yearly intervals. These scenarios are
different interpretations of the SRES scenarios as modelled by various integrated
assessment modelling groups (e.g. AIM, Matsuoka et al.1995). If the model is used such
that the connection between E3MG and ESM is operative, then emissions are obtained
directly from E3MG.
(c) SCM
The simple climate model, MAGICC.TAR, was used to illuminate the
consequences of the SRES scenarios in the IPCC Third Assessment Report (IPCC
2001a). The MAGICC model has been developed and updated over 2 decades. For the
Third Assessment Report it was tuned to emulate 7 state-of-the-art coupled Atmosphere-
Ocean Global Circulation Models (AOGCMs) and used to extend the model results to the
35 IPCC Special Report on Emissions Scenarios (SRES) scenarios (Nakicenovich &
Swart 2000). It is a single piece of software comprising a set of linked internal
components to simulate GHG cycles, radiative forcing, and ice melt. Gas cycles are used
to convert surface emissions of gases to atmospheric concentrations and these are then
converted using standard formulae into radiative forcing, including that due to sulphate
aerosols. The total forcing then drives an upwelling diffusion energy balance model to
estimate future climate changes. Thus the package allows the user to determine changes
in CO2 concentration, global mean surface air temperature and sea-level between the
years 1990 and 2100 resulting from anthropogenic emissions of CO2, CH4, N2), HFCs,
CFCs and PFCs, as well as SO2. It is also possible to determine the sensitivity of these
results to the variation in key model parameters, specifically the climate sensitivity, the
ocean diffusivity, the aerosol forcing and uncertainties in the Carbon cycle (Wigley
1993). A capability to carry out such sensitivity studies manually has been included in
the SoftIAM portal.
(d) DSM
The downscaling model or DSM, is ClimGen, a climate generation tool developed
by Mitchell and Osborn (2004) in the tradition of CLIMAPS (Rotmans et al., 1994),
SCENGEN (Hulme et al., 1995b), CLIMPACTS (Kenny et al., 1995) and COSMIC
(1997). ClimGen provides high-resolution grids (0.5 degree) of month-by-month climate
variations for 1901-2002 (Mitchell and Jones, 2005) and 2001-2100 (Mitchell et al.,
2004). Nine climate variables are represented and coverage extends over the global land
surface, excluding Antarctica.
(e) ICLIPS
The ICLIPS Climate Impact Model was constructed at the Potsdam Institute for
Climate Change Research and consists of a library of regionalized climate impact
response functions representing the cause-effect relationship between climate variables
(temperature and CO2 concentration) and an aggregated impact indicator (Toth et al.
2003). These indicators are specified in biophysical units (i.e. impacts are not valued).
The functions have been derived from many simulations of (i) a modified version of the
global vegetation model, BIOME1 (Prentice et al.1992) (ii) a crop suitability model
FAO-AEZ (Leemans and van den Born, 1994), both adapted to allow for the direct
effects of enhanced CO2 on plants, and (iii) a global water model WaterGAP 1.0 (Doll et
al. 1999) developed at the University of Kassel. These indicate the effects of T and CO2
concentrations upon natural vegetation, potential agricultural production, and fresh water
availability. These results are based on scaled climate-change patterns resulting from
three recent GCMs. The library is used as a “look-up table” such that climate impacts
may be determined for various outputs of the MAGICC model. For output to be valid,
the climate sensitivity used in MAGICC.TAR model must be “tuned” to match the GCM
used in ICLIPS. This is easily handled by the SoftIAM portal such that the user is alerted
to mis-tuned configurations.
The use of ICLIPS is as a placeholder for a more detailed treatment of impacts in
CIAS, in which the pattern scaling is to occur within CIAS’s DSM model and its outputs
then linked directly to regional and sectoral impact models.
Use Cases
The prototype coupled integrated assessment model may be used in a number of
“modes” known as “use cases” (which as far as the system is concerned, are different
coupled integrated assessment models). Figures 26 to 29 illustrate some of the
possibilities. Figure 26 illustrates the simplest use case, connecting only ESM and SCM,
whilst the most useful practical applications are shown in Figures 27 to 29, where the
user may compare the global and regional climate impacts resulting if various climate
policies are, or are not, applied in the regions covered by E3MG. Different timescales of
application of such policies may be studied, and impacts may be examined at either the
regional scale, or at the global scale, though a linkage of ECON, ESM, SCM, and the
ICLIPS impacts tool. In Use Case A (Figure 26) the inputs are emissions of greenhouse
gases from 1990 to 2100 and the outputs are global average T and sea level rise from
1990 to 2100, at 5 yearly intervals. In Use Case B (Figure 27) the inputs are economic
policies for Carbon taxes and/or permit trading in the various world regions covered by
E3MG, whilst the outputs are global climate predictions. In Use Case C (Figure 28) the
outputs are (instead) regionally specific climate predictions and impacts in the range of
sectors covered by ICLIPS.
Figure 26: Use case A

Figure 27: Use case B
Figure 28: Use case C

Figure 29: Use case D
Future Plans
CIAS’s design reflects our ambitious goal of creating an array of models in each of
the categories “ECON”, “CLIMATE” and “IMPACT” (Figure 32). Users will ultimately
be able to substitute different models, using transformations where appropriate, within
each category in order to examine the robustness of outputs to paradigm shifts associated
with the use of different options for economics models within the “ECON” category, or
with different options for climate models within the “CLIMATE” category for example.
In addition, CIAS will allow for climate models (for example) to be broken down into
LAND, ATMOSPHERE and OCEAN components, or for CARBON CYCLE to be
treated in more detail. Feedback mechanisms are an important advantage associated with
the use of IA and these will also be included at a later stage. This will require further
development of the BFG to support such complex flows of information.
Figure 32 is an envisaged advanced stage in the development of CIAS requiring
many participating institutions which donate models to the pool. These structures also
allow for many more inter-comparisons between models and for more detailed or
complex use cases to be set up, hence the sets of alternative modules seen in “ECON”
and “CLIMATE” in Figure 32. This will require further development of the BFG to
support the different computer languages used at the more extensive array of participating
institutions.
A new implementation of BFG (termed BFG2) is therefore planned to support the
required additional functionality to the SoftIAM system. Of particular importance to
CIAS is the support for complex behaviour and support for modules which are internally
parallel. Further, support for new languages and frameworks will be added as required by
CIAS.
Separate ongoing collaboration with the Met Office with their Flume project, and
with the GENIE consortium (through the project GENIEfY), is aiming to ensure that
modules from these modelling groups will also be compatible with SoftIAM modules
(and each other).
Finally, as the CIAS system matures it is envisaged that it will have to begin tackling
problems that it does not currently have to face, such as interoperability with modules
written for other frameworks, how to support a restart mechanism, the inclusion of
modules which exploit parallelism in their execution, the application of (data)
transformations to data exchanged between modules, online visualisation of scientific

results and the computational efficiency of the coupled model, particularly in more
dynamic computational environments, such as the Grid
Figure 32: A potential future advanced configuration of CIAS

Conclusions
The SoftIAM system has been used to underpin the development of a flexible
distributed integrated assessment model. At the heart of SoftIAM lies the BFG coupling
system; the flexibility provided by the BFG greatly enhances the model’s utility as a
policy design tool, through the potential to complete robustness studies to intra- and inter-
model uncertainties and value judgements. The resultant completed first version of the
CIAS model is shown, in which a carefully designed, multi-sectoral economic model is
coupled to a simple climate model and a simple impacts tool. Further development of
the model requires further development of its supporting softIAM technology.
Acknowledgements
The coupled modelling demonstrations would not have been possible without the
enthusiastic participation of our colleagues at the Potsdam Institute for Climatology. In
this context we particularly thank Rupert Klein, Ciaron Linstead and Jochen Hinkel.
We also thank the Potsdam Institute, and in particular our colleague Hans-Martin Fuessel,
for the use of the ICLIPS climate impacts tool within the CIAS modelling system, our
colleagues within the Tyndall Centre, Terry Barker, Jonathan Kohler, and Haoran Pan for
the use of the E3MG model within CIAS, our colleagues Tim Lenton, John Shepherd,
Bob Marsh, Andy Ridgewell, Neil Edwards, David Cameron Andrew Yool and Mark
Williamson for use of the BCM GOLDSTEIN model within CIAS, and Sarah Raper and
Tom Wigley for use of the MAGICC model within CIAS. We also thank Tim Mitchell, a
former colleague within the Tyndall Centre, for his initial participation in the softIAM
project prior to leaving the organisation, and in particular for his many helpful
discussions.
Outputs
Publications and outreach are listed in the Overview.
REFERENCES
Arctic Climate Impact Assessment (ACIA).: 2004 ‘Impacts of a warming Arctic’. Cambridge
University Press, Cambridge, U.K.
Alcamo, J. (ed.) 1984. IMAGE 2.0: Integrated Modeling of Global Climate Change. Kluwer
Academic Publishers, London.
Arnell, N.W.: 2004, ‘Climate change and global water resources: SRES emissions and socio-
economic scenarios’, Global Environmental Change 14, 31-52.
Barker, T. 1999. Achieving a 10% cut in Europe’s carbon dioxide emissions using additional
excise duties: coordinated, uncoordinated and unilateral action using the econometric model
E3ME. Economic Systems Research, Vol. 11, No. 4, 401-421.
Barker, T., Pan, H., Kohler, J., Warren, R., and Winne, S. Avoiding dangerous climate change
by inducing technological progress: scenarios using a large-scale econometric model. Tyndall
Working Paper no. 77, 2005. www.tyndall.ac.uk
Bye, B., Kverndokk, S. and K.E. Rosendahl (2002): Mitigation costs, distributional effects
and ancillary benefits of carbon policies in the Nordic countries, the UK and Ireland:
A survey, Mitigation and Adaptation Strategies for Global Change 7, 339-366.
Caldeira, K., and Wickett, M.E.: 2003, ‘Anthropogenic carbon and ocean pH’, Nature 425, 365.
COSMIC, 1997. Country Specific Model for Intertemporal Climate.
http://crga.atmos.uiuc.edu/COSMIC accessed on 17.02.04

Cox, P.M., Betts, R.A., Collins, M., Harris, P.P., Huntingford, C. and Jones,C.D., 2004.
Amazonian forest dieback under climate-carbon cycle projections for the 21st century. Theor.
Appl. Climatol. 78, 137-156
Criqui P, Kitous A, Berk M, den Elzen M, Eickhout B, Lucas P, van Vuuren D, Kouvaritakis N
and Vanregemorter D (2003) Greenhouse Gas Reduction Pathways in the UNFCCC Process up to
2025. Technical Report. Study Contract: B4-3040/2001/325703/MAR/E.1 for the DG
Environment
Doll, P, Kaspar, F., and Alcamo, J.,1999. Computation of Global Water Availability and Water
Use at the Scale of Large Drainage Basins. Mathematische Geologie 4, 111-118.
Dowlatabadi, H., 1995. Integrated Assessment Models of Climate Change - An Incomplete
Overview. Energy Policy, 23, 289-296.
Fisher, G., Shah, Mahendra, and van Velthuizen, H.: 2002, ‘Climate Change and Agricultural
Vulnerability’, special report prepared by the International Institute for Applied Systems Analysis
under UN contract agreement no. 1113 as contribution to the World Summit on Sustainable
Development, Johannesburg 2002. IIASA, Laxenburg, Austria.
Ford, R.W., Riley, G.D., Bane, M.K., Armstrong, C.W. and Freeman, T.L. GCF: a General
Coupling Framework, Concurrency and Computation: Practice and Experience. Wiley & Sons (in
press)
Foster, I., and Kesselman, C., 1997. Globus: A Metacomputing Infrastructure Toolkit. Intl J.
Supercomputer Applications, 11(2):115-128.
Foster, I., Kesselman, C., and Tuecke, S, 2001. The Anatomy of the Grid: Enabling Scalable
Virtual Organizations. International J. Supercomputer Applications, 15(3) pp.
Gregory, J.M., Huybrechts, P., and Raper, S.C.B. , 2004. Threatened loss of the Greenland Ice
Sheet. Nature 428 p 616

Hare, W., 2003, ‘Assessment of Knowledge on Impacts of Climate Change – Contribution to the
specification of Art. 2 on the UNFCCC’, WGBU, Berlin 2003.
Hoegh-Guldberg, O.: 1999,. Climate change, coral bleaching and the future of the world's coral
reefs', Marine and Freshwater Research 50, 839-866.
Hulme, M., Jiang, T., and Wigley, T.M.L., 1995b. SCENGEN: A Climate Change SCENario
GENerator, Software User Manual, Version 1.0. Climatic Research Unit, UEA, Norwich, 38 pp.
Hulme, M., Raper, S.C.B. and Wigley, T.M.L.,1995a. An Integrated Framework to Address
Climate Change (ESCAPE) and Further Developments of the Global and Regional Climate
Modules. Energy Policy 23, 347-355.
IPCC, 2001a. Climate Change 2001. Contribution of Working Group I to the Third Assessment
Report of the Intergovernmental Panel on Climate Change, Cambridge University Press, UK.
IPCC, 2001b. Climate Change 2001 – Impacts, Adaptation and Vulnerability. Contribution of
Working Group II to the Third Assessment Report of the Intergovernmental Panel on Climate
Change, Cambridge University Press, UK, 1032 pp.
IPCC, 2001c. Climate Change 2001 – Mitigation. Contribution of Working Group III to the Third
Assessment Report of the Intergovernmental Panel on Climate Change, Cambridge University
Press, UK.
Kainuma, M., Matsuoka, Y., and Morita, T., 2003 (Eds). Climate Policy Assessment: Asia Pacific
Modelling. Springer-Verlag, Tokyo. 402
Kenny, G.J., Warrick, R.A., Mitchell, N.D., Mullan, A.B., and Salinger, M.J., 1995.
CLIMPACTS: An Integrated Model for Assessment of the Effects of Climate Change on the New
Zealand Environment. Journal of Biogeography, 22, 883-895
Leemans, R and Eickhout, B.: 2003, ‘Analysing ecosystems for different levels of climate
change’, Report to OECD Working Party on Global and Structural Policies ENV/EPOC/GSP
5/FINAL. OECD.
Leemans, R., and van den Born, G., 1994. Determining the Potential Global Distribution of
Natural Vegetation, Crops and Agricultural Productivity. Water, Air and Soil Pollution 76, 133-
162
Matsuoka, Y., Kainuma, M. and Morita, T., 1995. Scenario Analysis of Global Warming Using
the Asian Pacific Integrated Model (AIM). Energy Policy 23, 357-371.
Milly, P.C.D., Wetherald, R.T., Dunne, K.A. and Delworth, T.L., 2002. Increasing Risk of Great
Floods in a Changing Climate. Nature 415, 514-517.
Mitchell,T.D., Carter,T.R., Jones,P.D., Hulme,M. and New,M.G. (2004) A comprehensive set of
high-resolution grids of monthly climate for Europe and the globe: the observed record (1901–
2000) and 16 scenarios (2001–2100) Tyndall Centre Working Paper No.55, Tyndall Centre,
Norwich, UK, 30pp.
Mitchell,T.D. and Jones,P.D. (2005) An improved method of constructing a database of monthly
climate observations and associated high-resolution grids Int. J. Climatol., 25, 693-712.
Morgan, M.G. and Dowlatabadi, H., 1996. Learning from Integrated Assessment of Climate
Change. Climatic Change 34, 337-368.
Nakicenovich, N., and Swart, R.m 2000. Special Report on Emissions Scenarios. Cambridge,
UK. Cambridge University Press.
Oakley, J., and O’Hagain, A., 2002. Bayesian inference for the uncertainty of computer model
outputs. Biometrika 89, no. 4, pp 769-784
Oppenheimer, M., and Alley, R.B., 2004. The West Antarctic Ice Sheet and Long Term Climate
Policy. Climatic Change 64, 1- 10.
Parry, M (ed), 2004. An assessment of the global effects of climate change under SRES emissions
and socioeconomic conditions. Global Environmental Change 14, 4, Special Issue.
Parry, M. 2001. Millions at risk: defining critical climate change threats and targets. Global
Environmental Change 11, 1-3.

Plambeck, E.L., Hope, C. and Anderson, J., 1997. The PAGE95 Model: Integrating the Science
and Economics of Global Warming. Energy Economics 19, 77-101.
Prentice, I.C., Cramer, W., Harrison, S.P., Leemans, R., Monserud, R.A., and Solomon, A.M.,
1992. A Global Biome Model Based on Plant Physiology and Dominance, Soil Properties and
Climate. J. Biogeogr. 19, 117-134.
Prinn, R., Jacoby, H., Sokolov, A., Wang, C., Xiao, X., Yang, Z., Eckhaus, R., Stone, P.,
Ellerman, D., Melillo, J., Fitzmaurice, J., Kicklighter, D., Holian, G. and Liu, Y., 1999. Integrated
Global System Model for Climate Policy Assessment: Feedbacks and Sensitivity Studies.
Climatic Change, 41, 469-546.
Rahmstorf, S., 1995. Bifurcations of the Atlantic Thermohaline Circulation in response to
changes in the hydrological cycle. Nature 378, 145-149.
Richels, R. and Edmonds, J., 1995. The Economics of Stabilizing Atmospheric CO2
Concentrations. Energy Policy 23, 373-378.
Rotmans, J., 1990. IMAGE: An Integrated Model to Assess the Greenhouse Effect. Kluwer, The
Netherlands.
Rotmans, J., Hulme, M. and Downing, T.E., 1994. Climate Change Implications for Europe: An
application of the ESCAPE Model. Global Environ. Change 4, 97-124.
Schneider, S.H., and Toth, F.L., 2003 (eds). Integrated Assessment of Climate Protection
Strategies. Climatic Change 56, Nos. 1 -2 . Special Issue, January I-II.
Toth, F.L., Bruckner, T., Fussel, H.-M., Leimbach, M., and Petschel-Held, G., 2003. Integrated
Assessment of Long-term Climate Policies: Part 1- Model Presentation. Climatic Change 56: 37-
56.
Warren, R., 2002. A Blueprint for Integrated Assessment. Tyndall Centre Technical Report 1,
20 www.tyndall.ac.uk
Warren, R., 2005. Summary of climate impacts for different levels of global temperature rise.
Proceedings of the Avoiding Dangerous Climate Change conference, Exeter 2005. CUP. (in
press).
Wigley, T., 1993.Balancing the carbon budget. Implications for projections of future carbon
dioxide concentration changes. Tellus 45B 409-425.
1 http://www.ietf.org/html.charters/secsh-charter.html
2 http://java.sun.com/
3 http://www-unix.mcs.anl.gov/mpi/mpich2/
5 http://ant.apache.org/
6 http://jakarta.apache.org/struts/
Figure Captions
Figure 1. An overview of the SoftIAM infrastructure for CIAS
Figure 2. define.xsd
Figure 3. source.xsd. Top level details
Figure 4. source.xsd. Fields details
Figure 5. executable.xsd
Figure 6. compose.xsd
Figure 7. deploy.xsd
Figure 8. coupled.xsd
Figure 9. module.xsd (I)
Figure 10. module.xsd (II)
Figure 11. module.xsd (III)
Figure 12. module.xsd (IV)
Figure 13. coupled.xsd (I)
Figure 14. coupled.xsd (II)

Figure 15. SoftIAM structure
Figure 16. module jar file
Figure 17. coupling jar file
Figure 18. Logon screen
Figure 19. Coupled Model screen
Figure 20. Deployment screen
Figure 21. Execution screen
Figure 22. Configuration screen
Figure 23. Restrictions Info screen
Figure 24. Results Download screen
Figure 25. The CIAS Prototype Structure
Figure 26. Use Case A.
Figure 27. Use Case B.
Figure 28. Use Case C.
Figure 29. Use Case D.
Figure 30. Carbon Dioxide Concentrations for Illustrative Stabilisation Scenarios
Figure 31. Effect of carbon taxes (with permit trading and revenue recycling) on GDP compared to a
baseline case with no carbon taxes, showing the effect of including induced technical change in the
modelling exercise.
Figure 32. A potential future advanced configuration of CIAS.
Table Captions
Table 1: CO2 Emission Permit Prices and Carbon Tax Rates $/tC in stabilisation scenarios for Annex 1 and
Non-Annex 1 Countries.
Table 2: CO2 Emissions 2000-2100, Gt/year

The inter-disciplinary Tyndall Centre for Climate
Change Research undertakes integrated research into
the long-term consequences of climate change for
society and into the development of sustainable
responses that governments, business-leaders and Recent Tyndall Centre Technical Reports
decision-makers can evaluate and implement.
Achieving these objectives brings together UK climate Tyndall Centre Technical Reports are available online at
scientists, social scientists, engineers and economists http://www.tyndall.ac.uk/publications/tech_r
in a unique collaborative research effort. eports/tech_reports.shtml
The Tyndall Centre is named after the 19th century UK
scientist John Tyndall, who was the first to prove the
Earth’s natural greenhouse effect and suggested that Challenor, P., (2007) Estimating uncertainty
slight changes in atmospheric composition could bring in future assessments of climate change:
about climate variations. In addition, he was Tyndall Centre Technical Report No. 50.
committed to improving the quality of science
education and knowledge.
O'Riordan T., Watkinson A., Milligan J, (2006)
The Tyndall Centre is a partnership of the following
Living with a changing coastline:
institutions:
Exploring new forms of governance for
sustainable coastal futures:
University of East Anglia
Tyndall Centre Technical Report No. 49.
University of Manchester
University of Southampton
University of Sussex Anderson K., Bows A., Mander S, Shackley S.,
University of Oxford Agnolucci P., Ekins P., (2006) Decarbonising
University of Newcastle Modern Societies:Integrated Scenarios
Process and Workshops, Tyndall Centre
The Centre is core funded by the following Technical Report 48.
organisations:
Natural Environmental Research Council (NERC) Gough C., Shackley S. (2005) An integrated
Economic and Social Research Council (ESRC) Assesment of Carbon Dioxide Capture and
Engineering and Physical Sciences Research Storage in the UK. Tyndall Centre Technical
Council (EPSRC) Report 47.
For more information, visit the Tyndall Centre Web site

Nicholls R., Hanson S., Balson P., Brown I.,
(www.tyndall.ac.uk) or contact:
French J., Spencer T., (2005) Capturing
Geomorphological Change in the Coastal
Communications Manager
Simulator, Tyndall Centre Technical Report 46
Tyndall Centre for Climate Change Research
University of East Anglia, Norwich NR4 7TJ, UK
Phone: +44 (0) 1603 59 3906; Fax: +44 (0) Weatherhead K, Knox J, Ramsden S, Gibbons
1603 59 3901 J, Arnell N. W., Odoni, N, Hiscock K, Sandhu C,
Email: tyndall@uea.ac.uk Saich A., Conway D, Warwick C, Bharwani S,
(2006) Sustainable water resources: A
framework for assessing adaptation
options in the rural sector, Tyndall Centre
Technical Report 45
Weatherhead K, Knox J, Ramsden S, Gibbons Starkey R., Anderson K., (2005) Domestic
J, Arnell N. W., Odoni, N, Hiscock K, Sandhu C, Tradeable Quotas: A policy instrument for
Saich A., Conway D, Warwick C, Bharwani S, reducing greenhouse gas emissions from
energy use:, Tyndall Centre Technical Report 39
(2006) Sustainable water resources: A
framework for assessing adaptation Pearson, S., Rees, J., Poulton, C., Dickson, M.,
options in the rural sector, Tyndall Centre Walkden, M., Hall, J., Nicholls, R., Mokrech, M.,
Technical Report 44 Koukoulas, S. and Spencer, T. (2005) Towards an
integrated coastal sediment dynamics and
shoreline response simulator, Tyndall Centre
Lowe, T. (2006) Vicarious experience vs. Technical Report 38
scientific information in climate change
Sorrell, S. (2005) The contribution of energy
risk perception and behaviour: a case service contracting to a low carbon economy,
study of undergraduate students in Tyndall Centre Technical Report 37
Norwich, UK, Tyndall Centre Technical Report
Tratalos, J. A., Gill, J. A., Jones, A., Showler, D.,
43
Bateman, A., Watkinson, A., Sugden, R., and
Atkinson, P, (2006) Towards an integrated Sutherland, W. (2005) Interactions between
coastal simulator of the impact of sea level rise tourism, breeding birds and climate change
in East Anglia: Part B3- Coastal simulator and across a regional scale, Tyndall Centre Technical
biodiversity - Modelling the change in Report 36
wintering Twite Carduelis flavirostris
Thomas, D., Osbahr, H., Twyman, C., Adger, W. N.
populations in relation to changing saltmarsh
and Hewitson, B., (2005) ADAPTIVE: Adaptations
area, Tyndall Centre Technical Report 42B3
to climate change amongst natural resource-
Gill, J, Watkinson, A. and Sutherland, W., dependant societies in the developing world:
(2006) Towards an integrated coastal simulator across the Southern African climate gradient,
of the impact of sea level rise in East Anglia: Tyndall Centre Technical Report 35
Part B2- Coastal simulator and biodiversity - Arnell, N. W., Tompkins, E. L., Adger, W. N. and
models of biodiversity responses to Delany, K. (2005) Vulnerability to abrupt climate
environmental change Tyndall Centre Technical change in Europe, Tyndall Centre Technical Report
Report 42B2 34
Ridley, J., Gill, J, Watkinson, A. and Shackley, S. and Anderson, K. et al. (2005)
Sutherland, W., (2006) Towards an integrated Decarbonising the UK: Energy for a climate
coastal simulator of the impact of sea level rise conscious future, Tyndall Technical Report 33
in East Anglia: Part B1- Coastal simulator and
biodiversity - Design and structure of the Halliday, J., Ruddell, A., Powell, J. and Peters, M.
coastal simulator Tyndall Centre Technical Report (2005) Fuel cells: Providing heat and power in
42B1 the urban environment, Tyndall Centre Technical
Report 32
Stansby, P., Launder B., Laurence, D., Kuang,
Haxeltine, A., Turnpenny, J., O’Riordan, T., and
C., and Zhou, J., (2006) Towards an integrated Warren, R (2005) The creation of a pilot phase
coastal simulator of the impact of sea level rise
Interactive Integrated Assessment Process for
in East Anglia: Part A- Coastal wave climate
managing climate futures, Tyndall Centre
prediction and sandbanks for coastal
Technical Report 31
protection Tyndall Centre Technical Report 42A
Nedic, D. P., Shakoor, A. A., Strbac, G., Black, M.,
Lenton, T. M., Loutre, M. F, Williamson, M. S., Watson, J., and Mitchell, C. (2005) Security
Warren, R., Goodess, C., Swann, M., Cameron, assessment of futures electricity scenarios,
D. R., Hankin, R., Marsh, R. and Shepherd, J. Tyndall Centre Technical Report 30
G., (2006) Climate change on the millennial
Shepherd, J., Challenor, P., Marsh, B., Williamson,
timescale, Tyndall Centre Technical Report 41
M., Yool, W., Lenton, T., Huntingford, C., Ridgwell, A
Bows, A., Anderson, K. and Upham, P. (2006) and Raper, S. (2005) Planning and Prototyping a
Contraction & Convergence: UK carbon Climate Module for the Tyndall Integrated
emissions and the implications for UK air Assessment Model, Tyndall Centre Technical
traffic, Tyndall Centre Technical Report 40 Report 29
Lorenzoni, I., Lowe, T. and Pidgeon, N. (2005) A Brown, K., Boyd, E., Corbera-Elizalde, E., Adger, W.
strategic assessment of scientific and N. and Shackley, S (2004) How do CDM projects
behavioural perspectives on ‘dangerous’ contribute to sustainable development? Tyndall
climate change, Tyndall Centre Technical Report Centre Technical Report 16
28
Levermore, G, Chow, D., Jones, P. and Lister, D.
Boardman, B., Killip, G., Darby S. and Sinden, G, (2004) Accuracy of modelled extremes of
(2005) Lower Carbon Futures: the 40% House temperature and climate change and its
Project, Tyndall Centre Technical Report 27 implications for the built environment in the
UK, Tyndall Centre Technical Report 14
Dearing, J.A., Plater, A.J., Richmond, N., Prandle,
D. and Wolf , J. (2005) Towards a high resolution Jenkins, N., Strbac G. and Watson J. (2004)
cellular model for coastal simulation Connecting new and renewable energy sources
(CEMCOS), Tyndall Centre Technical Report 26 to the UK electricity system, Tyndall Centre
Technical Report 13
Timms, P., Kelly, C., and Hodgson, F., (2005)
World transport scenarios project, Tyndall Palutikof, J. and Hanson, C. (2004) Integrated
Centre Technical Report 25 assessment of the potential for change in
storm activity over Europe: Implications for
Brown, K., Few, R., Tompkins, E. L., Tsimplis, M.
insurance and forestry, Tyndall Centre Technical
and Sortti, (2005) Responding to climate
Report 12
change: inclusive and integrated coastal
analysis, Tyndall Centre Technical Report 24 Berkhout, F., Hertin, J., and Arnell, N. (2004)
Business and Climate Change: Measuring and
Anderson, D., Barker, T., Ekins, P., Green, K.,
Enhancing Adaptive Capacity, Tyndall Centre
Köhler, J., Warren, R., Agnolucci, P., Dewick, P.,
Technical Report 11
Foxon, T., Pan, H. and Winne, S. (2005) ETech+:
Technology policy and technical change, a Tsimplis, S. et al (2004) Towards a vulnerability
dynamic global and UK approach, Tyndall Centre assessment for the UK coastline, Tyndall Centre
Technical Report 23 Technical Report 10
Abu-Sharkh, S., Li, R., Markvart, T., Ross, N., Gill, J., Watkinson, A. and Côté, I (2004). Linking
Wilson, P., Yao, R., Steemers, K., Kohler, J. and sea level rise, coastal biodiversity and
Arnold, R. (2005) Microgrids: distributed on-site economic activity in Caribbean island states:
generation, Tyndall Centre Technical Report 22 towards the development of a coastal island
simulator, Tyndall Centre Technical Report 9
Shepherd, D., Jickells, T., Andrews, J., Cave, R.,
Ledoux, L, Turner, R., Watkinson, A., Aldridge, J. Skinner, I., Fergusson, M., Kröger, K., Kelly, C. and
Malcolm, S, Parker, R., Young, E., Nedwell, D. Bristow, A. (2004) Critical Issues in
(2005) Integrated modelling of an estuarine Decarbonising Transport, Tyndall Centre
environment: an assessment of managed Technical Report 8
realignment options, Tyndall Centre Technical
Adger W. N., Brooks, N., Kelly, M., Bentham, S. and
Report 21
Eriksen, S. (2004) New indicators of
Dlugolecki, A. and Mansley, M. (2005) Asset vulnerability and adaptive capacity, Tyndall
management and climate change, Tyndall Centre Centre Technical Report 7
Technical Report 20
Macmillan, S. and Köhler, J.H., (2004)
Shackley, S., Bray, D. and Bleda, M., (2005) Modelling energy use in the global building
Developing discourse coalitions to incorporate stock: a pilot survey to identify available data,
stakeholder perceptions and responses within Tyndall Centre Technical Report 6
the Tyndall Integrated Assessment, Tyndall
Steemers, K. (2003) Establishing research
Centre Technical Report 19
directions in sustainable building design,
Dutton, A. G., Bristow, A. L., Page, M. W., Kelly, C. Tyndall Centre Technical Report 5
E., Watson, J. and Tetteh, A. (2005) The
Goodess, C.M. Osborn, T. J. and Hulme, M. (2003)
Hydrogen energy economy: its long term role
The identification and evaluation of suitable
in greenhouse gas reduction, Tyndall Centre
scenario development methods for the
Technical Report 18
estimation of future probabilities of extreme
Few, R. (2005) Health and flood risk: A strategic weather events, Tyndall Centre Technical Report 4
assessment of adaptation processes and
Köhler, J.H. (2002). Modelling technological
policies, Tyndall Centre Technical Report 17
change, Tyndall Centre Technical Report 3
Gough, C., Shackley, S., Cannell, M.G.R. (2002). Warren, R. (2002). A blueprint for integrated
Evaluating the options for carbon assessment of climate change, Tyndall
sequestration, Tyndall Centre Technical Report 2 CentreTechnical Report 1

TR 51

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TR 51

Diunggah oleh

Hak Cipta:

Format Tersedia

SoftIAM: Integrated assessment modelling

using distributed software components

Dr. Rachel Warren, Santiago de la Nava Santos, S.,Dr. Rupert Ford,

Tyndall Centre for Climate Change Research Technical Report 51

assessment modelling using distributed software components).The following researchers worked

Bane3, Christopher Barton,1, and Len Freeman2

Manchester M60 1QD

Relevance to Tyndall Centre research strategy & overall Centre objectives

Potential for further work

Communication highlights including major publications and outputs

Dissemination Demonstration of CIAS in operation at international integrated assessment

In order to deliver the above requirements of a flexible coupled integrated

The flexible coupling capability is provided by an application of the Bespoke

Framework Generator described in section ‘The Bespoke Framework Generator’. In

bespoke framework generator.

Main project deliverable:

The software infrastructure SoftIAM was developed to implement CIAS. This

implementation is the main deliverable of the softIAM project.

modules and execute it 1 to produce outputs from the integrated model.

the more abstract scientific computation which may be implemented by a module. An

overview of the SoftIAM infrastructure for CIAS is given in Figure 1.

At the heart of SoftIAM is the Bespoke Framework Generator (BFG), a framework

code generation system which provides flexibility in the composition of individual

an important component of SoftIAM; it is discussed in more detail in the following

detail in the following section.)

SoftIAM portal, located on one of the machines in a participating institution

simplifies the process of specifying a coupled model, running the coupled

model and viewing the results.

Distributed computing resources (computers at various

Figure1: SoftIAM infrastructure

• The specification (and in some cases the setting) of appropriate individual

individual modules where appropriate.

CIAS is a distributed system, SoftIAM ensures that input data is transferred to

be located on the same machine on

module codes are provided as binary libraries or cross-compilation is possible.

“wrapper” (or framework) code generated by the BFG system needs to be

over a number of computational resources the running of the generated

executables is coordinated in an appropriate manner by softIAM.

Software Technologies used in SoftIAM

implementation of the SoftIAM infrastructure used in CIAS.

The Bespoke Framework Generator

The Centre for Novel Computing (CNC) in the School of Computer

Science at the University of Manchester, UK, had developed a basic methodology to

models. This approach is called the Flexible Coupling Approach (FCA)

(http://www.cs.manchester.ac.uk/cnc/projects/fca). For application in softIAM, this

basic methodology required considerable further development and modification. This

the softIAM project.

coupled model. The composition is performed at an abstract level, independent of the

implementation details of particular modules (application codes) which satisfy the

interfaces. At this level, a module may be thought of as being implemented by a code

thought of as a Fortran or C subroutine, for example, which is to be called from an, as

length later in Section ‘Details of the Bespoke Framework Generator’.

In FCA, the processes of describing module interfaces and composing modules

Composition and Deployment.

Associated with this Description, Composition and Deployment (DCD) approach is

this metadata, a code generation/configuration system can create appropriate

Details of the Bespoke Framework Generator

The Bespoke Framework Generator (BFG) is an implementation of the FCA

http://www.cs.manchester.ac.uk/cnc/projects/bfg and further details may be found in Ford

structured in the "describe-compose-deploy" hierarchy mentioned previously to reflect

it treats individual modules.

model is to be deployed. This information is used to construct the appropriate

for the Grid middleware Globus (Foster et al.1997)).