>From: 10 <address@hidden> >Organization: NMSU/NSBF >Keywords: 200103042227.f24MRSL24149 McIDAS-X NEXRAD NEXR Robert, >I am ingesting NEXRAD data from my downstream site and have >been looking at it with GARP. When I try to look at it with >McIDAS (7.704 Solaris 8 Sparc) on uldbldm I get the following errors: > >IMGLIST RTNIDS/BREF1.ALL ID=HGX >Image file directory listing for:RTNIDS/BREF1 >IMGLIST: ADIRSERV failed on exec of nidsadir >IMGLIST: done This is telling us that the dataset was setup with an image type of NIDS. This was the correct setup _before_ SSEC adopted my server and wanted the type changed to NEXR. The NEXRAD Level III product server in the current SSEC and Unidata distributions supports only the type of NEXR. To correct this, you have three options: o edit the BATCH file used to setup the dataset in the first place o use DSSERVE.BAT file in the Unidata McIDAS-X distribution to create a local copy (recommend LSSERVE.BAT) to create/define the RTNEXRAD dataset group and descriptors (see below) o directly edit the ADDE dataset definition file, RESOLV.SRV If you decide to edit RESOLV.SRV, you will: o find it in the ~mcidas/workdata directory o need to change the 'K=NIDS' entries to 'K=NEXR' The other difference between the serving of NIDS versus NEXRAD products is the difference in dataset descriptors: NOAAPORT NEXRAD WSI NIDS --------------------+---------------------------- N0R BREF1 N1R BREF2 N2R BREF3 ... I suggest that you adopt the NOAAPORT conventions. >The data is being ingested on psnldm(SPARC) (still running McIDAS 7.613) >and is being file like this: Hold on. Where will the data be served from? If the answer is from 7.613, then there are two things to note: o NIDS.CFG would have to be changed so that the files can be correct found and identified BUT o the 7.613 NIDS server does not understand the zlib-compressed format of the NEXRAD Level III products If you want to serve the data from McIDAS 7.70x, then I recommend that you setup a new dataset to conform to new standards. >/var/data/ldm/nexrad% cd NIDS >/var/data/ldm/nexrad/NIDS% ls >HGX/ FDX/ FWS/ SHV/ >/var/data/ldm/nexrad/NIDS% cd HGX >/var/data/ldm/nexrad/NIDS/HGX% ls >N0V/ N0R/ NCR/ NTP/ >/var/data/ldm/nexrad/NIDS/HGX% cd N0R >/var/data/ldm/nexrad/NIDS/HGX/N0R% ls >N0R_20010304_2218 N0R_20010304_2208 N0R_20010304_2158 N0R_20010304_2148 >/var/data/ldm/nexrad/NIDS/HGX/N0R% OK, this shows use of the NOAAPORT descriptors for NEXRAD products: N0R, N0V, NCR, NTP, ... >My NIDS.CFG file in ~mcidas/workdata looks like this: > >DIRMASK=/product/nexrad/NIDS/\ID/\TYPE >FILEMASK=\TYPE_* >IPMASK=* Since you can not serve this data from 7.613, I will concentrate on the setup for 7.704. The thing facing you is the mismatch in ADDE dataset descriptors you currently have (BREF1, BREF2, etc.) and the NOAAPORT product types the products are being filed by (N0R, N0V, etc.) The absolute easiest thing to do to serve the data from 7.70x is: cd ~mcidas/data cp DSSERVE.BAT NSBFNEXR.BAT <edit NSBFNEXR.BAT and o remove all lines NOT related to the dataset RTNEXRAD> o set the INFO= sequence to point to the configuration file for the RTNEXRAD dataset: INFO=NSBFNEXR.CFG cd ~mcidas/workdata cp NIDS.CFG NSBFNEXR.CFG <the settings in NSBFNEXR.CFG are already correct given your examples above> batch.k NSBFNEXR.BAT At this point the RTNEXRAD dataset should be setup on your machine. To test this, you should run: IMGLIST RTNEXRAD/N0R ID=LIST IMGLIST RTNEXRAD/N0R ID=HGX STA=HGX EU=BREF REFRESH='EG;MAP H;BAR' >Where /product/nexrad/NIDS is the way the data directory is automounted >on uldbldm from psnldm. As you can see it finds the data fine: > >/product/nexrad/NIDS% ls >HGX/ FDX/ FWS/ SHV/ >/product/nexrad/NIDS% cd HGX >/product/nexrad/NIDS/HGX% ls >N0V/ N0R/ NCR/ NTP/ >/product/nexrad/NIDS/HGX% cd N0R >/product/nexrad/NIDS/HGX/N0R% ls >N0R_20010304_2218 N0R_20010304_2208 N0R_20010304_2158 N0R_20010304_2148 >/product/nexrad/NIDS/HGX/N0R% > >Where am I going wrong? You got thrown by: o having to serve the data from 7.70x since previous distributions do not support the zlib-compressed product format o my having to modify my code to suit SSEC (NIDS->NEXR, I had a big battle over this one, by the way). >Thanks, Let me know if this does not make sense. Tom >From address@hidden Sun Mar 4 20:24:21 2001 >Subject: Re: 20010304: NEXRAD data and McIDAS Yes it makes complete sense. The data will not be served from 7.6 I am only ingesting it on that machine and then accessing it via NFS for testing purposes. That machine will be upgraded to 7.704 after the Australian campaign is over. The first balloon failed shortly after launch.. they will launch another with a dummy payload as the science window has ended. If I were still at NSBF I would have been in YBAS for 70 days now... Thanks for the help as always. Robert
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.