The Flexible Unified Model Environment (FLUME) project aims to generate a new system architecture for the Met Office Unified Model System. This architecture will separate the infrastructure code from the scientific code and redesign both so that they are able to be more flexibly combined with each other (and with externally provided models). Scientific code will be modularised and infrastructure code will be generated. Broadly speaking, this can be accomplished by:
- providing a standard interface for FLUME-compliant models to adhere to;
- describing FLUME models using FLUME Metadata.
Consultants Graham Riley and Rupert Ford from the Centre for Novel Computing at the University of Manchester were brought in to give a view on what is required. The high-level design and initial implementation plans have been completed and are described in the documents below.
|
Considers the requirements, use cases, and related work for the FLUME project |
|
An initial high level design of FLUME |
|
Overall architecture of the complete system emphasising the interaction between subcomponents and the operation of the full system |
|
Scientists need to develop and test modifications to scientific aspects of their experiments while being confident that changes that may occur to the underlying system will not perturb results. |
|
Covers IO-related systems such as the needs for an extensive diagnostic system, production of checkpoint dumps, and archiving of output data |
|
Guidelines for developers who wish to develop a FLUME-compliant scientific model |
|
How will the scientists set up and configure their coupled model jobs and how will the system be maintained? |
|
Considers metadata requirements to describe data within the FLUME system, and the file formats that need to be supported for Climate Research and Numerical Weather Prediction operations |
|
Considers how documentation might flow through the FLUME system |
|
These documents require Adobe Reader 7.0 or later
If you wish to reference these documents, please follow the example below and reference the web address of this index page: 'The Met Office FLUME Project - Model Coupling Review. Rupert W. Ford, Graham D. Riley; Manchester Informatics Ltd., The University of Manchester. http://www.metoffice.gov.uk/research/interproj/flume/'
Work to implement FLUME has concentrated on the following areas.
FLUME components
A component is any piece of atomic code that can form part of a composition. FLUME takes the view that everything is a model. That is, all components should be treated the same within FLUME - as entities which accept input and provide output. Examples of components include scientific models and transformers adhering to the FLUME Conformance Rules.
The UM Atmosphere is being actively recoded into a FLUME Component.
Code Generator
The FLUME Code Generator takes a FLUME Metadata description of a job as input and transforms that metadata into infrastructure code (and, potentially, input files and build scripts) to run the experiment. The resultant code is linked with the FLUME Framework and the appropriate component code.
FLUME's code generator is based upon the Bespoke Framework Generator (BFG2) developed by Manchester Informatics, Ltd.
FLUME Framework
The FLUME Framework is a small set of F90 modules which provide types and subroutines to link FLUME components into a coherent program. The FLUME Framework includes support for coupling, data management, and adaptors for external (i.e. developed outside the scope of FLUME) components such as the MPI communication library or the OASIS4 coupler.
The FLUME Framework is continuing to evolve. Support for coupling, data management, and parallelisation is in place; support for grids is forthcoming.
FLUME Metadata
FLUME Metadata provides a complete XML description of a FLUME experiment. This includes descriptions of the components being coupled together, their input and output data, their deployment and decomposition strategies, etc.
Metadata schemas for describing aspects of climate modelling already exist - why is FLUME providing another one? what distinguishes it from existing schemas?
Each FLUME Metadata document corresponds to one particular step in the DCCD process. DCCD is the the act of:
- Defining a component; writing FLUME-compliant code and describing that code in FLUME Metadata.
- Configuring a specific instance of a component based upon the set of potential instances described by its definition; filling in the blanks.
- linking the inputs and outputs of components together into a single Composition; specifying the behaviour of the coupled system.
- specifying how to Deploy a composition onto computing resources.
Constraints embedded within FLUME Metadata mean that documents manipulated during any single phase of DCCD restrict the permissible manipulations of documents in any other phase.
- Syntactic
FLUME Metadata describes components at a very low level. It is predominantly syntactic rather than semantic; The main role of FLUME Metadata is to provide input to the code generator, not to provide descriptive information to end-users.
- Generic
Taking a cue from BFG, FLUME Metadata contains very little climate-specific information; It is predominantly a description of Fortran code as opposed to the science being simulated. Therefore, it shouldn't need to be extended as new climate configurations emerge.
A working version of the FLUME Metadata schemas has been completed. Support for grids, domain decompositions, constraints, and more complex compositions is forthcoming.
|
Home 
