>From: "Paul L. Sirvatka" <address@hidden> >Organization: COD >Keywords: 200210252051.g9PKpRq26172 McIDAS ADDE NEXRCOMP Paul, >address@hidden:~$ dsinfo.k IMAGE NEXRCOMP > > Dataset Names of Type: IMAGE in Group: NEXRCOMP > >Name NumPos Content >------------ ------ -------------------------------------- >1KN0R-NAT 99999 1 km N0R US Base Reflectivity Composite >2KN1P-NAT 99999 2 km N1P US 1-hr Precip. Composite >4KNTP-NAT 99999 4 km NTP US Storm Total Precip. Composite > >DSINFO -- done This looks good. re: ls listing should have had lots of entries; yours had one >It did...I just included one. OK, this makes sense now. re: I can access other datasets on weather.cod.edu, but not NEXRCOMP >Yes... I see that weather is not setup to serve NEXRCOMP images at all. >Here are my thoughts... >could it be the 7.8 version that is giving something fits? Yes if you are not running the latest Addendum for 7.8. v2002 has all GINI ADDE server mods, so sites running it will not have the same problems as you. >I had tried it >at first and got some data to plot although it did not look right. I do >not know what else may have happened but I could not get that original >image back. Of course I may have changed something but I do believe that >it is right now. OK. >Could it have something to do with the type of mounted directory it is? No, I don't think so. >I think it is readable by both the climate.cod.edu and weather.cod.edu >server. > >Just a thought. Good thought. >Feel free to log on as McIDAS to climate.cod.edu. (We allow ssh) >do you remember the password? I could send it to you if need be. OK, I just logged onto climate and poked around. I did a little clean-up before really diving into the NEXRCOMP stuff (this had nothing to do with the NEXRCOMP serving failure): cd workdata dmap.k Frame PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ -------- --------- -rw- 3072 Oct 29 15:31 Frame1.0 /home/mcidas/.mctmp/560693266 -rw- 3072 Nov 30 2001 Frame2.0 /home/mcidas/help 6144 bytes in 2 files The file /home/mcidas/help/Frame2.0 shouldn't be there, so I deleted it. The files FRAMENH.001, TERMCHAR.001, and FRAMED should not be in the ~mcidas/workdata directory, so I deleted them: rm FRAMENH.001 TERMCHAR.001 FRAMED The next thing I did is rerun your imglist.k invocation. This time I added the TRACE=1 keyword sequence onto the end of the command: imglist.k NEXRCOMP/1KN0R-NAT FORM=EXP TRACE=1 When the dataset is <LOCAL-DATA>, this causes the file ~mcidas/workdata/trce to be created. This is debug output from the server, and it shows that the server is seeing all of the files, but the header information is not being unpacked correctly. I then checked which version of McIDAS you are running: cat ~mcidas/data/VERSION.TXT 7.804 Unidata 011222 X I then went to the Unidata McIDAS-X 7.8 web pages and took a look at: Hot Topics http://www.unidata.ucar.edu/packages/mcidas/780/mcx/addenda.html and clicked on: Addenda http://www.unidata.ucar.edu/packages/mcidas/780/mcx/addendum_020406.html Since you already have Addenda #4, I checked the list of things changed in Addenda #5. Here I was reminded of the changes to the GINI image server that were made to support serving of NEXRAD composite images: giniutil.h servutil.h Update Unidata ADDE servers for NOAAPORT GINI imagery to giniadir.c support NEXRAD composites added to IDD FNEXRAD datastream. giniaget.c giniutil.c bar.pgm Update BAR to support INFO AUX blocks that contain up to 32 levels (was 16) So, it appears that all that is needed is an upgrade to Addendum #5. I did this for you: <as 'mcidas'> cd ~mcidas/mcidas7.8/update ftp ftp.unidata.ucar.edu <user> umcidas <pass> XXXXXX cd unix/780/bugfix binary get mcupdate.tar.Z quit ./mcunpack cd ../src less makelog <- to check to make sure how McIDAS was built make all VENDOR=-gcc make install.all VENDOR=-gcc After updating you to Addendum 5 (v7.805), I reran the imglist.k command that failed before: imglist.k NEXRCOMP/1KN0R-NAT.ALL Image file directory listing for:NEXRCOMP/1KN0R-NAT Pos Satellite/ Date Time Center Band(s) sensor Lat Lon --- ------------- ------------ -------- ---- ---- ------------ 1 RADAR 29 OCT 02302 14:21:00 TWX 27 2 RADAR 29 OCT 02302 14:32:00 TWX 27 3 RADAR 29 OCT 02302 14:42:00 TWX 27 4 RADAR 29 OCT 02302 14:53:00 TWX 27 5 RADAR 29 OCT 02302 15:04:00 TWX 27 6 RADAR 29 OCT 02302 15:15:00 TWX 27 7 RADAR 29 OCT 02302 15:26:00 TWX 27 8 RADAR 29 OCT 02302 15:37:00 TWX 27 9 RADAR 29 OCT 02302 15:48:00 TWX 27 10 RADAR 29 OCT 02302 15:58:00 TWX 27 11 RADAR 29 OCT 02302 16:09:00 TWX 27 12 RADAR 29 OCT 02302 16:20:00 TWX 27 13 RADAR 29 OCT 02302 16:31:00 TWX 27 14 RADAR 29 OCT 02302 16:42:00 TWX 27 15 RADAR 29 OCT 02302 16:53:00 TWX 27 16 RADAR 29 OCT 02302 17:04:00 TWX 27 ... 41 RADAR 29 OCT 02302 21:37:00 TWX 27 42 RADAR 29 OCT 02302 21:48:00 TWX 27 imglist.k: done and now this is working correctly. The ramifications of me upgrading to Addendum 5 are: 1) you have to exit the McIDAS session you are running on climate. Otherwise it is possible/likely that one or more of the McIDAS routines being run (e.g., mcenv, mcimage, mctext, etc.) will crash and burn (You should also update weather to Addendum #5). 2) you should stop your LDM: <as 'ldm'> ldmadmin stop <wait for all LDM related jobs to finish> 3) you should recreate the DECINFO.DAT file in ~mcidas/workdata: <as 'mcidas'> cd ~/workdata rm DECINFO.DAT decinfo.k LIST 4) restart your LDM <as 'ldm'> ldmadmin start 5) I noticed that climate does not have a 'compress' executable: <as 'mcidas'> which compress <returns nothing> but it does have access to uncompress: which uncompress /bin/uncompress In order for compressed ADDE transfers to work from climate (climate is running the remote ADDE server, and the client is accessing data through climate's remote ADDE Server; this is done when the client user's Unix session has MCCOMPRESS defined in it before s/he runs McIDAS), you will need to install a version of compress into a directory that is in the PATH of the user 'mcidas'. 6) I also noted that the ADDE remote server on climate was setup as if it could serve a number of datasets that I don't think you have: RTGINI, GINIEAST, GINIWEST, GINICOMP, WNEXRAD, WNOWRAD, RTGRIDS Most likely, these were setup when someone ran 'BATCH LSSERVE.BAT' on climate, and LSSERVE.BAT (a local copy of DSSERVE.BAT) had not been edited to comment out the DSSERVE commands that defined these datasets. The quickest way to remove the definitions for these datasets is to edit ~mcidas/workdata/RESOLV.SRV and remove each line that access the datasets. The lines will look like: N1=GINICOMP,N2= ... Simply delete the lines for the datasets that you do not/will not have and you will be done. This will also have to be done on weather. Please let me know if you run into anything unexpected after the upgrade to Addendum #5. Tom >From address@hidden Tue Oct 29 15:44:44 2002 >Subject: Re: 20021029: setting up ADDE dataset for NEXRAD composites (cont.) You are the best! I will do all the things you stated as soon as I can. But I am using the images correctly in the session that I am in. Thanks a lot! Now we just need to set up receiving the satellite images! Then I will see if we can be an ADDE server. I just do not know how much traffic we will be putting out. If we can, we will! 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 Fawell Blvd. Glen Ellyn, IL 60137 * ******************************************************************************
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.