xdfopen filename

GrADS requires a certain amount of metadata in order to understand how to read a NetCDF/HDF-SDS data file, also called a self-describing file (SDF). The sdfopen command assumes all the metadata is internal to the self-describing file, whereas the xdfopen command allows the user to supplement or replace any internal metadata via a data descriptor file. In this way, xdfopen provides access to some self-describing files that do not comply with the COARDS conventions.

filename is the name of the data descriptor file that contains the supplemental metadata. It has a syntax very similar to the regular data descriptor files that are used with the open command. The few differences are noted below:

  1. DSET SDF_filename

    This is the only required entry. SDF_filename may be either the name of a netCDF or HDF-SDS file or a substitution template for a collection of netCDF or HDF-SDS files.

    Other than DSET, the only other data descriptor file entries that are supported are UNDEF, TITLE, XDEF, YDEF, ZDEF, TDEF, EDEF, OPTIONS, VARS, and ENDVARS. Valid arguments for the OPTIONS entry are: yrev, zrev, template, and 365_day_calendar.


    Each of these entries requires an additional argument, SDF_dimension_name, which comes before all the other arguments. The SDF_dimension_name is used to achieve dimension order independence, so it must be a real dimension in the SDF. The SDF_dimension_name string may be mixed case and should appear exactly as it is listed in the output from ncdump.

    If the coordinate variables in the SDF file exist and have the required metadata, then SDF_dimension_name is the only argument needed for the corresonding axis definition entry (XDEF, YDEF, ZDEF, TDEF, and EDEF) in the data descriptor file. If you need to supplement or override the coordinate metadata in the SDF file, you can fill out the axis definition entries in the descriptor file with the remaining arguments describing the size, linearity, start, and increment. For EDEF, there is support for three variations on the compact syntax of the EDEF entry:
    edef <SDF_dimension_name>
    edef <SDF_dimension_name> <size>
    edef <SDF_dimension_name> <size> names <list of names>

  3. The first argument ("varname") of the variable definition lines that appear between VARS and ENDVARS has the following syntax:

    SDF_varname is the name of the variable as it appears in the output from the NetCDF utility ncdump. It may be of mixed case. If it includes blanks, substitute "~" for the blanks. If everything up to and including the "=>" is omitted, then grads_varname must be identical to SDF_varname. This syntax (when "SDF_varname=>" is omitted) will only work properly in GrADS if SDF_varname is less than 15 characters and does not contain any upper case letters. As it was with the coordinate variables, if the data variables in the SDF file have the required metadata, then SDF_varname=>grads_varname is the only argument needed for the corresonding variable definition entry in the data descriptor file.

  4. The order of the variable definition lines between VARS and ENDVARS is not important.

Usage Notes

  1. If filename contains only the DSET entry, then xdfopen devolves into working just like sdfopen.
  2. filename does not need to be a full data descriptor file, it only needs to contain whatever metadata the SDF file lacks. Anything not specified in filename will be looked for in the file's internal metadata.
  3. The SDF_dimension_name parameter in the XDEF, YDEF, ZDEF, TDEF, and EDEF entries and the first parameter of the VARIABLE definition lines are the only parts of the data descriptor file that aren't converted to lower case before they are interpreted.
  4. For further information on the COARDS conventions, check out Conventions for the standardization of NetCDF files.
  5. (GrADS version 2.0.a7.1+) The CHSUB entry will work with xdfopen.


This example shows the data descriptor file that would be required in order to open a self-describing file that is missing much of the required metadata. Below is the sample data descriptor file for the NetCDF file moisture.nc. Follow this link to see output from ncdump for this file.

DSET ^moisture.nc
TITLE This is a sample 
UNDEF 99999.0
XDEF dimension1 144 LINEAR 0.0 2.5
YDEF dimension2  73 LINEAR 0.0 2.5
TDEF dimension3 365 LINEAR 0Z01JAN1979 1DY
Moisture=>moisture 1 99 Moisture

This second example comes from a real-world HDF-SDS file from the Data Assimilation Office at NASA Goddard Space Flight Center. The data descriptor file is shown below, and this link shows the output from running the HDF version of ncdump on DAOE054A.hdf. (Note that the output has been annotated with explanatory comments -- they are preceded with "//")

DSET ^DAOE054A.hdf
TITLE This is only a test
UNDEF 1.0E15
XDEF XDim:DAOgrid 144 LINEAR -180.0 2.5
YDEF YDim:DAOgrid  91 LINEAR  -90.0 2.0
ZDEF HGHT18DIMS:DAOgrid 18 LEVELS 1000 850 700 500 400 300 250 200 150 100 70 50 30 10 5 2 1 0.4
GEOPOTENTIAL_HEIGHT=>hgt 18 99 geopotential height
SPECIFICHUMIDITY=>shum 18 99 specific humidity
TEMPERATURE=>temp 18 99 temperature