Hosted by CU logo University of Colorado
Boulder
Powered by ESGF-CoG logo
Welcome, Guest. | Login | Create Account
ESMF logo
You are at the CoG-CU node
 

CF Stagger Supergrid v0.1

In this ticket we propose an addition to the GRIDSPEC (https://cf-pcmdi.llnl.gov/trac/ticket/63) convention to allow it to express multiple stagger locations at once. This is a based on the idea of a supergrid proposed by V. Balaji in this original GRIDSPEC document (http://www.gfdl.noaa.gov/~vb/gridstd/gridstdse2.html#x4-130002.6). In a supergrid specification of a grid, every possible subgrid of a grid useful for an application is stored in the grid resulting in a higher resolution grid. Depending on the application, the factor of the increase in resolution can be an arbitrary integer. In this proposal our goal is the representation of stagger locations, so we suggest starting with the supergrid necessary to represent the Arakawa grids, in which case the resolution increase is a factor of two per dimension. Further types of supergrid can be added in the future if necessary.  There are two issues that this proposal covers. The first is how to indicate that a GRIDSPEC mosaic is a supergrid. The second is how to put a variable on a given grid subset (e.g. a given stagger). 

To indicate that a CF GRIDSPEC mosaic is a supergrid we propose adding a new global attribute to the mosaic file in the GRIDSPEC convention: gridspec_mosaic_type. If this attribute is present and is set to "mosaic_type_stagger_all", then that would indicate that the mosaic represents the combination of all the staggers (e.g. the supergrid), and thus all of its tiles are supergrids (In the future, other types of supergrid could be indicated using the mosaic_type attribute as well). In the case where there isn't a mosaic file, but just a single tile file, then we propose the new attribute: gridspec_tile_type which could be added to tile files if there isn't a mosaic file. If this attribute is present and is set to "tile_type_stagger_all" then it would indicate that the tile represents a supergrid containing all the staggers. In the case where there is both a gridspec_mosaic_type attribute and a gridspec_tile_type attribute then the gridspec_tile_type would take precedence and override the gridspec_mosaic_type for that tile. 

 

 To define a data variable on a subset of a mosaic (e.g. for an individual stagger in a supergrid) the user needs a way to indicate which part of the grid they want to include in the subset. This requires two pieces: a pointer to the tile which contains the coordinates, and a way to indicate the subset of the points in that tile on which the data variable is located. The current GRIDSPEC attribute: gridspec_tile_name handles the first piece by pointing to the tile. The index scheme defined in Balaji's original proposal (see: http://www.gfdl.noaa.gov/~vb/gridstd/gridstdse3.html#x5-260003.6) would be a good way to handle the second piece as it is very general. In this scheme, the user defines extra variables which contain a list of the locations in a mosaic tile on which the data variable lies. However, in Balaj's proposal for representing a subset of grid,  there isn't a way to get from the data variable to the index scheme which describes what subset it is of the tile. It would be useful to have a way to do this as it would allow the definition of multiple index schemes in a file for variables to access. To do this we propose having an attribute attached to the data variable which points to the index scheme for each dimension.  For example, for variable temp, you could have something like temp:gridspec_index_scheme="nx_index_corner:ny_index_corner", which would indicate that the user should use array nx_index_corner for the first dimension locations and array ny_index_corner for the second dimension locations. If no temp:gridspec_index_scheme variable is present then the variable would be assumed to be over the entire tile.  The variable attribute "gridspec_stagger" is attached to the index_scheme variables to indicate which stagger they are describing. A set of standard stagger names used in this attribute could be added to CF.  

 

The below is an example of how the custom index scheme would look:

 

-------

 

dimensions:

  nx=45;

  ny=46;

 

variables:

  int nx_index_corner(nx);

     nx_index_corner:gridspec_stagger="corner";

  int ny_index_corner(ny);

     ny_index_corner:gridspec_stagger="corner";

  float temp(nx,ny);

     temp:gridspec_index_scheme="nx_index_corner:ny_index_corner";

     

  

GLOBAL ATTRIBUTES:

     gridspec_tile_name="tile1";

 

nx_index_corner=1,3,5,...;

ny_index_corner=1,3,5,...;

 

------

 

 

To make things even easier we could predefine some index schemes, so if the user was doing something common like corners, centers, etc. then they could use a standardized set of names in the temp:gridspec_index_scheme attribute without having to define the indexing themselves (e.g. gridspec_indexscheme_center, gridspec_indexscheme_corner…). The good thing about giving users the ability of defining their own, but also predefining typical cases is that it allows full generality, but also gives an easy road if they're doing something common. This has worked well with how we do stagger locations in ESMF. Having standard index schemes for common staggers would also indicate to other users which stagger in the super grid a variable was defined on in an interoperable way. 

 

The below is an example of how using a standard index scheme would look:

 

------

 

dimensions:

  nx=45;

  ny=46;

 

variables:

  float temp(nx,ny);

     temp:gridspec_index_scheme="gridspec_indexscheme_corner:gridspec_indexscheme_corner";

  

GLOBAL ATTRIBUTES:

     gridspec_tile_name="tile1";

 

------

Last Update: March 10, 2013, 8:30 p.m. by Hydra Administrator