1 / 21

FLUME

FLUME. Marco Christoforou, Rupert Ford, Steve Mullerworth, Graham Riley, Allyn Treshansky, et. al. 19 October 2007. what is FLUME? everything you wanted to know about FLUME Metadata some other interesting things progress report. What is FLUME?. FL exible U nified M odel E nvironment

ralph
Download Presentation

FLUME

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FLUME Marco Christoforou, Rupert Ford, Steve Mullerworth, Graham Riley, Allyn Treshansky, et. al. 19 October 2007

  2. what is FLUME? • everything you wanted to know about FLUME Metadata • some other interesting things • progress report

  3. What is FLUME? • FLexible Unified Model Environment • scientific code is modularised; • infrastructure code is generated • big plans for UM vn7.0 (a bit)

  4. What is FLUME? 1. Components • a small set of F90 modules which provide types and subroutines to link components into a coherent program • any piece of atomic code that can form part of a composition • “everything is a model” 2. Framework

  5. What is FLUME? 3. Code Generator [BFG] • a set of tools to aid the user in creating experiments. • helps users to manipulate metadata so that it can be passed on to the code generator. • transforms a metadata description of an experiment into code (and input files) to actually run the experiment 4. User Interface

  6. What is FLUME? 5. Metadata • links all of the above entities together • describes all necessary aspects of a FLUME experiment • manipulated according to the DCCD paradigm

  7. FLUME Metadata why do we need another set of schemas? • process-driven: • each metadata document corresponds to a particular step in the experiment-creation (DCCD) process • syntactic: • FLUME describes models at a very low level – it is predominantly syntactic rather than semantic • generic: • there is almost nothing climate-specific about FLUME metadata • therefore it shouldn’t need to be extended as new climate configurations emerge

  8. FLUME Metadata DCCD • definition - defining a job’s components; writing code and creating metadata that follows the FLUME Single Model Guidelines • configuration - creating a specific instance of a component based upon the set of potential instances described by its definition; filling in the blanks • composition - creating links between components; specifying the behaviour of the coupled system • deployment - specifying how to deploy a composition onto computing resources • validation -ensuring no constraints are broken; ensuring that (definitions) metadata accurately reflects code

  9. resources grids administration configuration groups users roles modified during configuration data “models” composition machines modified during composition scientific models transformer models deployment grids diagnostic models modified during deployment composite models modified during definition constraints FLUME Metadata selections definitions nonspecific information model-specific information experiment-specific information

  10. some interesting things grids • grids are dissociated from model code and model metadata • grids are defined as resources that (variables within) models can map to • uninstantiated grids • high-level generic schema just containing some standard names, a set of question / answer pairs, and a reference to a grid instantiator • grid instantiators • algorithm that takes the answers to a configured uninstantiated grid as input and produces (a set of) instantiated grid(s) as output • instantiated grids • a “complete” description of a grid (gridspec?)

  11. some interesting things • how grid information might flow through flume: • configured grid data is referenced as data by a configured component; this data is passed directly to the component code (as subroutine arguments, for instance) • algorithm instantiates the grid and the FLUME Framework reads that information directly (and uses it for coupling, for instance)

  12. some interesting things constraints • specify logical relationships among metadata elements • built into metadata (written in XML) • implicit vs. explicit constraints • local vs. global constraints

  13. some interesting things

  14. progress report components • framework can flexibly couple toy models (add and remove models, change coupling options, etc.) • “FLUMEifying” the UM Atmosphere (stripping out infrastructure code) framework

  15. progress report metadata & code generator • basic structure is there • code generation “works” • grids • decompositions • constraints • more complex compositions

  16. final thoughts where does FLUME fit within the vast menagerie of standards • compatible with OASIS because using OASIS will be a deployment option • complementary to ESMF because generating ESMF models is a target of BFG • incorporates (a variant of) BFG • agnostic (probably) about model output metadata • has a different goal than NMM • one of the standards informing METAFOR • as for Curator…

  17. the end

  18. the end

  19. the end

  20. the end

  21. the end

More Related