wiki:use-cases/CaptureGridDefinition

Use-Case: Capture a Grid Definition


Author: Phil Bentley
Version: 0.1
Date: 29 April 2009
Associated Work Packages: WP4, WP6

Purpose: Describes a number of possible scenarios for capturing the definition of the grid coordinate system associated with a model or dataset.

Actors: DataManager, MetadataManager, OnlineQuestionnaire, QuestionnaireDatabase, CMIP5Archive

Related Use-Cases:

None known

Summary:

This use-case describes a handful of scenarios whereby a DataManager or MetadataManager actor undertakes the process of capturing a definition of the grid coordinate system associated with a climate model and/or dataset.

It is anticipated that METAFOR partners may (and probably will) devise additional local mechanisms for capturing and managing grid-related information. Modelling centres that do not have the capability, time or desire to develop an in-house solution will be able to use the METAFOR online questionnaire described in scenario 1.

Important Note: The use-case scenarios described below relate only to the definition of qualitative-descriptive metadata associated with model and dataset grids. The scenarios are not intended to describe how quantitative coordinate system information will be encoded in the netCDF files that will be accessible from the CMIP5 data archive. The tools and workflow sequence for managing the latter have yet to be finalised and published (as far as is known to the author).

Scenario 1: Use METAFOR questionnaire

Scenario 1

Figure 1. Grid definition scenario 1

  1. The actor logs in to the METAFOR online questionnaire application.
  2. The actor selects an existing metadata object (e.g. a climate model definition), or else creates a new one.
  3. The actor enters or updates the desired grid definition together with any other additional metadata (e.g. software, activity) as required.
  4. The actor saves the metadata entry and exits the online questionnaire.
  5. At some later time the grid definition stored in the Questionnaire Database is used in the generation of a CIM-compliant XML document. This could either be a stand-alone grid definition document or else a complete CIM document (e.g. activity + model + grid).
  6. The CIM XML document is transmitted to the CMIP5 archive (and potentially other destinations, if desired).

Note: The metadata information stored in the Questionnaire Database could, of course, be used for a range of other purposes, not just the generation of CIM-compliant outputs.

Scenario 2: Use local metadata capture solution

Scenario 2

Figure 2. Grid definition scenario 2

  1. The actor logs in to a local metadata capture form, as indicated by the item 'In-house Metadata Entry Form' in Figure 2.
  2. The actor uses this metadata capture application to create a new, or modify an existing, grid definition.
  3. The grid definition is saved into a local in-house metadata database.
  4. At some later time the grid definition stored in the metadata database is used in the generation of a CIM-compliant XML document. As before, this could either be a stand-alone grid definition document or else a complete CIM document.
  5. Optionally, the grid definition stored in the in-house metadata database may also be used to set, or update, grid-related attributes held in the netCDF data files destined to be transmitted to the CMIP5 archive.
  6. The CIM XML document, and optionally any netCDF files, are transmitted to the CMIP5 archive (and potentially other destinations, if desired).

Note: This scenario is envisaged as being the one adopted by the Met Office Hadley Centre. We expect to store a variety of metadata objects in a relational database environment. This will probably be a superset of the metadata items required for the CIM. At appropriate times we will generate CIM-compliant outputs - i.e. XML documents - on an as-needs basis.

Scenario 3: Use GFDL gridspec tools

Scenario 3

Figure 3. Grid definition scenario 3

  1. The actor uses the  gridspec tools developed at GFDL to create netCDF files that contain a definition of one or more grid mosaics (these netCDF files store the grid coordinates as well as the metadata describing the grid coordinate system).
  2. A locally-developed tool (indicated by the 'extract grid metadata item' in Figure 3) may then be used to extract relevant pieces of the grid metadata stored in the netCDF files and copy them to a local metadata database and/or use them in the generation of a CIM-compliant XML document.
    1. Alternatively the local metadata extraction tool could write only to the in-house metadata database and a second utility could then be used to generate CIM-compliant XML documents from that database.
  3. The CIM XML document, and optionally any netCDF files, are transmitted to the CMIP5 archive (and potentially other destinations, if desired).

Note: This scenario is, I believe, the preferred approach that GFDL plans to adopt.

Pre-Conditions

  • The DataManager or MetadataManager actor must be an authorised user of the METAFOR online questionnaire application or the in-house metadata solution.

Post-Conditions

  • A grid definition record conforming to the CIM conceptual model captured either in the METAFOR questionnaire database or else in a locally-maintained, institute-specific metadata database.

Miscellaneous Notes:

The CMIP5 Archive item is intended to represent any of the federated CMIP5 data nodes, i.e. PCMDI, BADC, or MPI.

Use-Case Diagrams:

None. But see figures above.

Attachments