1. Title

GRIDSPEC to aggregate block-structured and time dependent data

2. Moderator

Balaji (v.balaji@…)

3. Requirement

Current conventions support logical rectangular data stored in a single file. The proposed extension will allow users to aggregate data stored in multiple files, whether the data represent different time slices or are associated with different logically rectangular grids as in the case of the cubed sphere mosaic for instance.

4. Initial Statement of Technical Proposal

GRIDSPEC comprises of two parts: M-SPEC for representing the grid connectivity in mosaics and F-SPEC for time and mosaic data aggregation.

For M-SPEC, a mosaic file contains the list of files where grid information can be extracted with inter-tile connectivity information provided as a map between the set of indices on one tile to indices on the neighbouring tile. This covers both surfacial and volumetric coupling. The former arises for instance when two three-dimensional grids share a surface while the latter arises when the grids are overlapping.

The F-SPEC describes the format of the host file, which acts as a single entry point to the aggregation. Variable data scattered among many files appear as one logical entity when viewed through the host file. Brittleness, in other words the fragility of the aggregation resulting from inadvertent file corruption, file movement and other file operations, is minimized by consolidating all the file names in the host file, which can be straightforwardly re-generated by scanning directories and inspecting the global attributes of the files residing therein.

5. Benefits

Data producers will be able to store data in multiple files while allowing data consumers to access the data as if all the data were stored in a single file.

A number of codes are moving away from longitude-latitude grids because of the singularity of such grids at the pole, which can cause severe limitations in the maximum time steps than models can take. M-SPEC will allow atmospheric and ocean models to store data on their native grids, without having to incur inaccuracies due to lon-lat regridding.

6. Detailed Proposal

Because of the length of this proposal, a separate ​web page was created to explain in more details our proposed enhancements. The web page contains many examples and is supported by illustrations.

In section 7.3. Cell Methods there are 3 references to "cell_bounds" that should be "bounds" instead (including one reference in 7.3.2).

1. New cell_methods of range

2. Moderator

Alison Pamment

3. Requirement

Provide a way to indicate that the data value for an element of data variable is the range of values (the absolute difference between the maximum and the minimum) that occur within the cell.

4. Initial Statement of Technical Proposal

Add a entry in the table of Appendix E, as follows

The choice of the word range is consistent with the existing cell_methods of mid_range.

5. Benefits

The particular use case which motivated the proposal was provided by José María Rodríguez González, who wished to describe the diurnal range of surface air temperature. With the new convention, this could be described by cell_methods="time: range" with a time coordinate variable whose bounds specified daily intervals. This new use of cell_methods corresponds to the use of maximum and minimum to describe the daily maximum and daily minimum temperature.

6. Status Quo

Using the long_name is the most likely alternative.