关于ctl变量描述的问题

雪颜

下面是一个EC的ctl变量描述
vars 25
GHprs 19 156,100,0 ** (profile) Height [gpm]
LCCsfc  0 186,1,0  ** surface Low cloud cover [(0 - 1)]
MSLsfc  0 151,1,0  ** surface Mean sea level pressure [Pa]
PVprs 19 60,100,0 ** (profile) Potential vorticity [K m**2 kg**-1 s**-1]
Qprs 19 133,100,0 ** (profile) Specific humidity [kg kg**-1]
Rprs 19 157,100,0 ** (profile) Relative humidity [%]
RSNsfc  0 33,1,0  ** surface Snow density [kg m**-3]
SDsfc  0 141,1,0  ** surface Snow depth [m of water equivalent]
SKTsfc  0 235,1,0  ** surface Skin temperature [K]
SSTKsfc  0 34,1,0  ** surface Sea surface temperature [K]
Tprs 19 130,100,0 ** (profile) Temperature [K]
TCCsfc  0 164,1,0  ** surface Total cloud cover [(0 - 1)]
TCWsfc  0 136,1,0  ** surface Total column water [kg m**-2]
TCWVsfc  0 137,1,0  ** surface Total column water vapour [kg m**-2]
Uprs 19 131,100,0 ** (profile) U velocity [m s**-1]
Vprs 19 132,100,0 ** (profile) V velocity [m s**-1]
Wprs 19 135,100,0 ** (profile) Vertical velocity [Pa s**-1]

以GHprs 19 156,100,0 ** (profile) Height [gpm]为例
156,100,0的各项是什么意思？
我们很多时候都用99，那什么时候用这种呢？
这些变量处理后能直接用99吗？

river

这个有时候还真是挺复杂的，但是一般不需要去管他······
你问的第二个问题关于什么时候用99，还是先去了解grads的基础知识吧，有数就看看书，没有书可以在论坛下载一个课件看看


另外附上官网的一部分说明，很多。
VARS varnum
variable_record_1
variable_record_2
...
variable_record_varnum
ENDVARS        back to top
This 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, or hdf5_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_varname
SDF_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 and non-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

levs       
This is an integer that specifies the number of vertical levels the variable contains. levs may not exceed znum as specified in the ZDEF statement. If levs is 0, the variable does not correspond to any vertical level. Surface variables (e.g. sea level pressure) have a levs value of 0.

For DTYPE station or bufr, surface variables have a levs value of 0 and upper air variables have a levs value of 1. (Exception to this rule for bufr data: replicated surface variables are given a levs value of 2).

levs
(DTYPE grib2)

(GrADS version 2.0) This is a comma-delimited list of numbers that provide information about the vertical dimension of a variable. The first number in the list is the number of vertical levels the variable contains or zero if the variable doesn't vary in Z. The remaining numbers are the GRIB2 parameters that specify the veritcal level or layer. The levs field may contain up to five comma-delimited numbers:

NLEVS,LTYPE,LVAL,LVAL2,LTYPE2
where
NLEVS        =        The number of vertical levels, or 0 if not Z-varying (Required)
LTYPE        =        The level type indicator (Required)
LVAL        =        The value of the 1st level (Not Required for all level types)
LVAL2        =        The value of the 2nd level (Only Required for layers between 2 fixed levels)
LTYPE2        =        The level type indicator for the 2nd level (Only required if different from LTYPE)
If NLEVS > 0 and is followed only by the LTYPE, the values for LVAL will be determined by the ZDEF entry. If a variable has an NLEVS entry that is > 0 but less than the number of levels declared in the ZDEF entry, then the values for LVAL will correspond to the first NLEVS values of the Z axis. If LTYPE is 100 (the GRIB2 code for an isobaric surface), the units of LVAL must be Pascals. If the values of LVAL are taken from the ZDEF entry, use OPTIONS pascals to convert the vertical coordinate to millibars once the descriptor file is opened with GrADS. Some level types such as "mean sea level" or "tropopause" do not require an LVAL. In this case, LVAL may be omitted (see the "slp" example below). If two LTYPE entries are required but LVAL and LVAL2 are not, then the LVAL entries may be omitted, with adjacent commas used to indicate missing values (see the "cloud" example below).

Examples:

hgt        26,100        0,3,5        Geopotential Height [gpm]
hgt500        0,100,50000        0,3,5        Geopotential Height at 500mb [gpm]
slp        0,101        0,3,1        Sea Level Pressure [Pa]
t2m        0,103,2        0,0,0        2-meter Temperature [K]
soilt1        0,106,0,0.1        0,0,0        Soil Temp, 0-0.10m below surface [K]
cloud        0,1,,,8        0,6,1        Total Cloud Cover, from surface to TOA [%]
The external utilities grib2scan and wgrib2 are quite useful in determining what the values for the levs field should be for a GRIB2 data file.

additional_codes
(DTYPE grib2)
(optional)        (GrADS version 2.0.2+) This field specifies any additional GRIB2 codes that are required to uniquely identify the record when the elements in the levs and units fields are not sufficient. It is only required for certain Product Definition Templates: the Probability Forecasts (PDT 5 and 9), Percentiles (PDT 6 and 10), and the Optical Properties of Aerosol (PDT 48). The additional_codes field always begins with the letter "a" (for "additional") followed by a set of comma-delimited numbers. The quantity and meaning of the numbers depends on the product.
additional_codes
(PDT 5 or 9)       
For the Probability forecasts (PDT 5 or 9), the additional_codes field has 2 or 3 comma-delimted numbers, preceded by the letter "a" :

aPTYPE,LIMIT,LIMIT2
where
PTYPE        =        The probability type indicator
LIMIT        =        The value of the limit (for probabilities above or below the given limit)
LIMIT2        =        The value of the 2nd limit (for probabilities between the 2 given limits)
(only needed for PTYPE=2)
Examples:

pt2m273        0,103,2        a0,273        0,0,0        Prob. of 2-m Temp below 273
pcape250        0,1,0        a1,250        0,7,6        Prob. of CAPE above 250
pcape500        0,1,0        a1,500        0,7,6        Prob. of CAPE above 500
pcape1000        0,1,0        a1,1000        0,7,6        Prob. of CAPE above 1000
pcsnow1        0,1,0        a2,1,1        0,1,195        Prob. of categor. snow between 1 and 1
The external utilities grib2scan (with the -v option) and wgrib2 are quite useful in determining what the values for the additional_codes field should be for a GRIB2 data file.

additional_codes
(PDT 6 or 10)       
(Version 2.1.a3+) For the Percentile forecasts (PDT 6 or 10), the additional_codes field has only one number preceded by the letter "a" :

aPCT LE
where
PCTLE        =        The percentile value
Examples:

t75        0,103,2        a75        0,0,0        75th percentile of of 2-m Temperatures
t90        0,103,2        a90        0,0,0        90th percentile of of 2-m Temperatures
The external utilities grib2scan (with the -v option) and wgrib2 are quite useful in determining what the values for the additional_codes field should be for a GRIB2 data file.

additional_codes
(PDT 48)       
For the Aerosol Forecasts (PDT 48), the additional_codes field may have up to 7 comma-delimted numbers, preceded by the letter "a":

aATYPE,STYPE,S1,S2,WTYPE,W1,W2

where
ATYPE        =         The aerosol type indicator
STYPE        =         The type of interval for the first and second size
S1        =       
The first size (in meters)

S2        =         The second size (in meters)
WTYPE        =         The type of interval for the first and second wavelength
W1        =         The first wavelength (in meters)
W2        =         The second wavelength (in meters)
The ATYPE code is always required. If the STYPE is non-missing, then the trio of numbers STYPE,S1,S2 must be included in the additional_codes field. Similarly, if WTYPE is non-missing, then the trio of numbers WTYPE,W1,W2 must be included in the additional_codes field. If both STYPE and WTYPE are non-missing, then all six codes must be present in the order listed above.

Examples:

aotk        0,10,0        a62000,0,2e-5,0,7,5.45e-7,5.65e-7        0,0,0        *desc1
aemflx        0,10,0        a62001,0,2e-05,0        0,20,3        *desc2

*desc1=Total Aerosol Optical Thickness, size < 2e-5, wavelength >= 5.45e-7 and <= 5.65e-7
*desc2=Atmosphere Emission Mass Flux for Dry Dust, size is < 2e-5
The external utilities grib2scan (with the -v option) and wgrib2 are quite useful in determining what the values for the additional_codes field should be for a GRIB2 data file.

The units component of the variable record is used for data with DTYPE bufr, grib, netcdf, or hdfsds. It is also used for non-standard binary data files that require special "unpacking" instructions, and special cases of pre-projected wind components. If the data you are describing does not fall into any of these categories, put a value of 99 in the units field.
units        For flat binary files containing 4-byte floating-point data that are not pre-projected, this field is ignored but must be included. Put in a value of 99.
units
(DTYPE bufr)        (GrADS version 1.9) For DTYPE bufr files, this field contains the x,y pair for the named variable.
units
(DTYPE grib)       
For DTYPE grib, the units field specifies the GRIB parameters of the variable. This information is used by the gribmap utility for mapping the variables listed in the descriptor file to the data records in the GRIB files. This parameter may contain up to four comma-delimited numbers:

VV,LTYPE,LVAL,TRI
or
VV,LTYPE,LVAL,LVAL2
where,
VV        =        The GRIB parameter number (Required)
LTYPE        =        The level type indicator (Required)
LVAL        =        The value of the 1st level (Required if NLEVS=0)
LVAL2        =        The value of the 2nd level (Optional)
TRI        =        The "time range indicator" (Optional)
The external utilities gribscan and wgrib are quite useful in determining what the values for the units field should be for a GRIB data file. Examples:

u        39        33,100        U Winds [m/s]
t        39        11,100        Temperature [K]
ts        0        11,1        Surface Temperature [K]
tb        0        11,116,60,30        Temperature, 30-60mb above surface [K]
dpt        0        17,100,1000        Dew Point Temperature at 1000 mb [K]
units
(DTYPE grib2)       
(GrADS version 2.0) This is a comma-delimited list of values that identify a GRIB2 parameter (variable):

DISC,CAT,NUM,SP,SP2
where,

DISC        =        The parameter Discipline (Required)
CAT        =        The parameter Category (Required)
NUM        =        The parameter Number (Required)
SP        =        The Statistical Process used to derive the parameter
(May be required if parameter is not an instantaneous value)
SP2        =        The Spatial Process used to interpolate the parameter
(Required only for Product Definition Template 4.15)
Some examples are:

u        26,100        0,2,2        U-Component of Wind [m/s]
v        26,100        0,2,3        V-Component of Wind [m/s]
t2max        0,103,2        0,0,5        2-meter Temperature Maximum [K] (NCEP)
t2max        0,103,2        0,0,0,2        2-meter Temperature Maximum [K] (TIGGE)
soilm1        0,106,0,0.1        2,0,192        Soil Moisture, 0-0.10m below surface [K]
catave        10,100        0,19,22,0,3        Spatial Avg. of Clear Air Turbulence [%]
catmax        10,100        0,19,22,2,3        Spatial Max of Clear Air Turbulence [%]


units
(DTYPE netcdf,
hdfsds, or hdf5_grid)       
(GrADS version 1.9) For DTYPE netcdf or hdfsds or hdf5_grid (GrADS version 2.0.a7+) , the units field is a comma-delimited list of the varying dimensions of the variable. Dimensions expressed as x, y, z, or t correspond to the four axes defined by XDEF, YDEF, ZDEF and TDEF. For example, a surface variable such as sea level pressure might look like this:

presSFC=>psfc   0   y,x   Surface Pressure
A time-varying atmospheric variable such as geopotential height might look like this:

Height=>hght   17   t,z,y,x   Geopotential Height (m)
The order of the dimensions listed in the units field does matter. They must describe the shape of the variable as it was written to the SDF data file. For NetCDf files, this information appears in the output from ncdump next to the variable name.

If your data file contains a variable that also varies in a non-world-coordinate dimension (e.g. histogram interval, spectral band, ensemble number) then you can put a non-negative integer in the list of varying dimensions that will become the array index of the extra dimension. For example:

VAR=>hist0   0   0,y,x   First historgram interval for VAR
VAR=>hist1   0   1,y,x   Second historgram interval for VAR
VAR=>hist2   0   2,y,x   Third histogram interval for VAR

Another option in this example would be to fill the unused Z axis with the histogram intervals:

zdef 3 linear 1 1
...
VAR=>hist   3   z,y,x   VAR Histogram

In this case, it would appear to GrADS that variable 'hist' varies in Z, but the user would have to remember that the Z levels correspond to histogram intervals. The latter technique makes it easier to slice through the data, but is not the most accurate representation. And if you don't have an unsued world-coordinate axis available, then you still have a way to access your data.

units
(non-standard binary)       
For non-standard binary files, the units field is used to instruct GrADS how to read binary files that do not conform to the default structure or do not contain 4-byte float data. GrADS assumes the data were written in the following order (starting from the fastest varying dimension to the slowest): longitude (X), latitude (Y), vertical level (Z), variable (VAR), time (T). If your binary data set was created or "packed" according to a different dimension sequence, then you can use the units field to tell GrADS exactly how to unpack the data.

For these non-standard binary files, the units field is a series of one or more comma-delimited numbers, the first of which is always -1. The syntax is as follows:

-1, structure <,arg>
There are four options for structure, outlined below. Some of these options have additional attributes which are specified with arg.

-1,10,arg       
(GrADS 1.9 or earlier) This option indicates that "VAR" and "Z" have been transposed in the dimension sequence. The order is: longitude (X), latitude (Y), variable (VAR), vertical level (Z), time(T). Thus, all variables are written out one level at a time. This feature was designed to be used with NASA GCM data in the "phoenix" format. The upper air prognostic variables were transposed, but the diagnostic variables were not. Thus an arg of 1 means the variable has been var-z transposed, and an arg of 2 means the variable has not.

-1,20       
This option indicates that "VAR" and "T" have been transposed in the dimension sequence. The order is: longitude (X), latitude (Y), vertical level (Z), time(T), variable (VAR). Thus, all times for one variable are written out in order followed by all times for the next variable, etc. Data files for which "VAR" and "T" have been transposed may not be templated together.

-1,30        (GrADS 1.9 or earlier) This option handles the cruel and unusual case where X and Y dimensions are transposed and the horizontal grids are (lat,lon) as opposed to (lon,lat) data. This option causes GrADS to work very inefficiently. However, it is useful for initial inspection and debugging.
-1,40,arg       
This option handles non-float data. If there are multiple variables in the same file, they must all be the same type. The dimension sequence is assumed to be the default. The secondary arg tells GrADS what type of data values are in the binary file:

units = -1,40,1     = 1-byte unsigned chars (0-255)
units = -1,40,2     = 2-byte unsigned integers
units = -1,40,2,-1 = 2-byte signed integers
units = -1,40,4     = 4-byte integers
units
(pre-projected wind components)        For pre-projected vector component data that require the use of PDEF and rotation, GrADS has to retrieve both the u and v component in order to do the rotation calculation. The new (and recommended) method for matching vector components is to use the VECTORPAIRS descriptor file entry. The old technique (for versions older than 1.9b4) is to use the units field of the variable record. The u-component variable must have a units value of 33, and the v-component variable must have a units value of 34. (This is the GRIB convention). If there are more than one u/v pairs, secondary units values are used.
description        This is text description or long name for the variable. Max 140 characters.