<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Undef handling in GrADS changed with Grads 2.0.a6. The undef value in the data file (let's call it the 'input undef') is no longer the same as the undef value in the display or in the output (the 'output undef'). If you want them to be the same, use the 'set undef' command. Here is the documentation on 'set undef': <div><br></div><div><span class="Apple-style-span" style="font-family: Times; "><h2><b>set undef</b></h2></span></div><div><span class="Apple-style-span" style="font-family: Times; "><p>This command allows the user to set the undefined data value for all forms of GrADS output. This command controls the undefined values printed to screen with the 'gxout stat' and the 'gxout print' output, as well as the undefined values in fwrite, sdfwrite, and geotiff files.</p><p>The output undef value will not necessarily be the same as the native undef value of the data set -- the default value is -9.99e8. The user can easily change the output undef value to match the undef value of the default file or a specific open file.<br></p><h3>Syntax</h3><code>set undef <i>value</i> </code>(sets output undef value to <em>value</em>)<br><code>set undef file <i>n</i> </code>(copies undef value from file <i>n</i>)<br><code>set undef dfile </code>(copies undef value from default file)<h3>Usage Notes</h3><p><span class="style1" style="color: rgb(153, 0, 0); font-style: italic; font-weight: bold; ">This is a new feature with GraDS version 2.0.a6, that changes the default behavior of GrADS!</span><br>By default, the output undef value will be -9.99e8 instead of the undef value given in the data descriptor file. You may easily revert to the old behavior by using the 'set undef file n' option.</p><p>You can find out what the current output undef value is with the <code>'<a href="http://iges.org/grads/gadoc/gradcomdquery.html">query undef</a>'</code> command.</p><p>The <code><a href="http://iges.org/grads/gadoc/gradcomdreinit.html">reinit</a></code> command will return the output undef value to the default (-9.99e8); the <code><a href="http://iges.org/grads/gadoc/gradcomdreset.html">reset</a></code> command leaves it unchanged.</p><p>If you issue the '<code>set undef dfile</code>' command, the output undef value will be copied from the default file's undef value. If you subsequently change the default file number, the output undef value will not change. You must issue '<code>set undef dfile</code>' again if you wish the output undef value to be the same as the new default file.</p><h3><br></h3><h3><br></h3><h3><span class="Apple-style-span" style="font-weight: normal; "><font class="Apple-style-span" face="Helvetica" size="4"><span class="Apple-style-span" style="font-size: 14px;">As for your specific question about grib, there is no undef value in grib, there's a bit map. The undef record in a 'dtype grib/grib2' descriptor file is a number to put where data are designated as missing by the bit map -- it can be anything you want: -9.99e33, 1e+20, -999, 9.99e20, etc. There is no standard. In the recent versions of GrADS, this value has become almost entirely irrelevant, since the only way it will appear in your output is if you use the command "set undef file n".</span></font></span></h3><h3><span class="Apple-style-span" style="font-weight: normal; "><font class="Apple-style-span" face="Helvetica" size="4"><span class="Apple-style-span" style="font-size: 14px;">I cannot address issues with pygrads -- but I suspect that if you use the "set undef file n" command before you 'display', your problems might go away. It might also be relevant to know that the 'q ctlinfo' output will show you the undef value in the descriptor file (** see note below), but the output from 'gxout stat' or 'set stat on' shows you the undef value in the output. For pygrads, the better way to check the undef value might be to 'q undef' or 'set stat on' and parse that output instead. </span></font></span></h3><h3><span class="Apple-style-span" style="font-weight: normal; "><font class="Apple-style-span" face="Helvetica" size="4"><span class="Apple-style-span" style="font-size: 14px;">--Jennifer</span></font></span></h3><div><font class="Apple-style-span" face="Helvetica" size="4"><span class="Apple-style-span" style="font-size: 14px;">** N.B.: In a self-describing file (netcdf or hdf) the undef entry in the descriptor file can have 2nd argument, the name of the attribute that contains the missing value. In this case, the value given in the 1st argument of the undef entry is not required to match the undef values in the file, it can be anything you want, just like grib undefs. For recent versions of GrADS, this undef value is also almost entirely irrelevant, just as I mentioned above. At the moment of an I/O request, the named attribute containing the undef value is read from the variable's attributes, the retrieved undef value is used to test for misising data, and then discarded. The undef value in the descriptor file is not used unless you use the "set undef file n" command. </span></font></div><div><font class="Apple-style-span" face="Helvetica" size="4"><span class="Apple-style-span" style="font-size: 14px;"> </span></font></div><div><font class="Apple-style-span" face="Helvetica"><font class="Apple-style-span" face="Times"><br></font></font></div></span><div><div><div>On Aug 12, 2009, at 9:45 PM, P.R. wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br>Im having an issue with g2ctl & how it sets the undefined value in the ctl<br>file output.<br>g2ctl.pl hard-sets the undef value at 9.99e+20, which I *believe* has been<br>pretty much the standard undef value up until now.<br><br>However, the undef value on some datasets (the GFS grib2 files, for example)<br>is giving me a value of -9.99e+08.<br>(could someone please confirm this value for undef from the GFS grib2<br>files?).<br><br>Normally, I don't believe that it matters if the g2ctl.pl undef value<br>differs from the grib2's undef value.<br>However, I ran into an issue with pygrads; pygrads reads the undef value<br>from the ctl file, and it will improperly try to plot undefined data points<br>due to fact that it doesn't know the correct undef value.<br><br>So, my question/suggestion is:<br>should g2ctl be setting the undef value based on the dataset inside the<br>grib2 file, instead of hard-setting to a fixed value?<br>Is it even possible to retrieve this value from the grib2 metadata?<br><br>Thanks,<br>P.Romero<br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Jennifer M. Adams</div><div>IGES/COLA</div><div>4041 Powder Mill Road, Suite 302</div><div>Calverton, MD 20705</div><div><a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span></div></span> </div><br></div></div></body></html>