下载文档原格式
grads处理多个ctl文件和nc文件2011-10-10 21:03:59| 分类：grads学习| 标签：|举报|字号大中小订阅下载LOFTER我的照片书 |用grads处理多个相同格式的数据时若单个单个处理非常麻烦，当文件非常多的时候是单个处理是不实际的。
下面介绍一种方法;第一步，在这种情况下可以重新写一个ctl描述文件，其文件变量都和已知的ctl相同，若原来的n 文件只是时间不同，那么新描述文件的时间维数是所有原文件的时间的和。
同样，若其他维数不同时也用同样的方法处理。
第二步，在第一行之后添加一行：options template 表示多个时间序列原始数据文件想用一个描述文件统一地描述。
这些原数据的原文件名由dset定义的形势命名文件名。
第三步，修改dset 的文件名。
原路径不变，把文件名用％表示。
其中：％y2 代表两位数年％y4 代表四位数年％m1 代表一位或者两位数的月％m2 代表两位数月（用0补齐1位数）％mc 3个字符月份的缩写％d1 1或2位天％d2 两位天％h1 1或者2位时％h2 2位时例如：原文件其中之一的文件名为gdas2006050812f00，且所有文件只有天和时的变化那么新描述文件的文件名为：gdas200605%d2%h2f00另外如果源文件里有index项的话，需要修改其idx的文件名，假设改成fnl.idx。
并用在dos下用gribmap函数生成一个新的idx文件。
gribmap -e -i fnl.ctl（加绝对路径）open fnl.ctl就可以打开所有文件。
*************************************************************************************************************** *******************若想要提取从1951-2006年56年nc文件中的某些数据，一个一个处理非常麻烦，这里介绍种较为简易的方法。
GrADS读取NetCDF和HDF的ctl⽂件SDF⽂件的描述⽂件翻译⾃使⽤GrADS阅读NetCDF和HDF⽂件NetCDF和HDF格式的⽂件被称作⾃描述⽂件(self-describing file, SDF)，因为数据和元数据⼀块保存在同⼀个⽂件中。
GrADS可以读取NetCDF和HDF格式的⽂件，只要数据是存储在⼀个规范⽹格。
HDF格式是⾮常通⽤的；GrADS接⼝仅适⽤于5-D的(lon/lat/lev/time/ensemble)⽹格化数据集。
GrADS处理HDF4科学数据集和部分HDF5⽂件。
为了读取⾃描述⽂件SDF，GrADS需要⼀个特定的源数据为了将，GrADS需要⼀定数量的元数据，从⽽将数据放置在内部⽹格空间中。
有三种⽅式可以做到这些：1. 使⽤命令打开⽂件。
这为⽤户省去了最少的⼯作-只需提供⽂件名（或OPeNDAP URL），其余的⼯作由GrADS完成。
如果使⽤sdfopen命令打开SDF，则GrADS所需的⽂件中的所有元数据都必须符合。
"sdfopen"界⾯不⽀持HDF5格式。
如果sdfopen不起作⽤，则...2. 使⽤命令打开⽂件。
这需要进⾏更多的⼯作-您必须编写⼀个数据描述⽂件来补充或替换现有的元数据，以便GrADS能够理解它。
xdfopen使⽤的描述符⽂件的语法与栅格化⼆进制数据(gridded binary data)的描述符⽂件中使⽤的语法不完全相同-有关更多详细信息，请参见。
xdfopen命令提供对更多SDF⽂件的访问，包括许多不符合任何已知标准的SDF。
"xdfopen"界⾯不⽀持HDF5格式。
如果xdfopen不起作⽤，则...3. 使⽤命令打开⽂件。
这要求⽤户编写⼀个完整的GrADS描述符⽂件，以覆盖⽂件中的所有元数据。
下⾯给出了为NetCDF，HDF-SDS或HDF5⽹格数据⽂件组成完整描述符⽂件的指南。
另请参考。
grads批处理ctl文件和用cmd生成idx文件的步骤(2009-07-31 14:30:09)
分类：科研笔记标签：grads软件ctl idx批处理气
象教育
一：grads批处理涉及idx文件的grib资料时，编辑grads批处理所需要的ctl文件：（一般可以把已存在的第一个时次的ctl文件进行更改后另存为一个新的ctl文件即可，比如本次批处理的原来的ctl名字都是200206xxxx.ctl形式，则可以新建一个200206.ctl 作为grads将来要调用的ctl文件）
）
grib200206%d2%h2时间循环
options template多个时间序列原始数据文件想用一个数据描述文件统一地描述这些原始数据时采用的选项。
必不可少，且注意其位置。
grib200206.idx将要生成的idx文件
120本次批处理总共的时次个数
00Z01jun2002批处理的起始时间
6hr相邻时次的时间间隔
其他的部分不需要更改。
二：用cmd生成idx文件
进入cmd界面
“>”后输入’gribmap –e’，然后回车键，出现以下界面
提示行后输入ctl文件的路径和名字
按回车键后开始运行
运行结束后显示以下界面，idx文件生成。
至此，有了ctl文件和idx文件，然后就可以用GrADS软件快速方便的进行批处理了。
Components of a GrADS Data Descriptor FileDSET data_filenameback to topThis entry specifies the filename of the data file being described. If the data and the descriptor file are not in the same directory, then data_filename must include a full path. If a ^ character is placed in front of data_filename,then data_filename is assumed to be relative to the path of the descriptor file. If you are using the ^ character in the DSET entry, then the descriptor file and the data file may be moved to a new directory without changing any entries in the data descriptor file, provided their relative paths remain the same. For example:If the data descriptor file is:/data/wx/grads/sa.ctland the binary data file is:/data/wx/grads/sa.datthen the data file name in the data descriptor file can be:DSET ^sa.datinstead of:DSET /data/wx/grads/sa.datIf data_filename does not include a full path or a ^, then GrADS will only look for data files in the directory where you are running GrADS.GrADS allows you use a single DSET entry to aggregate multiple data files and handle them as if they were one individual file. The individual data files must be identical in all dimensions except time, and the time range of each individual file must be indicated it its filename. To accomplish this, the DSET entry has a substitution template instead of a filename. See the section on Using Templates for a description of all the possible components of the template. Second, the OPTIONS entry must contain the template keyword.CHSUB t1 t2 stringback to top(GrADS version 1.9b4) This entry is used with a new option for templating data files that allows for any user-specified string substitution, instead of only date string substitution. This is useful when none of the standard template options match the time ranges in the files you wish to aggregate, or if the files are located on different disks. When you put the %ch template inyour DSET entry, then you also need to put additional CHSUB entries in the descriptor file. The string will be substituted for%ch in the data file name for the time steps beginning with t1 and ending with t2.See the section on Using Templates for examples.DTYPE keywordback to topThe DTYPE entry specifies the type of data being described. There are four options: grib, hdfsds, netcdf, or station. If the data type is none of these, then the DTYPE entry is omitted completely from the descriptor file and GrADS will assume the data type is gridded binary.bufr (GrADS version 1.9) Data file is a BUFR station data file. This data type must be accompanied by the following special entries: XVAR, YVAR, TVAR, STID. Optional special entries are: ZVAR, TOFFVAR.grib Data file is an indexed GRIB (version 1) file. This data type requires a secondary entry in the descriptor file:INDEX. The INDEX entry provides the filename (including the full path or a ^) for the GRIB index file. Theindex file is created by the gribmap utility. You must run gribmap and create the index file before you candisplay the GRIB data in GrADS.grib2 (GrADS version 2.0) Data file is an indexed GRIB2 file. This data type requires a secondary entry in the descriptor file: : INDEX. The INDEX entry provides the filename (including the full path or a ^) for the GRIB2index file. The index file is created by the gribmap utility. You must run grib2map and create the index filebefore you can display the GRIB2 data in GrADS.hdfsds (GrADS version 1.9) Data file is an HDF Scientific Data Set (SDS). Although HDF-SDS files are self-describing and may be read automatically using the sdfopen/xdfopen commands, this DTYPE gives youthe option of overriding the file's own metadata and creating a descriptor file for some or all of the variablesin the file. This DTYPE may also be used if the metadata in the HDF-SDS file is insufficient or is notcoards-compliant. This data type requires a special entry in the units field of the variabledeclaration. The undef and unpack entries contain special options for this dtype.hdf5_grid (GrADS version 2.0.a7+) Data file is HDF5 gridded format. The HDF5 format is extremely general and is designed to store a variety of data types. The GrADS interface is only for grids, and requires a completedescriptor file -- there is no sdfopen/xdfopen interface for HDF5.netcdf (GrADS version 1.9) Data file is NetCDF. Although NetCDF files are self-describing and may be read automatically using the sdfopen/xdfopen commands, this DTYPE gives you the option of overriding the file'sown metadata and creating a descriptor file for some or all of the variables in the file. This DTYPE may alsobe used if the metadata in the NetCDF file is insufficient or is not coards-compliant. This data type requires aspecial entry in the units field of the variable declaration. The undef and unpack entries contain specialoptions for this dtype.station Data file is in GrADS station data format. This data type requires a secondary entry in the descriptor file: STNMAP. The STNMAP entry provides the filename (including the full path or a ^) for the station data mapfile. The map file is created by the stnmap utility. You must run stnmap and create the map file before youcan display the station data in GrADS.INDEX filenameback to topThis entry specifies the name of the grib map file. It is required when using the DTYPE grib or grib2 entry to read GRIB formatted data. The file is generated by running the external utility gribmap. or grib2map. Filenaming conventions are the same as those described for the DSET entry.STNMAP filenameback to topThis entry specifies the name of the station map file. It is required when using the DTYPE station entry to readGrADS-formatted station data. The file is generated by running the external utility stnmap. Filenaming conventions are thesame as those described for the DSET entry.TITLE stringback to topThis entry gives brief description of the contents of the data set. String will be included in the output from a query command and it will appear in the directory listing if you are serving this data file with the GrADS-DODS Server (GDS), so it is helpful to put meaningful information in the title field. For GDS use, do not use double quotation marks (") in the title.UNDEF value<undef_attribute_name>back to topThis entry specifies the undefined or missing data value. UNDEF is a required entry even if there are no undefined data. GrADS operations and graphics routines will ignore data with this value from this data set.(GrADS version 1.9b4) An optional second argument has been added for data sets of DTYPE netcdf or hdfsds -- it is the name of the attribute that contains the undefined value. This should be used when individual variables in the data file have different undefined values. After data I/O, the missing values in the grid are converted from the variable undef to the file-wide undef (the numerical value in the first argument of the UNDEF record). Then it appears to GrADS that all variables have the same undef value, even if they don't in the original data file. If the data require a transformation using the attributes named in the UNPACK entry, GrADS assumes the variable undef value corresponds to the data values as they appear in the file,i.e.,before they are transformed using a scale factor and offset. Missing packed data values are thus assigned the file-wide undef value and are never unpacked. Attribute names are case sensitive, and it is assumed that the name is identical for all variables in the netcdf or hdfsds data file. If the name given does not match any attributes, or if no name is given, the file-wide undef value will be used.Example: UNDEF 1e+33 _FillValueUNPACK scale_factor_attribute_name <add_offset_attribute_name>back to top(GrADS version 1.9) This entry is used with DTYPE netcdf, hdfsds, or hdf5_grid (GrADS version 2.0.a7+) for data variables that are 'packed' -- i.e. non-float data that need to be converted to float by applying the following formula:y = x * scale_factor + add_offsetIf your self-describing file does not have an offset attribute, the 2nd argument may be omitted, and the offset will be assigned the default value of 0.0. If your self-describing file has an offset attribute, but not a scale factor, use "NULL" forthe scale_factor_attribute_name. (This "NULL" option is in GrADS version 2.0.0+). Attribute names are case sensitive, and it is assumed that the names are identical for all variables in the netcdf or hdfsds data file. If the names given do not match any attributes, the scale factor will be assigned a value of 1.0 and the offset will be assigned a value of 0.0. The transformation of packed data is done after the undef test has been applied.Examples:UNPACK scale_factor add_offsetUNPACK NULL add_offsetUNPACK Slope InterceptFILEHEADER lengthback to topThis optional entry tells GrADS that your data file has a header record of length bytes that precedes the data. GrADS will skip past this header, then treat the remaineder of the file as though it were a normal GrADS binary file after that point. This optional descriptor file entry is only valid for GrADS gridded data sets.THEADER length HEADERBYTES length<back to topThese two equivalent optional entries tell GrADS that the data file has a header record of length bytes preceding each time block of binary data. Use one or the other but not both. These entries are only valid for GrADS gridded data sets. See the section on structure of a gridded binary data file for more information.TRAILERBYTES lengthback to topThis optional entry tell GrADS that the data file has a trailer record of length bytes following each time block of binary data. This entry is only valid for GrADS gridded data sets. See the section on structure of a gridded binary data file for more information.XYHEADER lengthback to topThis optional entry tells GrADS that the data file has a header record of length bytes preceding each horizontal grid (XY block) of binary data. This entry is only valid for GrADS gridded data sets. See the section on structure of a gridded binary datafile for more information.XVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station's longitude. This entry is required for DTYPE bufr.YVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station's latitude. This entry is required for DTYPE bufr.ZVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station data's vertical coordinate (e.g., pressure). This is an optional entry for DTYPE bufr.STID x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station ID. This entry is required for DTYPE bufr.TVAR yr x,y mo x,y dy x,y hr x,y mn x,y sc x,yback to top(GrADS version 1.9) This entry provides the x,y pairs for all the base time coordinate variables. Each time unit (year=yr, month=mo, day=dy, hour=hr, minute=mn, second=sc) is presented as a 2-letter abbreviation followed by the x,y pair that goes with that time unit. The time for any individual station report is the base time plus the offset time (see TOFFVAR). All six base time units are not required to appear in the TVAR record, only those that are in the data file. This entry is requiredfor DTYPE bufr.TOFFVAR yr x,y mo x,y dy x,y hr x,y mn x,y sc x,yback to top(GrADS version 1.9) This entry provides the x,y pairs for all the offset time coordinate variables. The syntax is the same as TVAR. The time for any individual station report is the base time plus the offset time. All six offset time units are not required to appear in the TOFFVAR record, only those that are in the data file. This is an optional entry for DTYPE bufr.CACHESIZE bytesback to top(GrADS version 2.0.a8+) This entry overrides the default size of the cache for reading HDF5 or NetCDF4 files. It is not relevant for other data types. It should not be necessary to set the cache size explicitly unless the data file has especially large chunks. Please see the documentation on compression.OPTIONS keywordback to topThis entry controls various aspects of the way GrADS interprets the raw data file. It replaces the old FORMAT record.The keyword argument may be one or more of the following:pascals (GrADS version 2.0) (For DTYPE grib2 only) Indicates that pressure values that appear in the descriptor file (in the ZDEF entry and in the GRIB2 codes in the variable declarations) are given inunits of Pascals. The gribmap utility requires pressure to be given in Pascals. If this keyword ispresent, the pressure level values will be converted to millibars after the gribmap index is generatedand the descriptor file is opened with GrADS. If this keyword is omitted, pressure levels will remain inPascals, and many of the internal functions (which assume a vertical dimension in units of millibars)will not work properly.yrev Indicates that the Y dimension (latitude) in the data file has been written in the reverse order from what GrADS assumes. An important thing to remember is that GrADS still presents the view that thedata goes from south to north. The YDEF statement does not change; it still describes thetransformation from a grid space going from south to north. The reversal of the Y axis is done as thedata is read from the data file.zrev Indicates that the Z dimension (pressure) in the data file has been written from top to bottom, rather than from bottom to top as GrADS assumes. The same considerations as noted above for yrev alsoapply.template Indicates that a template for multiple data files is in use. For more information, see the section on Using Templates.sequential Indicates that the file was written in sequential unformatted I/O. This keyword may be used with either station or gridded data. If your gridded data is written in sequential format, then each record must bean X-Y varying grid. If you have only one X and one Y dimension in your file, then each record in thefile will be one element long (it may not be a good idea to write the file this way).365_day_calendar Indicates the data file was created with perpetual 365-day years, with no leap years. This is used for some types of model ouput.byteswapped Indicates the binary data file is in reverse byte order from the normal byte order of your machine.Putting this keyword in the OPTIONS record of the descriptor file tells GrADS to swap the byte orderas the data is being read. May be used with gridded or station data.The best way to ensure hardware independence for gridded data is to specify the data's source platform. This facilitates moving data files and their descriptor files between machines; the data may be used on any type of hardware without having to worry about byte ordering. The following three OPTIONS keywords are used to describe the byte ordering of a gridded or station data file:big_endian Indicates the data file contains 32-bit IEEE floats created on a big endian platform (e.g., sun, sgi)little_endian Indicates the data file contains 32-bit IEEE floats created on a little endian platform (e.g., iX86, and dec)cray_32bit_ieee Indicates the data file contains 32-bit IEEE floats created on a cray.PDEFback to topPDEF is so powerful it has its own documentation page.XDEF xnum mapping <additional arguments>back to topThis entry defines the grid point values for the X dimension, or longitude. The first argument, xnum, specifies the number of grid points in the X direction. xnum must be an integer >= 1. mapping defines the method by which longitudes are assigned to X grid points. There are two options for mapping:LINEAR Linear mappingLEVELS Longitudes specified individuallyThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the longitude at grid point X=1. Negative values indicate western longitudes. increment is the spacing between grid point values, given as a positive floating point value.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the longitude value for each grid point. value-list should contain xnum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters. There must be at least 2 levels in value-list; otherwise use the LINEAR method.Here are some examples:XDEF 144LINEAR 0.0 2.5XDEF 72LINEAR 0.0 5.0XDEF 12LEVELS 0 30 60 90 120 150 180 210 240 270 300 330XDEF 12LEVELS 15 45 75 105 135 165 195 225 255 285 315 345YDEF ynum mapping <additional arguments>back to topThis entry defines the grid point values for the Y dimension, or latitude. The first argument, ynum, specifies the number of gridpoints in the Y direction. ynum must be an integer >= 1. mapping defines the method by which latitudes are assigned to Y grid points. There are several options for mapping:LINEAR Linear mappingLEVELS Latitudes specified individuallyGAUST62 Gaussian T62 latitudesGAUSR15 Gaussian R15 latitudesGAUSR20 Gaussian R20 latitudesGAUSR30 Gaussian R30 latitudesGAUSR40 Gaussian R40 latitudesThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the latitude at grid point Y=1. Negative values indicate southern latitides. increment is the spacing between grid point values in the Y direction. It is assumed that the Y dimension values go from south to north, so increment is always positive.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the latitude for each grid point, from south to north. value-list should contain ynum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters. There must be at least 2 levels in value-list; otherwise use the LINEAR method.The Gaussian mapping methods require one additional argument: start. This argument indicates the first gaussian grid number. If the data span all latitudes, start would be 1, indicating the southernmost gaussian grid latitude.Here are some examples:YDEF 73LINEAR -90 2.5YDEF 180LINEAR -90 1.0YDEF 18LEVELS -85 -75 -65 -55 -45 -35 -25 -15 -5 5 15 25 35 45 55 65 75 85YDEF 94GAUST62 1YDEF 20GAUSR40 15The NCEP/NCAR Reanalysis surface variables are on the GAUST62 grid.The final example shows that there are 20 Y dimension values which start at Gaussian Latitude 15 (64.10 south) on the Gaussian R40 gridZDEF znum mapping <additional arguments>back to topThis entry defines the grid point values for the Z dimension. The first argument, znum, specifies the number of pressure levels. znum must be an integer >= 1. mapping defines the method by which level values are assigned to Z grid points. There are two options for mapping:LINEAR Linear mappingLEVELS Pressure levels specified individuallyThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the level value at grid point Z=1. increment is the spacing between grid point values in the Z direction, or from lower to higher. increment must be non-zero and non0negative.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the pressure level for each grid point in ascending order. value-list should contain znum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters.Here are some examples:ZDEF 7LEVELS 1000 850 700 500 300 200 100ZDEF 17LEVELS 1000 925 850 700 600 500 400 300 250 200 150 100 70 50(GrADS version 2.0) (For DTYPE grib2 only) If your Z axis is pressure, the gribmap utility requires the level values to be given in units of Pascals instead of millibars. Use the "options pascals" keyword to convert the unit of the level values to millibars after the gribmap index is generated and when the descriptor file is opened with GrADS. Pressure level values may remain in Pascals, but then many of the internal functions (which assume a vertical dimension in units of millibars) will not work properly.TDEF tnum LINEAR start incrementback to topThis entry defines the grid point values for the T dimension. The first argument, tnum, specifies the number of timesteps.tnum must be an integer >= 1. The method by which times are assigned to T grid points is always LINEAR.start indicates the initial time value at grid point T=1. start must be specified in the GrADS absolute date/time format:hh:mm Z ddmmmyyyywhere:hh = hour (two digit integer)mm = minute (two digit integer)dd = day (one or two digit integer)mmm = 3-character monthyyyy = year (may be a two or four digit integer; 2 digits implies a year between 1950 and 2049)If not specified, hh defaults to 00, mm defaults to 00, and dd defaults to 1. The month and year must be specified. No intervening blanks are allowed in the GrADS absolute date/time format.increment is the spacing between grid point values in the T direction. increment must be specified in the GrADS absolute time increment format:vvkkwhere:vv = an integer number, 1 or 2 digitskk = mn (minute)hr (hour)dy (day)mo (month)yr (year)Here are some examples:TDEF 60LINEAR 00Z31dec1999 1mnTDEF 73LINEAR 3jan1989 5dyTDEF 730LINEAR 00z1jan1990 12hrTDEF 12LINEAR 1jan2000 1moTDEF 365LINEAR 12Z1jan1959 1dyTDEF 40LINEAR 1jan1950 1yrEDEF enum NAMES <list of names>back to topEDEF enumensemble_record_1 ensemble_record_2 ...ensemble_record_enum ENDEDEFback to top(GrADS version 2.0) This entry defines the ensemble dimension. All ensemble members must have identical X, Y, and Z dimensions, the same list of variables, and the same time axis increment. There are two different syntaxes for the EDEF entry: the first is simpler and requires only the names for each ensemble member, the second expanded form contains a name, individual time axis information, and optional GRIB2 codes.Both EDEF syntaxes begin with the enum argument, an integer >=1 which specifies the number of ensemble members.If all of the ensemble members have an identical time axis (i.e. length, initial time, and increment are the same for each one), then it is only necessary to distinguish the ensembles by their names, and the simplified EDEF syntax with the NAMES keyword may be used. A simple space-delimited list of names is all that is required. Ensemble names must have between 1 and 15 alphanumeric characters, lower case only. (In version 2.0.0 and later, mixed case ensemble names are allowed). Some examples are:EDEF 10NAMES 1 2 3 4 5 6 7 8 9 10EDEF 12NAMES m01 m02 m03 m04 m05 m06 m07 m08 m09 m10 m11 ensmEDEF 7NAMES e1 e2 e3 e4 e5 e6 e7When the OPTIONS TEMPLATE entry is used with EDEF, the ensemble names are used in the %e substitution template to generate the file name. See Using Templates for more details.If the ensemble members do not have identical time axes (i.e., their lengths or initial times are not the same), or if you need to include the GRIB2 codes, then you must use the expanded EDEF syntax: a collection of records framed by EDEF and ENDEDEF. The format of the ensemble records is as follows:ensname length start <grib2 codes>The ensname is the 1-15 character "name" for the ensemble member. The length is the size of the time axis of the ensemble, which must be less than or equal to the tnum argument in the TDEF entry. (The time axis described by TDEF must span all the ensemble members.) The start argument is the initial time of the ensemble member and must be given in GrADS absolute date/time format. (See TDEF for details).The grib2 codes are required if (1) the DTYPE is grib2 and (2) there is more than one ensemble member (enum > 1). The expanded form of the EDEF entry must be used when grib2 codes are required, even if the length and start times are the same for all members. For GRIB2 ensembles, support currently exists for four different Product Definition Template (PDT) numbers: 1, 2, 11, and 12. These are grouped into two types: individual ensemble forecasts (PDT 1 and 11) or derived forecasts based on all ensemble members (PDT 2 and 12). For individual ensemble forecasts (PDT 1 and 11), twocomma-delimited grib2 codes are required: the ensemble type and perturbation number. For derived forecasts based on all ensemble members (PDT 2 and 12), only one grib2 code is required: the derived forecast. Clarification of all the GRIB2 nomenclature may be found in the documentation at WMO and NCEP. Two examples are given below.The first example illustrates ensemble members with different lengths and start times:TDEF 591 linear 12z09dec1980 12hrEDEF 16ensm 591 12z09dec1980m01 591 12z09dec1980m02 589 12z10dec1980m03 587 12z11dec1980m04 585 12z12dec1980m05 583 12z13dec1980m06 571 12z19dec1980m07 569 12z20dec1980m08 567 12z21dec1980m09 565 12z22dec1980m10 563 12z23dec1980m11 549 12z30dec1980m12 547 12z31dec1980m13 545 12z01jan1981m14 543 12z02jan1981m15 541 12z03jan1981ENDEDEFThe second example illustrates the use of GRIB2 codes:TDEF 31 linear 00z24apr2007 12hrEDEF 23p01 31 00z24apr2007 3,1p02 31 00z24apr2007 3,2p03 31 00z24apr2007 3,3p04 31 00z24apr2007 3,4p05 31 00z24apr2007 3,5p06 31 00z24apr2007 3,6p07 31 00z24apr2007 3,7p08 31 00z24apr2007 3,8p09 31 00z24apr2007 3,9p10 31 00z24apr2007 3,10p11 31 00z24apr2007 3,11p12 31 00z24apr2007 3,12p13 31 00z24apr2007 3,13p14 31 00z24apr2007 3,14p15 31 00z24apr2007 3,15p16 31 00z24apr2007 3,16p17 31 00z24apr2007 3,17p18 31 00z24apr2007 3,18p19 31 00z24apr2007 3,19p20 31 00z24apr2007 3,20c00 31 00z24apr2007 1,0avg 31 00z24apr2007 0spr 31 00z24apr2007 2ENDEDEFVECTORPAIRS U-component,V-componentback to top(GrADS version 1.9b4) This entry is for explicity identifying vector component pairs. This is only necessary if the data are on a native projection other than lat/lon (i.e. you are using PDEF) and if the winds have to be rotated from a grid-relative sense to an Earth-relative sense. (GrADS has to retrieve both the u and v component in order to do the rotation calculation.)Using this entry replaces the old technique of putting 33 (for U) or 34 (for V) in the first element of the units field in the variable declaration. The U-component and V-component arguments should be variable names that appear in the VARS list. They are separated by a comma, with no spaces. More than one pair of components may be listed; in this case, the pairs should be separated by a space. For example:VECTORPAIRS u,v u10,v10 uflx,vflxVARS varnum variable_record_1back to topvariable_record_2...variable_record_varnumENDVARSThis ensemble of entries describes all the variables contained in the data set. varnum indicates the number of variables in the data set and is therefore also equal to the number of variable records that are listed between the VARS and ENDVARS entries. ENDVARS must be the final line of the Grads data descriptor file. Any blank lines after the ENDVARS statement may cause open to fail!The format of the variable records is as follows:varname levs units description (Version 2.0.1 or earlier)varname levs <additional_codes> units description (Version 2.0.2 or later)The syntax of varname and units is different depending on what kind of data format (DTYPE) you are describing.The<additional_codes> are only necessary for certain types of GRIB2 data sets. Details provided below:varname This is a 1-15 character "name" or abbreviation for the data variable. varname may contain alphabetic and numeric characters but it must start with an alphabetic character (a-z).varname (DTYPE netcdf, hdfsds, orhdf5_grid) (GrADS version 1.9+) For DTYPE netcdf or hdfsds, varname may have a different syntax. This syntax is required when the name of the data variable in the SDF does not conform to the GrADS naming conventions (see below for list of criteria), but it may also be used to shorten or change the variable name to make it easier to work with inside GrADS. The syntax is:SDF_varname=>grads_varnameSDF_varname is the name the data variable was given when the SDF file was originally created. For NetCDF files, this name appears in the output from ncdump. It is important that SDF_varname exactly matches the variable name in the data file. SDF_varname may contain uppercase letters andnon-alpha-numeric characters.The classic varname syntax (i.e., when "SDF_varname =>" is omitted) may be used if SDF_varname meets the criteria for GrADS variable names: it must be less than 16 characters, start with an alphabetic character, and cannot contain any upper case letters or non-alpha-numeric characters.(GrADS version 2.0.a3+) If the SDF_varname contains spaces, substitute "~" for each space -- the spaces in the variable name string will be swapped back in later after the descriptor file has been parsed.(GrADS version 2.0.a7+) For dtype hdf5_grid, the SDF_varname may be particularly long since it must contain the names of all the nested groups (separated by "/") to which the data set belongs.For example:/HDFEOS/GRIDS/EarthSurfaceReflectanceClimatology/Data~Fields/MonthlySurfaceReflectance=>msr。
GRADS (Grid Analysis and Display System)讲义（10）GrADS 描述语言及编程一、描述语言概述描述语言是GrADS软件包中自带的高级语言，可以用于GrADS的高级操作，更方便地使用GrADS 的功能。
通过描述语言可以编写具有复杂功能的命令集（即gs文件）。
二、gs文件中的两类型语句1）描述语句：不用引号，需要经过编译的。
2）指令性语句：GrADS命令，需用引号括起来。
通过描述语句来控制指令描述语言用到指令性语句中要用引号，即，i=1‘set t ‘i’’(或者‘set t ’ i )三、描述语言程序特点1、程序通过GrADS的run命令来编译执行；run file-name options2、可以有变量、流程控制也可以执行GrADS的命令。
3、描述语言可以1）编写函数子程序，2）制作屏幕菜单，3）可以显示动画图形，4）可以使用从GrADS的query命令中得到的信息作注释等。
3、描述语言的所有变量都是字符串型的，描述变量可以进行计算。
流程控制是通过if/else/endif和while/endwhile语句块实现。
循环过程可以用continue或break命令改变。
变量中包含的或者由表达式结果产生的字符串可以作为GrADS命令项使用。
而由GrADS命令执行后产生的文字结果可以读入变量并在描述语言程序中使用。
描述语言也支持函数子程序功能。
四、描述语言的组成1、一个描述语言程序是由许多语句组成,每个语句之间由换行号或分号分隔。
2、下面是GrADS描述语言中语句的类型：赋值语句If / Else / Endifwhile / endwhilebreak / continuefunction header / returnsay / pull3、描述表达式描述表达式是由运算对象和运算符组成。
运算对象：描述变量、子程序函数或常数；运算符：数学、逻辑或连结运算符。
下面分别介绍变量、运算符、表达式4、描述语言变量1）构成变量名是由1至8个字符组成，以字母开头，仅可以包含字母和数字，变量名区分大小写。
GRADS (Grid Analysis and Display System)讲义（10）GrADS 描述语言及编程一、描述语言概述描述语言是GrADS软件包中自带的高级语言，可以用于GrADS的高级操作，更方便地使用GrADS的功能。
通过描述语言可以编写具有复杂功能的命令集（即gs文件）。
二、gs文件中的两类型语句1）描述语句：不用引号，需要经过编译的。
2）指令性语句：GrADS命令，需用引号括起来。
通过描述语句来控制指令描述语言用到指令性语句中要用引号，即，i=1‘set t ‘i’’(或者‘set t ’ i )三、描述语言程序特点1、程序通过GrADS的run命令来编译执行；run file-name options2、可以有变量、流程控制也可以执行GrADS 的命令。
3、描述语言可以1）编写函数子程序，2）制作屏幕菜单，3）可以显示动画图形，4）可以使用从GrADS的query命令中得到的信息作注释等。
3、描述语言的所有变量都是字符串型的，描述变量可以进行计算。
流程控制是通过if/else/endif和while/endwhile语句块实现。
循环过程可以用continue或break命令改变。
变量中包含的或者由表达式结果产生的字符串可以作为GrADS命令项使用。
而由GrADS命令执行后产生的文字结果可以读入变量并在描述语言程序中使用。
描述语言也支持函数子程序功能。
四、描述语言的组成1、一个描述语言程序是由许多语句组成,每个语句之间由换行号或分号分隔。
2、下面是GrADS描述语言中语句的类型：赋值语句If / Else / Endifwhile / endwhilebreak / continuefunction header / returnsay / pull3、描述表达式描述表达式是由运算对象和运算符组成。
运算对象：描述变量、子程序函数或常数；运算符：数学、逻辑或连结运算符。
下面分别介绍变量、运算符、表达式4、描述语言变量1）构成变量名是由1至8个字符组成，以字母开头，仅可以包含字母和数字，变量名区分大小写。
Components of a GrADS Data Descriptor FileDSET data_filenameback to topThis entry specifies the filename of the data file being described. If the data and the descriptor file are not in the same directory, then data_filename must include a full path. If a ^ character is placed in front of data_filename,then data_filename is assumed to be relative to the path of the descriptor file. If you are using the ^ character in the DSET entry, then the descriptor file and the data file may be moved to a new directory without changing any entries in the data descriptor file, provided their relative paths remain the same. For example:If the data descriptor file is:/data/wx/grads/sa.ctland the binary data file is:/data/wx/grads/sa.datthen the data file name in the data descriptor file can be:DSET ^sa.datinstead of:DSET /data/wx/grads/sa.datIf data_filename does not include a full path or a ^, then GrADS will only look for data files in the directory where you are running GrADS.GrADS allows you use a single DSET entry to aggregate multiple data files and handle them as if they were one individual file. The individual data files must be identical in all dimensions except time, and the time range of each individual file must be indicated it its filename. To accomplish this, the DSET entry has a substitution template instead of a filename. See the section on Using Templates for a description of all the possible components of the template. Second, the OPTIONS entry must contain the template keyword.CHSUB t1 t2 stringback to top(GrADS version 1.9b4) This entry is used with a new option for templating data files that allows for any user-specified string substitution, instead of only date string substitution. This is useful when none of the standard template options match the time ranges in the files you wish to aggregate, or if the files are located on different disks. When you put the %ch template inyour DSET entry, then you also need to put additional CHSUB entries in the descriptor file. The string will be substituted for%ch in the data file name for the time steps beginning with t1 and ending with t2.See the section on Using Templates for examples.DTYPE keywordback to topThe DTYPE entry specifies the type of data being described. There are four options: grib, hdfsds, netcdf, or station. If the data type is none of these, then the DTYPE entry is omitted completely from the descriptor file and GrADS will assume the data type is gridded binary.bufr (GrADS version 1.9) Data file is a BUFR station data file. This data type must be accompanied by the following special entries: XVAR, YVAR, TVAR, STID. Optional special entries are: ZVAR, TOFFVAR.grib Data file is an indexed GRIB (version 1) file. This data type requires a secondary entry in the descriptor file:INDEX. The INDEX entry provides the filename (including the full path or a ^) for the GRIB index file. Theindex file is created by the gribmap utility. You must run gribmap and create the index file before you candisplay the GRIB data in GrADS.grib2 (GrADS version 2.0) Data file is an indexed GRIB2 file. This data type requires a secondary entry in the descriptor file: : INDEX. The INDEX entry provides the filename (including the full path or a ^) for the GRIB2index file. The index file is created by the gribmap utility. You must run grib2map and create the index filebefore you can display the GRIB2 data in GrADS.hdfsds (GrADS version 1.9) Data file is an HDF Scientific Data Set (SDS). Although HDF-SDS files are self-describing and may be read automatically using the sdfopen/xdfopen commands, this DTYPE gives youthe option of overriding the file's own metadata and creating a descriptor file for some or all of the variablesin the file. This DTYPE may also be used if the metadata in the HDF-SDS file is insufficient or is notcoards-compliant. This data type requires a special entry in the units field of the variabledeclaration. The undef and unpack entries contain special options for this dtype.hdf5_grid (GrADS version 2.0.a7+) Data file is HDF5 gridded format. The HDF5 format is extremely general and is designed to store a variety of data types. The GrADS interface is only for grids, and requires a completedescriptor file -- there is no sdfopen/xdfopen interface for HDF5.netcdf (GrADS version 1.9) Data file is NetCDF. Although NetCDF files are self-describing and may be read automatically using the sdfopen/xdfopen commands, this DTYPE gives you the option of overriding the file'sown metadata and creating a descriptor file for some or all of the variables in the file. This DTYPE may alsobe used if the metadata in the NetCDF file is insufficient or is not coards-compliant. This data type requires aspecial entry in the units field of the variable declaration. The undef and unpack entries contain specialoptions for this dtype.station Data file is in GrADS station data format. This data type requires a secondary entry in the descriptor file: STNMAP. The STNMAP entry provides the filename (including the full path or a ^) for the station data mapfile. The map file is created by the stnmap utility. You must run stnmap and create the map file before youcan display the station data in GrADS.INDEX filenameback to topThis entry specifies the name of the grib map file. It is required when using the DTYPE grib or grib2 entry to read GRIB formatted data. The file is generated by running the external utility gribmap. or grib2map. Filenaming conventions are the same as those described for the DSET entry.STNMAP filenameback to topThis entry specifies the name of the station map file. It is required when using the DTYPE station entry to readGrADS-formatted station data. The file is generated by running the external utility stnmap. Filenaming conventions are thesame as those described for the DSET entry.TITLE stringback to topThis entry gives brief description of the contents of the data set. String will be included in the output from a query command and it will appear in the directory listing if you are serving this data file with the GrADS-DODS Server (GDS), so it is helpful to put meaningful information in the title field. For GDS use, do not use double quotation marks (") in the title.UNDEF value<undef_attribute_name>back to topThis entry specifies the undefined or missing data value. UNDEF is a required entry even if there are no undefined data. GrADS operations and graphics routines will ignore data with this value from this data set.(GrADS version 1.9b4) An optional second argument has been added for data sets of DTYPE netcdf or hdfsds -- it is the name of the attribute that contains the undefined value. This should be used when individual variables in the data file have different undefined values. After data I/O, the missing values in the grid are converted from the variable undef to the file-wide undef (the numerical value in the first argument of the UNDEF record). Then it appears to GrADS that all variables have the same undef value, even if they don't in the original data file. If the data require a transformation using the attributes named in the UNPACK entry, GrADS assumes the variable undef value corresponds to the data values as they appear in the file,i.e.,before they are transformed using a scale factor and offset. Missing packed data values are thus assigned the file-wide undef value and are never unpacked. Attribute names are case sensitive, and it is assumed that the name is identical for all variables in the netcdf or hdfsds data file. If the name given does not match any attributes, or if no name is given, the file-wide undef value will be used.Example: UNDEF 1e+33 _FillValueUNPACK scale_factor_attribute_name <add_offset_attribute_name>back to top(GrADS version 1.9) This entry is used with DTYPE netcdf, hdfsds, or hdf5_grid (GrADS version 2.0.a7+) for data variables that are 'packed' -- i.e. non-float data that need to be converted to float by applying the following formula:y = x * scale_factor + add_offsetIf your self-describing file does not have an offset attribute, the 2nd argument may be omitted, and the offset will be assigned the default value of 0.0. If your self-describing file has an offset attribute, but not a scale factor, use "NULL" forthe scale_factor_attribute_name. (This "NULL" option is in GrADS version 2.0.0+). Attribute names are case sensitive, and it is assumed that the names are identical for all variables in the netcdf or hdfsds data file. If the names given do not match any attributes, the scale factor will be assigned a value of 1.0 and the offset will be assigned a value of 0.0. The transformation of packed data is done after the undef test has been applied.Examples:UNPACK scale_factor add_offsetUNPACK NULL add_offsetUNPACK Slope InterceptFILEHEADER lengthback to topThis optional entry tells GrADS that your data file has a header record of length bytes that precedes the data. GrADS will skip past this header, then treat the remaineder of the file as though it were a normal GrADS binary file after that point. This optional descriptor file entry is only valid for GrADS gridded data sets.THEADER length HEADERBYTES length<back to topThese two equivalent optional entries tell GrADS that the data file has a header record of length bytes preceding each time block of binary data. Use one or the other but not both. These entries are only valid for GrADS gridded data sets. See the section on structure of a gridded binary data file for more information.TRAILERBYTES lengthback to topThis optional entry tell GrADS that the data file has a trailer record of length bytes following each time block of binary data. This entry is only valid for GrADS gridded data sets. See the section on structure of a gridded binary data file for more information.XYHEADER lengthback to topThis optional entry tells GrADS that the data file has a header record of length bytes preceding each horizontal grid (XY block) of binary data. This entry is only valid for GrADS gridded data sets. See the section on structure of a gridded binary datafile for more information.XVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station's longitude. This entry is required for DTYPE bufr.YVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station's latitude. This entry is required for DTYPE bufr.ZVAR x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station data's vertical coordinate (e.g., pressure). This is an optional entry for DTYPE bufr.STID x,yback to top(GrADS version 1.9) This entry provides the x,y pair for the station ID. This entry is required for DTYPE bufr.TVAR yr x,y mo x,y dy x,y hr x,y mn x,y sc x,yback to top(GrADS version 1.9) This entry provides the x,y pairs for all the base time coordinate variables. Each time unit (year=yr, month=mo, day=dy, hour=hr, minute=mn, second=sc) is presented as a 2-letter abbreviation followed by the x,y pair that goes with that time unit. The time for any individual station report is the base time plus the offset time (see TOFFVAR). All six base time units are not required to appear in the TVAR record, only those that are in the data file. This entry is requiredfor DTYPE bufr.TOFFVAR yr x,y mo x,y dy x,y hr x,y mn x,y sc x,yback to top(GrADS version 1.9) This entry provides the x,y pairs for all the offset time coordinate variables. The syntax is the same as TVAR. The time for any individual station report is the base time plus the offset time. All six offset time units are not required to appear in the TOFFVAR record, only those that are in the data file. This is an optional entry for DTYPE bufr.CACHESIZE bytesback to top(GrADS version 2.0.a8+) This entry overrides the default size of the cache for reading HDF5 or NetCDF4 files. It is not relevant for other data types. It should not be necessary to set the cache size explicitly unless the data file has especially large chunks. Please see the documentation on compression.OPTIONS keywordback to topThis entry controls various aspects of the way GrADS interprets the raw data file. It replaces the old FORMAT record.The keyword argument may be one or more of the following:pascals (GrADS version 2.0) (For DTYPE grib2 only) Indicates that pressure values that appear in the descriptor file (in the ZDEF entry and in the GRIB2 codes in the variable declarations) are given inunits of Pascals. The gribmap utility requires pressure to be given in Pascals. If this keyword ispresent, the pressure level values will be converted to millibars after the gribmap index is generatedand the descriptor file is opened with GrADS. If this keyword is omitted, pressure levels will remain inPascals, and many of the internal functions (which assume a vertical dimension in units of millibars)will not work properly.yrev Indicates that the Y dimension (latitude) in the data file has been written in the reverse order from what GrADS assumes. An important thing to remember is that GrADS still presents the view that thedata goes from south to north. The YDEF statement does not change; it still describes thetransformation from a grid space going from south to north. The reversal of the Y axis is done as thedata is read from the data file.zrev Indicates that the Z dimension (pressure) in the data file has been written from top to bottom, rather than from bottom to top as GrADS assumes. The same considerations as noted above for yrev alsoapply.template Indicates that a template for multiple data files is in use. For more information, see the section on Using Templates.sequential Indicates that the file was written in sequential unformatted I/O. This keyword may be used with either station or gridded data. If your gridded data is written in sequential format, then each record must bean X-Y varying grid. If you have only one X and one Y dimension in your file, then each record in thefile will be one element long (it may not be a good idea to write the file this way).365_day_calendar Indicates the data file was created with perpetual 365-day years, with no leap years. This is used for some types of model ouput.byteswapped Indicates the binary data file is in reverse byte order from the normal byte order of your machine.Putting this keyword in the OPTIONS record of the descriptor file tells GrADS to swap the byte orderas the data is being read. May be used with gridded or station data.The best way to ensure hardware independence for gridded data is to specify the data's source platform. This facilitates moving data files and their descriptor files between machines; the data may be used on any type of hardware without having to worry about byte ordering. The following three OPTIONS keywords are used to describe the byte ordering of a gridded or station data file:big_endian Indicates the data file contains 32-bit IEEE floats created on a big endian platform (e.g., sun, sgi)little_endian Indicates the data file contains 32-bit IEEE floats created on a little endian platform (e.g., iX86, and dec)cray_32bit_ieee Indicates the data file contains 32-bit IEEE floats created on a cray.PDEFback to topPDEF is so powerful it has its own documentation page.XDEF xnum mapping <additional arguments>back to topThis entry defines the grid point values for the X dimension, or longitude. The first argument, xnum, specifies the number of grid points in the X direction. xnum must be an integer >= 1. mapping defines the method by which longitudes are assigned to X grid points. There are two options for mapping:LINEAR Linear mappingLEVELS Longitudes specified individuallyThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the longitude at grid point X=1. Negative values indicate western longitudes. increment is the spacing between grid point values, given as a positive floating point value.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the longitude value for each grid point. value-list should contain xnum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters. There must be at least 2 levels in value-list; otherwise use the LINEAR method.Here are some examples:XDEF 144LINEAR 0.0 2.5XDEF 72LINEAR 0.0 5.0XDEF 12LEVELS 0 30 60 90 120 150 180 210 240 270 300 330XDEF 12LEVELS 15 45 75 105 135 165 195 225 255 285 315 345YDEF ynum mapping <additional arguments>back to topThis entry defines the grid point values for the Y dimension, or latitude. The first argument, ynum, specifies the number of gridpoints in the Y direction. ynum must be an integer >= 1. mapping defines the method by which latitudes are assigned to Y grid points. There are several options for mapping:LINEAR Linear mappingLEVELS Latitudes specified individuallyGAUST62 Gaussian T62 latitudesGAUSR15 Gaussian R15 latitudesGAUSR20 Gaussian R20 latitudesGAUSR30 Gaussian R30 latitudesGAUSR40 Gaussian R40 latitudesThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the latitude at grid point Y=1. Negative values indicate southern latitides. increment is the spacing between grid point values in the Y direction. It is assumed that the Y dimension values go from south to north, so increment is always positive.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the latitude for each grid point, from south to north. value-list should contain ynum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters. There must be at least 2 levels in value-list; otherwise use the LINEAR method.The Gaussian mapping methods require one additional argument: start. This argument indicates the first gaussian grid number. If the data span all latitudes, start would be 1, indicating the southernmost gaussian grid latitude.Here are some examples:YDEF 73LINEAR -90 2.5YDEF 180LINEAR -90 1.0YDEF 18LEVELS -85 -75 -65 -55 -45 -35 -25 -15 -5 5 15 25 35 45 55 65 75 85YDEF 94GAUST62 1YDEF 20GAUSR40 15The NCEP/NCAR Reanalysis surface variables are on the GAUST62 grid.The final example shows that there are 20 Y dimension values which start at Gaussian Latitude 15 (64.10 south) on the Gaussian R40 gridZDEF znum mapping <additional arguments>back to topThis entry defines the grid point values for the Z dimension. The first argument, znum, specifies the number of pressure levels. znum must be an integer >= 1. mapping defines the method by which level values are assigned to Z grid points. There are two options for mapping:LINEAR Linear mappingLEVELS Pressure levels specified individuallyThe LINEAR mapping method requires two additional arguments: start and increment. start is a floating point value that indicates the level value at grid point Z=1. increment is the spacing between grid point values in the Z direction, or from lower to higher. increment must be non-zero and non0negative.The LEVELS mapping method requires one additional argument, value-list, which explicitly specifies the pressure level for each grid point in ascending order. value-list should contain znum floating point values. It may continue into the next record in the descriptor file, but note that records may not have more than 255 characters.Here are some examples:ZDEF 7LEVELS 1000 850 700 500 300 200 100ZDEF 17LEVELS 1000 925 850 700 600 500 400 300 250 200 150 100 70 50(GrADS version 2.0) (For DTYPE grib2 only) If your Z axis is pressure, the gribmap utility requires the level values to be given in units of Pascals instead of millibars. Use the "options pascals" keyword to convert the unit of the level values to millibars after the gribmap index is generated and when the descriptor file is opened with GrADS. Pressure level values may remain in Pascals, but then many of the internal functions (which assume a vertical dimension in units of millibars) will not work properly.TDEF tnum LINEAR start incrementback to topThis entry defines the grid point values for the T dimension. The first argument, tnum, specifies the number of timesteps.tnum must be an integer >= 1. The method by which times are assigned to T grid points is always LINEAR.start indicates the initial time value at grid point T=1. start must be specified in the GrADS absolute date/time format:hh:mm Z ddmmmyyyywhere:hh = hour (two digit integer)mm = minute (two digit integer)dd = day (one or two digit integer)mmm = 3-character monthyyyy = year (may be a two or four digit integer; 2 digits implies a year between 1950 and 2049)If not specified, hh defaults to 00, mm defaults to 00, and dd defaults to 1. The month and year must be specified. No intervening blanks are allowed in the GrADS absolute date/time format.increment is the spacing between grid point values in the T direction. increment must be specified in the GrADS absolute time increment format:vvkkwhere:vv = an integer number, 1 or 2 digitskk = mn (minute)hr (hour)dy (day)mo (month)yr (year)Here are some examples:TDEF 60LINEAR 00Z31dec1999 1mnTDEF 73LINEAR 3jan1989 5dyTDEF 730LINEAR 00z1jan1990 12hrTDEF 12LINEAR 1jan2000 1moTDEF 365LINEAR 12Z1jan1959 1dyTDEF 40LINEAR 1jan1950 1yrEDEF enum NAMES <list of names>back to topEDEF enumensemble_record_1 ensemble_record_2 ...ensemble_record_enum ENDEDEFback to top(GrADS version 2.0) This entry defines the ensemble dimension. All ensemble members must have identical X, Y, and Z dimensions, the same list of variables, and the same time axis increment. There are two different syntaxes for the EDEF entry: the first is simpler and requires only the names for each ensemble member, the second expanded form contains a name, individual time axis information, and optional GRIB2 codes.Both EDEF syntaxes begin with the enum argument, an integer >=1 which specifies the number of ensemble members.If all of the ensemble members have an identical time axis (i.e. length, initial time, and increment are the same for each one), then it is only necessary to distinguish the ensembles by their names, and the simplified EDEF syntax with the NAMES keyword may be used. A simple space-delimited list of names is all that is required. Ensemble names must have between 1 and 15 alphanumeric characters, lower case only. (In version 2.0.0 and later, mixed case ensemble names are allowed). Some examples are:EDEF 10NAMES 1 2 3 4 5 6 7 8 9 10EDEF 12NAMES m01 m02 m03 m04 m05 m06 m07 m08 m09 m10 m11 ensmEDEF 7NAMES e1 e2 e3 e4 e5 e6 e7When the OPTIONS TEMPLATE entry is used with EDEF, the ensemble names are used in the %e substitution template to generate the file name. See Using Templates for more details.If the ensemble members do not have identical time axes (i.e., their lengths or initial times are not the same), or if you need to include the GRIB2 codes, then you must use the expanded EDEF syntax: a collection of records framed by EDEF and ENDEDEF. The format of the ensemble records is as follows:ensname length start <grib2 codes>The ensname is the 1-15 character "name" for the ensemble member. The length is the size of the time axis of the ensemble, which must be less than or equal to the tnum argument in the TDEF entry. (The time axis described by TDEF must span all the ensemble members.) The start argument is the initial time of the ensemble member and must be given in GrADS absolute date/time format. (See TDEF for details).The grib2 codes are required if (1) the DTYPE is grib2 and (2) there is more than one ensemble member (enum > 1). The expanded form of the EDEF entry must be used when grib2 codes are required, even if the length and start times are the same for all members. For GRIB2 ensembles, support currently exists for four different Product Definition Template (PDT) numbers: 1, 2, 11, and 12. These are grouped into two types: individual ensemble forecasts (PDT 1 and 11) or derived forecasts based on all ensemble members (PDT 2 and 12). For individual ensemble forecasts (PDT 1 and 11), twocomma-delimited grib2 codes are required: the ensemble type and perturbation number. For derived forecasts based on all ensemble members (PDT 2 and 12), only one grib2 code is required: the derived forecast. Clarification of all the GRIB2 nomenclature may be found in the documentation at WMO and NCEP. Two examples are given below.The first example illustrates ensemble members with different lengths and start times:TDEF 591 linear 12z09dec1980 12hrEDEF 16ensm 591 12z09dec1980m01 591 12z09dec1980m02 589 12z10dec1980m03 587 12z11dec1980m04 585 12z12dec1980m05 583 12z13dec1980m06 571 12z19dec1980m07 569 12z20dec1980m08 567 12z21dec1980m09 565 12z22dec1980m10 563 12z23dec1980m11 549 12z30dec1980m12 547 12z31dec1980m13 545 12z01jan1981m14 543 12z02jan1981m15 541 12z03jan1981ENDEDEFThe second example illustrates the use of GRIB2 codes:TDEF 31 linear 00z24apr2007 12hrEDEF 23p01 31 00z24apr2007 3,1p02 31 00z24apr2007 3,2p03 31 00z24apr2007 3,3p04 31 00z24apr2007 3,4p05 31 00z24apr2007 3,5p06 31 00z24apr2007 3,6p07 31 00z24apr2007 3,7p08 31 00z24apr2007 3,8p09 31 00z24apr2007 3,9p10 31 00z24apr2007 3,10p11 31 00z24apr2007 3,11p12 31 00z24apr2007 3,12p13 31 00z24apr2007 3,13p14 31 00z24apr2007 3,14p15 31 00z24apr2007 3,15p16 31 00z24apr2007 3,16p17 31 00z24apr2007 3,17p18 31 00z24apr2007 3,18p19 31 00z24apr2007 3,19p20 31 00z24apr2007 3,20c00 31 00z24apr2007 1,0avg 31 00z24apr2007 0spr 31 00z24apr2007 2ENDEDEFVECTORPAIRS U-component,V-componentback to top(GrADS version 1.9b4) This entry is for explicity identifying vector component pairs. This is only necessary if the data are on a native projection other than lat/lon (i.e. you are using PDEF) and if the winds have to be rotated from a grid-relative sense to an Earth-relative sense. (GrADS has to retrieve both the u and v component in order to do the rotation calculation.)Using this entry replaces the old technique of putting 33 (for U) or 34 (for V) in the first element of the units field in the variable declaration. The U-component and V-component arguments should be variable names that appear in the VARS list. They are separated by a comma, with no spaces. More than one pair of components may be listed; in this case, the pairs should be separated by a space. For example:VECTORPAIRS u,v u10,v10 uflx,vflxVARS varnum variable_record_1back to topvariable_record_2...variable_record_varnumENDVARSThis ensemble of entries describes all the variables contained in the data set. varnum indicates the number of variables in the data set and is therefore also equal to the number of variable records that are listed between the VARS and ENDVARS entries. ENDVARS must be the final line of the Grads data descriptor file. Any blank lines after the ENDVARS statement may cause open to fail!The format of the variable records is as follows:varname levs units description (Version 2.0.1 or earlier)varname levs <additional_codes> units description (Version 2.0.2 or later)The syntax of varname and units is different depending on what kind of data format (DTYPE) you are describing.The<additional_codes> are only necessary for certain types of GRIB2 data sets. Details provided below:varname This is a 1-15 character "name" or abbreviation for the data variable. varname may contain alphabetic and numeric characters but it must start with an alphabetic character (a-z).varname (DTYPE netcdf, hdfsds, orhdf5_grid) (GrADS version 1.9+) For DTYPE netcdf or hdfsds, varname may have a different syntax. This syntax is required when the name of the data variable in the SDF does not conform to the GrADS naming conventions (see below for list of criteria), but it may also be used to shorten or change the variable name to make it easier to work with inside GrADS. The syntax is:SDF_varname=>grads_varnameSDF_varname is the name the data variable was given when the SDF file was originally created. For NetCDF files, this name appears in the output from ncdump. It is important that SDF_varname exactly matches the variable name in the data file. SDF_varname may contain uppercase letters andnon-alpha-numeric characters.The classic varname syntax (i.e., when "SDF_varname =>" is omitted) may be used if SDF_varname meets the criteria for GrADS variable names: it must be less than 16 characters, start with an alphabetic character, and cannot contain any upper case letters or non-alpha-numeric characters.(GrADS version 2.0.a3+) If the SDF_varname contains spaces, substitute "~" for each space -- the spaces in the variable name string will be swapped back in later after the descriptor file has been parsed.(GrADS version 2.0.a7+) For dtype hdf5_grid, the SDF_varname may be particularly long since it must contain the names of all the nested groups (separated by "/") to which the data set belongs.For example:/HDFEOS/GRIDS/EarthSurfaceReflectanceClimatology/Data~Fields/MonthlySurfaceReflectance=>msr。
