This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: "Paul L. Sirvatka" <address@hidden> >Organization: College of DuPage >Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP Paul, re: how to use the '%' key in vi to show matching parentheses >Thanks for the tips in vi. I still use that so that will help. It really is quite a handy thing. re: how the SFCPLT and GRDDISP displays are different >I suppose it is not a big deal since I KNOW that my way is fine. If I find >anything intersting I will let you know. OK. If you do uncover something, I will send it back to SSEC for detailed investigation. re: losing the image window >Yes...I have run the same commands other times and I got that erro and the >window went away. I have gotten that in the near past with THAE on the >SFCCON stuff. Sometimes things work well...other times they crap out. OK, this is important to know. It may have to with building the code with optimization turned on. It may be some faulty coding. re: unexpected display color in frame 6 when using incorrect MATH clause >I saw this too. I have no idea why. To me, this means that something is definately being stepped on. This really does warrant further investigation. Also, what version of Linux are you using (e.g., RedHat 6.2, RedHat 7.0, Debian x.x, Slackware y.y)? I have uncovered a problem in serving sounding data through the remote ADDE server hosted on RedHat 6.2 and 7.0. I am searching around for a site not running RedHat to see if the problem exists there. For reference, the problem does not occur on RedHat 5.2, FreeBSD 4.2, or Solaris x86 2.[78]. This one has been my bane for over a week now. re: perhaps multiplying that single term by 36000 was causing the floating point exception >Maybe...should I make that 36**3 ? ??? >Now for the ADDE vs local-data. I do not understand. Here is the output of >DSSERVE and DATALOC. > >DSSERVE >Group/Descriptor Type Format & Range RT Comment >------------------------ ----- ------------------ -- -------------------- >MYDATA/GRIDS GRID GRID 1-9999 All gridded data in >GRID fo > rmat >MYDATA/IMAGES IMAGE AREA 1-9999 All images in AREA >format >MYDATA/PTSRCS POINT MD 1-9999 All point source data >files > in MD file format >MYDATA/TOPO IMAGE AREA 9000-9019 All topographic >images in A DSSERVE is used to setup datasets. It creates an association between a dataset group/descriptor and actual data files. In the your DSSERVE listing above, there is one dataset setup: MYDATA. MYDATA has four different descriptors in it: GRIDS, IMAGES, PTSRCS, TOPO. A descriptor should be thought of as a subsetting of a larger dataset. Subsetting can be by gross data type (like MYDATA above) or by finer resolution of type (like creating one descriptor for GOES-East VIS images; another for GOES-East IR iamges; yet another for GOES-West VIS images; etc.) When a user creates a dataset using DSSERVE, s/he specifies the granularity of the access to elements in the dataset. For instance. the MYDATA/IMAGES is a definition that encompasses all images in AREA file format and using AREAnnnn naming; MYDATA/GRIDS is a defiition that encompasses all grids in McIDAS GRID file format using GRIDnnnn naming; etc. This is what I would call a gross categorization. The setup for imagery in the Unidata-Wisconsin datastream imagery is more finely differentiated. The recommended definition for those images is contained in the McIDAS BATCH file DSSERVE.BAT. This file gets installed in the ~mcidas/data directory. What account are you running the DSSERVE and DATALOC commands from? >DATALOC >Group Name Server IP Address >-------------------- ---------------------------------------- >BLIZZARD 144.92.109.163 >G8-GHCC 198.116.59.198 >MYDATA <LOCAL-DATA> >RTGINI ADDE.UCAR.EDU >RTGRIDS <LOCAL-DATA> >RTIMAGES <LOCAL-DATA> >RTNEXRAD ADDE.UCAR.EDU >RTNIDS ADDE.UCAR.EDU >RTNOWRAD <LOCAL-DATA> >RTPTSRC ADDE.UCAR.EDU >RTWXTEXT ADDE.UCAR.EDU >TOPO ADDE.UCAR.EDU This shows that you will be going to adde.ucar.edu for all of the datasets listed except MYDATA and RTNOWRAD. >Does SFCCON use RTPTSRC? SFCCON and SFCPLOT both use RTPTSRC/SFCHOURLY. To see the descriptors in a dataset, run: DSINFO ALL group_name DSINFO ALL RTPTSRC - or since RTPTSRC only has POINT data - DSINFO POINT RTPTSRC >If I change that to LOCAL-DATA I get RTPTSRC/SFCHOURLY unable to resolve >that data. Right. The reason for this is that the dataset has not been setup on your machine. Since I don't know if you are creating the data files that will comprise RTPTSRC/SFCHOURLY, let's start with the TOPO data. I send topography images out in the McIDAS-X distribution, so I know that you do have them on your system. Let's do the following from the 'mcidas' account on your machine: <login as 'mcidas'> cd workdata batch.k TOPOADDE.BAT TOPOADDE.BAT will run a series of DSSERVE commands to setup the TOPO dataset with various descriptors. Again, the DSSERVE commands establish the link between dataset group/descriptor and sets of files. After running BATCH (batch.k), a DSSERVE LIST TOPO should show: Group/Descriptor Type Format & Range RT Comment ------------------------ ----- ------------------ -- -------------------- TOPO/ALL IMAGE AREA 9000-9019 All topographic images TOPO/CONF IMAGE AREA 9011-9011 North America (Conformal) TOPO/GLOB IMAGE AREA 9000-9000 Global (Mercator) TOPO/GOESE IMAGE AREA 9016-9016 GOES-East (75W) TOPO/GOESW IMAGE AREA 9017-9017 GOES-West (135W) TOPO/HIRES IMAGE AREA 9001-9001 USA high resolution TOPO/MDR IMAGE AREA 9018-9018 US Radar projection TOPO/MERC IMAGE AREA 9010-9010 North America (Mercator) TOPO/MOLL IMAGE AREA 9015-9015 Global (Mollweide) TOPO/NPOLE IMAGE AREA 9014-9014 Northern Hemisphere TOPO/QUAD IMAGE AREA 9019-9019 NW Quadrasphere TOPO/SPOLE IMAGE AREA 9013-9013 Southern Hemisphere TOPO/WHEMI IMAGE AREA 9012-9012 Western Hemisphere DSSERVE: done The next thing to do is verify that this account can access the AREA files that comprise the TOPO dataset: dmap.k AREA9 You should see a listing that looks something like: PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ -------- --------- -rw- 1503728 Nov 13 19:17 AREA9010 /home/mcidas/data -rw- 1503728 Nov 13 19:18 AREA9011 /home/mcidas/data -rw- 1543904 Nov 13 19:18 AREA9012 /home/mcidas/data -rw- 1003728 Nov 13 19:18 AREA9013 /home/mcidas/data -rw- 1003728 Nov 13 19:19 AREA9014 /home/mcidas/data -rw- 897680 Nov 13 19:19 AREA9015 /home/mcidas/data -rw- 608288 Nov 13 19:19 AREA9016 /home/mcidas/data -rw- 565512 Nov 13 19:19 AREA9017 /home/mcidas/data -rw- 311008 Nov 13 19:19 AREA9018 /home/mcidas/data -rw- 714288 Nov 13 19:19 AREA9019 /home/mcidas/data -rw- 768 Nov 25 1996 AREA9982 /home/mcidas/data -rw- 768 Nov 25 1996 AREA9983 /home/mcidas/data -rw- 2816 Jun 02 1998 AREA9995 /home/mcidas/data assuming, of course, that the HOME directory for your 'mcidas' user is /home/mcidas. If it is something else, you will see a different directory under the DIRECTORY column. After defining the TOPO dataset with DSSERVE, you should be able to change your DATALOC for those files to be LOCAL-DATA: DATALOC ADD TOPO LOCAL-DATA And, you should be able to list and display those images in a McIDAS session. IMGLIST TOPO/ALL.ALL IMGDISP TOPO/CONF EU=TOPO MAG=-3 etc. Once we have the TOPO dataset setup, we can proceed with ones like RTPTSRC, RTIMAGES, RTGRIDS, RTWXTEXT _if_ you are running decoders to produce the data files that will populate these datasets. >Sorry for the myriad questions. But I am learning by leaps and bounds. No problem. It might help to skim through the McIDAS installation instructions as setting up the various datasets is described there: http://www.unidata.ucar.edu/packages/mcidas/770/mcx/mcidas-x.html One last comment for this email exchange. After you have setup access to the various McIDAS datasets on your own machine, you will want to setup the remote ADDE server on your machine so that you can access those datasets from other machines that are accessible by TCP/IP Ethernet. The way you are getting data right now, is doing just this. The only difference is that you are now going to adde.ucar.edu when you could be going to your own machine (access will probably be faster on your own machine from your own network). This is the really cool thing about ADDE. You can go to your own machine for data if you have it, or point to another machine for access when you don't. You could, for instance, look at data on Gilbert's machine. Example: DATALOC ADD RTNEXRAD weather.admin.niu.edu DSINFO I RTNEXRAD IMGLIST RTNEXRAD/N0R ID=LIST IMGDISP RTNEXRAD/N0R ID=ILX STA=ILX EU=BREF REFRESH='EG;MAP H;BAR' Remember, however, that when you change who you are pointing at for data (using DATALOC), that pointer stays that way until you change it to a different machine. >Paul > > >-- >****************************************************************************** >* Paul L. Sirvatka | Office: (630) 942-2118; Lab: (630) 942-2590 * >* Professor of Meteorology | COD Weather Lab: (630)-858-0032 * > >* College of DuPage | Address: 425 22nd St. Glen Ellyn, IL 60137 * >****************************************************************************** >