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.ecollaboration.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. Multilevel 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: understand the degree to which increasing complexity of component models enhances understanding or increases/decreases uncertainty understand the robustness of results to paradigm shifts • the policy maker can receive a clear picture of:

the consistency or otherwise of integrated modelling results 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.

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.

1

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 This

basic methodology required considerable further development and modification.

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.

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.

2

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/secshcharter.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 visualization scripting

is of

used the of

by

the

internal software.

scripting The to SSH

engine server

and allows stage

data the

SoftIAM the

engine

SoftIAM

software

securely

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> <args>-c @SRC_FILES@</args> </compiler> <linker> <name>mpif90</name> <args>-oiclips-im.exe @LIBRARY_PATHS@</args> <libraryPaths> <directive>-L</directive> <dirList> <dir>@.@</dir> </dirList> </libraryPaths> </linker> </language> </mpi>
</BFG>

@OBJ_FILES@

-liclips-im

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> <value>type2.ems</value> </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) (ii) Compiles each module in the machine where the module is being executed. 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 group source language machine model runsOn
1..∞

1..∞

company

os

compiler fields
1..∞

1..∞

Figure 3: source.xsd. Top level details id index direction fieldunits fields array dimension
1..∞

size dimensionunits vartype

type

source 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 executable

units

machineName location directory name

type datasize
1..∞

value size units

Figure 5: executable.xsd

value runDuration compose providesModel connect requiresModel provides fieldConnect
0..∞

units name version

0..∞

id id

requires Figure 6: compose.xsd

machineName
deploimentUnit

name model
1..∞

1..∞

version

deploy framework

fabric language comms Figure 7: deploy.xsd

interface component
1..∞

source model executable run

coupled compose 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 dataList configList resultList module build actionList src language bfg
0..1

platform data config result

1..∞

file machine filename filename dist

0..1

1..∞

0..1

1..∞

0..1

1..∞

0..1

action fileList

1..∞

clean

0..1

file
0..1

0..∞

mpi webservice parameterList
0..1

parameter

0..∞

parameterArrayList 0..1

parameterArray

0..∞

Figure 9: module.xsd (I)

shell dist script
0..1

file args

clean

0..1

shell command
0..1

executeList

execute

target

ext

intermediate

0..1

ext

name language compiler args directive includePaths
0..1

dirList name linker args directive libraryPaths
0..1

dir

0..∞

dirList

dir

0..∞

Figure 10: module.xsd (II)

type args mpi
implementation

name

language

(See language reference at figure 10) name

implementation

webservice language

file

(See language reference at figure 10)

name type parameter readonly

0..1

downloadable regex filename displayOrder

0..1

name value restriction displayOrder

0..1

restrictionList

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 restriction value displayOrder Figure 12: module.xsd (IV)

0..1

restrictionList

0..1

0..∞

0..1

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:

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’. 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 “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> <type>fortran</type> <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> <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@ dummya.lib fmpich2.lib</args> <libraryPaths> <directive>/LIBPATH:</directive> <dirList> <dir>@MPICH2_HOME@\lib</dir> </dirList> </libraryPaths> </linker> </language> </mpi> </bfg>

“sourcefile1.obj”

“sourcefile2.obj”

“dummy-a.lib”

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> <directive>/I</directive> <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> <type>java.lang.String</type> <regex>^(.*)$</regex>

<filename>dummy-a.properties</filename> <displayOrder>1</displayOrder> <restrictionList> <restriction> <name>Type 1 Values</name> <value>type1.ems</value> </restriction> <restriction> <name>Type 2 Values</name> <value>type2.ems</value> </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> <type>java.lang.String</type> <regex>^(?:.*\n){36}^[ ]*(.*)[ ]*\*[ ]*GCM.*$</regex> <filename>MAGMOD.CFG</filename> <displayOrder>3</displayOrder> <restrictionList> <restriction> <name>Custom</name> <value>Custom</value> <displayOrder>1</displayOrder> </restriction> <restriction> <name>GFDL</name> <value>GFDL</value> <constrainedParameterList> <constrainedParameter> <name>Measure of CO2 Doubling Forcing (W 1/m&#178;)</name> <value>5.352</value> </constrainedParameter> <constrainedParameter> <name>Climate Sensitivity (&#176;C) (0.5 - 5.5)</name> <value>4.2</value> </constrainedParameter> <constrainedParameter> <name>Mixed Layer Depth (m)</name> <value>60</value> </constrainedParameter> </restriction> <restriction>

<name>HadCM3</name> <value>HadCM3</value> <constrainedParameterList> <constrainedParameter> <name>Measure of CO2 Doubling Forcing (W 1/m&#178;)</name> <value>5.396</value> </constrainedParameter> <constrainedParameter> <name>Climate Sensitivity (&#176;C) (0.5 - 5.5)</name> <value>3.0</value> </constrainedParameter> </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&#178;)’ takes the value 5.396 and the parameter ‘Climate Sensitivity (&#176;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"> <!-- Where used @USERNAME@ is replaced before this specification file is used with the name of the user invoking SoftIAM --> <!-- Where used @LOCAL_SOFTIAM_HOME@ is replaced before this specification file is used with the full PATH to the local SoftIAM installation --> <!-- Where used @JAVA_HOME@ is replaced before this specification file is used with the full PATH to the local Java installation --> <!-- Where used @MPICH2_HOME@ is replaced before this specification file is used with the full PATH to the local Mpich2 installation --> <!-- Where used @.@ is replaced before this specification file is used with the full PATH to the module installation --> <!-- These three tags contain information which will be displayed by the SoftIAM Portal --> <name>Module Dummy A</name> <description>A dummy module.</description> <configurationDescription>Select from the drop down list.</configurationDescription> <!-- These tags specify which platforms this module specification file can be run on --> <platformList> <platform>unix</platform> </platformList> <!-- These tags specify the data archives which need to be expanded into the directory where the module executable lives --> <!-- <dataList> <data> <file></file> <machine</machine> </data> </dataList> --> <!-- These tags specify the configuration files which the user of the module is allowed to change in order to customize the behaviour of the model --> <configList> <config> <filename>dummy-a.properties</filename> </config> </configList> <!-- These tags specify the results files which the module produces --> <!-- <resultList> <result> <filename></filename> </result> </resultList> -->

<!-- These tags force SoftIAM to execute the action in the script build.xml equal to the action that the user is invoking SoftIAM with --> <build>build.xml</build> <!-- These tags force SoftIAM to execute the various commands depending on what action the user is invoking SoftIAM with --> <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> <!-- Here are all the src files which need to be built --> <src> <fileList> <file>ModuleDummyA.f90</file> <file>SourceDummyA.f90</file> </fileList> </src> <!-- Here is all the information needed to build this module --> <language> <target> <ext>.o</ext> </target> <compiler> <name>ifc</name>

<args>-c @SRC_FILES@</args> </compiler> <linker> <name>ar</name> <args>-rsv libdummy-a.a @OBJ_FILES@</args> </linker> </language> <!-- Here is all the information necessary to allow this module to be coupled into a model --> <bfg> <mpi> <type>fortran</type> <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> <args>-c @SRC_FILES@</args> </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> <!-- These tags contain information which will be used by the SoftIAM Portal to generate input fields which allow the values of module configuration parameters to be altered in the files referred to in the &lt;configList> tags --> <parameterList> <parameter> <name>Values</name> <type>java.lang.String</type> <regex>^(.*)$</regex> <filename>dummy-a.properties</filename> <displayOrder>1</displayOrder> <restrictionList> <restriction> <name>Type 1 Values</name> <value>type1.ems</value> </restriction> <restriction>

<name>Type 2 Values</name> <value>type2.ems</value> </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> <valueCompatibility> <valueList1> <value>ECHAM4</value> </valueList1> <valueList2> <value>allEcham2</value> </valueList2> </valueCompatibility> <valueCompatibility> <valueList1> <value>Custom</value> </valueList1> <valueList2> <value>allFiles</value> </valueList2> </valueCompatibility> </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’. 2. The parameter ‘GCM Tuning’ of the module ‘MAGICC Climate (Tyndall Centre)’ equal to ‘ECHAM4’ and the parameter ‘Change in Indicators’ of the module ‘ICLIPS (PIK)’ equal to ‘allEcham2’. 3. The parameter ‘GCM Tuning’ of the module ‘MAGICC Climate (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
0..∞

machine platform ssh-style module1Name
parameter1Name

parameterCompatibilityList 0..1

parameterCompatibility 1..∞

module2Name
parameter2Name

file

simpleCompatibility complexCompatibility

mpi bfg webservice Figure 13: coupled.xsd (I) file

valueList1
complexCompatibility
valueCompatibility 1..∞

value

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> <name>tynsoftiam.zicer.uea.ac.uk</name> <platform>windows</platform> <ssh-style>unix</ssh-style> </machine> </module> <module> <machine> <file>MPI_WINDOWS_scengen-dsm.jar</file> <name>tynsoftiam.zicer.uea.ac.uk</name> <platform>windows</platform> <ssh-style>unix</ssh-style> </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: -admin: -gui:

Displays this information Displays usage information associated with administrating SoftIAM and SoftIAM Portal Starts couplings and modules test interface Starts data analysis user interface

-data-analysis:

-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: -dist: -clean:

Deploys SoftIAM and the SoftIAM Portal Generates the SoftIAM and SoftIAM Portal distributions 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_dummya_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. •

softiam -username ID -password *** -trace -coupling EXAMPLE_MPI_dummya_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. •

softiam -username ID -password *** -trace -coupling EXAMPLE_MPI_dummya_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 AtmosphereOcean 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 intermodel 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 socioeconomic 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, 133162 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: 3756. 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. press). Wigley, T., 1993.Balancing the carbon budget. Implications for projections of future carbon dioxide concentration changes. Tellus 45B 409-425. CUP. (in

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 decision-makers can evaluate and implement. Achieving these objectives brings together UK climate scientists, social scientists, engineers and economists in a unique collaborative research effort. 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 slight changes in atmospheric composition could bring about climate variations. In addition, he was committed to improving the quality of science education and knowledge. The Tyndall Centre is a partnership of the following institutions: University University University University University University of of of of of of East Anglia Manchester Southampton Sussex Oxford Newcastle

Recent Tyndall Centre Technical Reports

http://www.tyndall.ac.uk/publications/tech_r eports/tech_reports.shtml

Tyndall Centre Technical Reports are available online at

Challenor, P., (2007) Estimating uncertainty in future assessments of climate change: Tyndall Centre Technical Report No. 50. O'Riordan T., Watkinson A., Milligan J, (2006) Living with a changing coastline: Exploring new forms of governance for sustainable coastal futures: Tyndall Centre Technical Report No. 49. Anderson K., Bows A., Mander S, Shackley S., Agnolucci P., Ekins P., (2006) Decarbonising Modern Societies:Integrated Scenarios Process and Workshops, Tyndall Centre Technical Report 48. Gough C., Shackley S. (2005) An integrated Assesment of Carbon Dioxide Capture and Storage in the UK. Tyndall Centre Technical Report 47. Nicholls R., Hanson S., Balson P., Brown I., French J., Spencer T., (2005) Capturing Geomorphological Change in the Coastal Simulator, Tyndall Centre Technical Report 46 Weatherhead K, Knox J, Ramsden S, Gibbons J, Arnell N. W., Odoni, N, Hiscock K, Sandhu C, 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

The Centre is core funded by the following organisations: Natural Environmental Research Council (NERC) Economic and Social Research Council (ESRC) Engineering and Physical Sciences Research Council (EPSRC) For more information, visit the Tyndall Centre Web site (www.tyndall.ac.uk) or contact: Communications Manager Tyndall Centre for Climate Change Research University of East Anglia, Norwich NR4 7TJ, UK Phone: +44 (0) 1603 59 3906; Fax: +44 (0) 1603 59 3901 Email: tyndall@uea.ac.uk

Weatherhead K, Knox J, Ramsden S, Gibbons J, Arnell N. W., Odoni, N, Hiscock K, Sandhu C, 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 44 Lowe, T. (2006) Vicarious experience vs. scientific information in climate change risk perception and behaviour: a case study of undergraduate students in Norwich, UK, Tyndall Centre Technical Report 43 Atkinson, P, (2006) Towards an integrated
coastal simulator of the impact of sea level rise in East Anglia: Part B3- Coastal simulator and biodiversity - Modelling the change in wintering Twite Carduelis flavirostris populations in relation to changing saltmarsh area, Tyndall Centre Technical Report 42B3

Starkey R., Anderson K., (2005) Domestic Tradeable Quotas: A policy instrument for reducing greenhouse gas emissions from energy use:, Tyndall Centre Technical Report 39 Pearson, S., Rees, J., Poulton, C., Dickson, M., Walkden, M., Hall, J., Nicholls, R., Mokrech, M., Koukoulas, S. and Spencer, T. (2005) Towards an integrated coastal sediment dynamics and shoreline response simulator, Tyndall Centre Technical Report 38 Sorrell, S. (2005) The contribution of energy service contracting to a low carbon economy, Tyndall Centre Technical Report 37 Tratalos, J. A., Gill, J. A., Jones, A., Showler, D., Bateman, A., Watkinson, A., Sugden, R., and Sutherland, W. (2005) Interactions between tourism, breeding birds and climate change across a regional scale, Tyndall Centre Technical Report 36 Thomas, D., Osbahr, H., Twyman, C., Adger, W. N. and Hewitson, B., (2005) ADAPTIVE: Adaptations to climate change amongst natural resourcedependant societies in the developing world: across the Southern African climate gradient, Tyndall Centre Technical Report 35 Arnell, N. W., Tompkins, E. L., Adger, W. N. and Delany, K. (2005) Vulnerability to abrupt climate change in Europe, Tyndall Centre Technical Report 34 Shackley, S. and Anderson, K. et al. (2005) Decarbonising the UK: Energy for a climate conscious future, Tyndall Technical Report 33 Halliday, J., Ruddell, A., Powell, J. and Peters, M. (2005) Fuel cells: Providing heat and power in the urban environment, Tyndall Centre Technical Report 32 Haxeltine, A., Turnpenny, J., O’Riordan, T., and Warren, R (2005) The creation of a pilot phase Interactive Integrated Assessment Process for managing climate futures, Tyndall Centre Technical Report 31 Nedic, D. P., Shakoor, A. A., Strbac, G., Black, M., Watson, J., and Mitchell, C. (2005) Security assessment of futures electricity scenarios, Tyndall Centre Technical Report 30 Shepherd, J., Challenor, P., Marsh, B., Williamson, M., Yool, W., Lenton, T., Huntingford, C., Ridgwell, A and Raper, S. (2005) Planning and Prototyping a Climate Module for the Tyndall Integrated Assessment Model, Tyndall Centre Technical Report 29

Gill, J, Watkinson, A. and Sutherland, W.,
(2006) Towards an integrated coastal simulator of the impact of sea level rise in East Anglia: Part B2- Coastal simulator and biodiversity models of biodiversity responses to environmental change Tyndall Centre Technical Report 42B2

Ridley, J., Gill, J, Watkinson, A. and Sutherland, W., (2006) Towards an integrated
coastal simulator of the impact of sea level rise in East Anglia: Part B1- Coastal simulator and biodiversity - Design and structure of the coastal simulator Tyndall Centre Technical Report 42B1

Stansby, P., Launder B., Laurence, D., Kuang, C., and Zhou, J., (2006) Towards an integrated
coastal simulator of the impact of sea level rise in East Anglia: Part A- Coastal wave climate prediction and sandbanks for coastal protection Tyndall Centre Technical Report 42A

Lenton, T. M., Loutre, M. F, Williamson, M. S., Warren, R., Goodess, C., Swann, M., Cameron, D. R., Hankin, R., Marsh, R. and Shepherd, J. G., (2006) Climate change on the millennial
timescale, Tyndall Centre Technical Report 41 Bows, A., Anderson, K. and Upham, P. (2006) Contraction & Convergence: UK carbon emissions and the implications for UK air traffic, Tyndall Centre Technical Report 40

Lorenzoni, I., Lowe, T. and Pidgeon, N. (2005) A strategic assessment of scientific and behavioural perspectives on ‘dangerous’ climate change, Tyndall Centre Technical Report 28 Boardman, B., Killip, G., Darby S. and Sinden, G, (2005) Lower Carbon Futures: the 40% House Project, Tyndall Centre Technical Report 27 Dearing, J.A., Plater, A.J., Richmond, N., Prandle, D. and Wolf , J. (2005) Towards a high resolution cellular model for coastal simulation (CEMCOS), Tyndall Centre Technical Report 26 Timms, P., Kelly, C., and Hodgson, F., (2005) World transport scenarios project, Tyndall Centre Technical Report 25 Brown, K., Few, R., Tompkins, E. L., Tsimplis, M. and Sortti, (2005) Responding to climate change: inclusive and integrated coastal analysis, Tyndall Centre Technical Report 24 Anderson, D., Barker, T., Ekins, P., Green, K., Köhler, J., Warren, R., Agnolucci, P., Dewick, P., Foxon, T., Pan, H. and Winne, S. (2005) ETech+: Technology policy and technical change, a dynamic global and UK approach, Tyndall Centre Technical Report 23 Abu-Sharkh, S., Li, R., Markvart, T., Ross, N., Wilson, P., Yao, R., Steemers, K., Kohler, J. and Arnold, R. (2005) Microgrids: distributed on-site generation, Tyndall Centre Technical Report 22 Shepherd, D., Jickells, T., Andrews, J., Cave, R., Ledoux, L, Turner, R., Watkinson, A., Aldridge, J. Malcolm, S, Parker, R., Young, E., Nedwell, D. (2005) Integrated modelling of an estuarine environment: an assessment of managed realignment options, Tyndall Centre Technical Report 21 Dlugolecki, A. and Mansley, M. (2005) Asset management and climate change, Tyndall Centre Technical Report 20 Shackley, S., Bray, D. and Bleda, M., (2005) Developing discourse coalitions to incorporate stakeholder perceptions and responses within the Tyndall Integrated Assessment, Tyndall Centre Technical Report 19 Dutton, A. G., Bristow, A. L., Page, M. W., Kelly, C. E., Watson, J. and Tetteh, A. (2005) The Hydrogen energy economy: its long term role in greenhouse gas reduction, Tyndall Centre Technical Report 18 Few, R. (2005) Health and flood risk: A strategic assessment of adaptation processes and policies, Tyndall Centre Technical Report 17

Brown, K., Boyd, E., Corbera-Elizalde, E., Adger, W. N. and Shackley, S (2004) How do CDM projects contribute to sustainable development? Tyndall Centre Technical Report 16 Levermore, G, Chow, D., Jones, P. and Lister, D. (2004) Accuracy of modelled extremes of temperature and climate change and its implications for the built environment in the UK, Tyndall Centre Technical Report 14 Jenkins, N., Strbac G. and Watson J. (2004) Connecting new and renewable energy sources to the UK electricity system, Tyndall Centre Technical Report 13 Palutikof, J. and Hanson, C. (2004) Integrated assessment of the potential for change in storm activity over Europe: Implications for insurance and forestry, Tyndall Centre Technical Report 12 Berkhout, F., Hertin, J., and Arnell, N. (2004) Business and Climate Change: Measuring and Enhancing Adaptive Capacity, Tyndall Centre Technical Report 11 Tsimplis, S. et al (2004) Towards a vulnerability assessment for the UK coastline, Tyndall Centre Technical Report 10 Gill, J., Watkinson, A. and Côté, I (2004). Linking sea level rise, coastal biodiversity and economic activity in Caribbean island states: towards the development of a coastal island simulator, Tyndall Centre Technical Report 9 Skinner, I., Fergusson, M., Kröger, K., Kelly, C. and Bristow, A. (2004) Critical Issues in Decarbonising Transport, Tyndall Centre Technical Report 8 Adger W. N., Brooks, N., Kelly, M., Bentham, S. and Eriksen, S. (2004) New indicators of vulnerability and adaptive capacity, Tyndall Centre Technical Report 7 Macmillan, S. and Köhler, J.H., (2004) Modelling energy use in the global building stock: a pilot survey to identify available data, Tyndall Centre Technical Report 6 Steemers, K. (2003) Establishing research directions in sustainable building design, Tyndall Centre Technical Report 5 Goodess, C.M. Osborn, T. J. and Hulme, M. (2003) The identification and evaluation of suitable scenario development methods for the estimation of future probabilities of extreme weather events, Tyndall Centre Technical Report 4 Köhler, J.H. (2002). Modelling technological change, Tyndall Centre Technical Report 3

Gough, C., Shackley, S., Cannell, M.G.R. (2002). Evaluating the options for carbon sequestration, Tyndall Centre Technical Report 2

Warren, R. (2002). A blueprint for integrated assessment of climate change, Tyndall CentreTechnical Report 1