<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>GrADS needs to set the dimension environment to *something* when it opens a station data set, so it uses those defaults. The stnmap file doesn’t tell GrADS anything about the domain of the data — GrADS has no idea where the data are located until you invoke display and launch an I/O request. After you open the file, you can change the dimension environment to the smaller domain (since you know what it is ahead of time), then do a display. </div><div>—Jennifer</div><div><br></div><br><div><div>On Jul 7, 2015, at 1:02 PM, Clement Agboma <<a href="mailto:aclems@gmail.com">aclems@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">You are right in terms of XDEF, YDEF, and ZDEF being used in station<br>control file. However, even by removing these from the control file,<br>my station data domain still read as:<br><br>LON set to 0 360<br>LAT set to -90 90<br>LEV set to 500 500<br>Time values set: 2006:1:1:0 2006:1:1:0<br>E set to 1 1<br><br>This is a global data coverage but my data only spans a small<br>watershed with coordinates provided earlier on. It is really confusing<br>why this is happening within GrADS. Has anyone faced similar issue?<br><br>Clement.<br><br>On 7/7/15, M.Mahakur <<a href="mailto:mmahakur@tropmet.res.in">mmahakur@tropmet.res.in</a>> wrote:<br><blockquote type="cite"><br>You need to correct your .ctl file, No need to specify lon-lat coordinates<br>in the GrADS DDF.<br><br>Please see the documenation.<br><br>XDEF, YDEF, and ZDEF These entries are not included in a station data<br>control file<br><br>(<a href="http://www.iges.org/grads/gadoc/aboutstationdata.html">http://www.iges.org/grads/gadoc/aboutstationdata.html</a>)<br><br>----- Original Message -----<br>From: Clement Agboma <<a href="mailto:aclems@gmail.com">aclems@gmail.com</a>><br>To: <a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>Sent: Tue, 07 Jul 2015 19:46:26 +0530 (IST)<br>Subject: [gradsusr] Station data control file<br><br>Hello All,<br><br>I am having lots of issues reading station data with a control file that I<br>had used multiple times in the past to open and view meteorological<br>variable. I have a fortran program that generates a binary file and I use<br>the stnmap utility to create the required map file for inclusion in the<br>station control file. My control file is attached.<br><br>When I try to open the file in grads, and I use the "q dim" command, it<br>gives a global coverage for my data domain as follows:<br><br>ga-> q dim<br>Default file number is: 1<br>X is varying Lon = 0 to 360 X = 0 to 360<br>Y is varying Lat = -90 to 90 Y = -90 to 90<br>Z is fixed Lev = 500 Z = 500<br>T is fixed Time = 00Z01JAN2006 T = 1<br><br><br>My actual station data domain is:<br><br>xdef 9 linear -103.7 0.3<br>ydef 5 linear 51.8 0.3<br>zdef 1 linear 1 1<br>tdef 3287 linear 00Z01jan2006 1dy<br><br>I have tried to use stnmap -1 -i (my_control_file) as well as stnmap -i<br> (my_control_file) to generate stnmap files for use in grads versions 1.94<br>and 2.0.2 but the problem persist.<br><br>Please can someone assist because I never had this problem in the past<br>using this same control file. A few people equally had this problem a<br>while back but I didn't see any solution provided.<br><br>Thanks,<br><br>Clement Agboma (PhD, PGeo).<br><br>_______________________________________________<br>gradsusr mailing list<br><a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>http://gradsusr.org/mailman/listinfo/gradsusr<br><br></blockquote>_______________________________________________<br>gradsusr mailing list<br><a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>http://gradsusr.org/mailman/listinfo/gradsusr<br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 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; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Jennifer M. Adams<br>Center for Ocean-Land-Atmosphere Studies (COLA)<br>111 Research Hall, Mail Stop 2B3<br>George Mason University<br>4400 University Drive<br>Fairfax, VA 22030 <br><br></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span><br class="Apple-interchange-newline">
</div>
<br></body></html>