Difference between revisions of "GENIE Gridspec"

From SourceWiki
Jump to navigation Jump to search
Line 19: Line 19:
 
==Gridspec proposal==
 
==Gridspec proposal==
  
A [http://www.earthsystemcurator.org/index.php?option=com_content&task=view&id=38&Itemid=74 proposal] is currently being worked on by V. Balaji (GFDL).  The proposal currently consists of a [http://curatordb.cvs.sourceforge.net/*checkout*/curatordb/curator/curator-nmm/grid/gridstd.pdf PDF document] that describes the proposed standard, implemented as an extension to the NetCDF [http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-current.html Climate and Forecast (CF) conventions], and a couple of UML class diagrams that provide a diagrammatic overview of the proposed grid schema.
+
A [http://www.earthsystemcurator.org/index.php?option=com_content&task=view&id=38&Itemid=74 gridspec proposal] is currently being worked on by V. Balaji (GFDL).  The proposal currently consists of a [http://curatordb.cvs.sourceforge.net/*checkout*/curatordb/curator/curator-nmm/grid/gridstd.pdf PDF document] that describes the proposed standard, implemented as an extension to the NetCDF [http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-current.html Climate and Forecast (CF) conventions], and a couple of UML class diagrams that provide a diagrammatic overview of the proposed grid schema.
  
 
As part of the work to create a version of the [[GENIE_Coupling|GENIE ESM framework using the PRISM coupler]] (OASIS) using the [[GENIE_BFG|Bespoke Framework Generator (BFG)]] tool, a working implementation of Balaji's grid schema proposal is being developed.  This gridspec implementation will be used to describe the grids used by individual GENIE models, allowing BFG to generate automatically the PRISM grid initialisation code for each model required for OASIS coupling.  A draft of this gridspec is presented below.
 
As part of the work to create a version of the [[GENIE_Coupling|GENIE ESM framework using the PRISM coupler]] (OASIS) using the [[GENIE_BFG|Bespoke Framework Generator (BFG)]] tool, a working implementation of Balaji's grid schema proposal is being developed.  This gridspec implementation will be used to describe the grids used by individual GENIE models, allowing BFG to generate automatically the PRISM grid initialisation code for each model required for OASIS coupling.  A draft of this gridspec is presented below.

Revision as of 14:38, 27 February 2007

Ian Henderson (I.R.Henderson@reading.ac.uk)

Gridspec introduction

The gridspec is a way of describing the grids used in Earth system models. It is intended to provide a standard format (or 'schema') for describing grids. The gridspec will have several advantages:

  • The gridspec is a formalised description of grid topography, making it suitable for use by computer programs.
  • Tools used to analyse model output data can use the information supplied in a gridspec to provide more advanced visualisation and analysis functionality to scientists, without requiring model-specific customisation.
  • Frameworks of Earth system models must transfer coupling fields between model grids. Increasingly, standard tools are being developed for model framework construction, running and coupling. The gridspec makes it easier for couplers (for instance the PRISM coupler, OASIS) to transform fields from one grid to another by providing a standard grid description that many models can be expected to use.
  • Regridding of model input or output data will be more straightforward, as it will be standards-based rather than bespoke.
  • The gridspec is designed to be extensible so that it can be used to describe many different types of grid, both extant and future.

The gridspec should be able to describe grids at different spatial resolutions, and of different shapes and structures. It should be able to cover, or be easily extended to cover, as wide a range of grids as possible.

Gridspec proposal

A gridspec proposal is currently being worked on by V. Balaji (GFDL). The proposal currently consists of a PDF document that describes the proposed standard, implemented as an extension to the NetCDF Climate and Forecast (CF) conventions, and a couple of UML class diagrams that provide a diagrammatic overview of the proposed grid schema.

As part of the work to create a version of the GENIE ESM framework using the PRISM coupler (OASIS) using the Bespoke Framework Generator (BFG) tool, a working implementation of Balaji's grid schema proposal is being developed. This gridspec implementation will be used to describe the grids used by individual GENIE models, allowing BFG to generate automatically the PRISM grid initialisation code for each model required for OASIS coupling. A draft of this gridspec is presented below.

The gridspec has been implemented as an XML schema in preference to NetCDF to fit in with the XML metadata implementation used by BFG; eventually the gridspec should be available in both NetCDF/CF and XML formats, making it accessible to a wide range of Earth system modelling tools and programs.

Draft gridspec

The XML gridspec implementation is based very closely on Balaji's gridspec proposal, UML diagrams for which can be found here (gridspec model) and here (gridspec details). For more detailed information please refer to Balaji's gridspec PDF document.

The draft XML gridspec implementation is available for download here:

The draft XML gridspec implementation is outlined in the following diagrams:

Known issues

The following issues have been identified so far:

  • Splitting up gridspec into different files for each mosaic/tile, more modular, better for point/cell IDs which are constrained to be unique across a gridspec instance file (therefore only have to be unique for the tile, rather than across tiles). Balaji says there should be separate files for each mosaic, tile and contact region, e.g. "grid_mosaic.xsd", "grid_tile.xsd", "contact_region.xsd".
  • Cell vertex data is potentially duplicated - many cells may share vertices. A list of vertices should be associated with a tile rather than a cell, then each cell contains references to these vertices rather than the vertices themselves, as is done currently for cell edges (defined by refs to two vertices, rather than duplicating the vertices themselves).
  • How and where should halo regions be described for grids that are split up into "tiles" for parallel processing? (Is this something the gridspec should cover?)
  • How should exchange grids be specified for grid tiles where coordinate axes are specified instead of individual cells (e.g. for regular grids like those used by IGCM and GOLDSTEIN)? Currently, exchange grid cells consist of references to individual cells in the overlapping grids. A similar problem may exist for boundary anchor points.
  • Gridspec needs to be extended - e.g. missing cell types for different discretisations. The use of base types/base classes should make the gridspec easy to extend. This should be the job of people who are experts on the different grids in question.

See also

External links