>From: alan anderson <address@hidden> >Organization: St. Cloud State >Keywords: 200102202133.f1KLXZL10511 McIDAS NEXRAD display Alan, >I have looked at waldo, and it has McIDAS 7.5 installed on it. Ouch! >We don't use it as a McIDAS terminal, so have not bothered to upgrade. Yes, but you use it to decode data via XCD into McIDAS compatible formats. >For our remaining terminals, 4 have ver. 7.7x and 2 are still running >ver. 7.613. I am hoping to upgrade these last 2 right away. OK. >The disk on waldo runs about 50-55% full, and it is a about 8 Gb. This >is a Gateway machine, and runs Solaris for intel, ver. 2.7 So, disk space wise, waldo is in pretty good shape. How heavily used is it otherwise? I suspect really not that much since it is being used to run the LDM and McIDAS-XCD. This should not create too much of a load for the box. I took a quick look at waldo through ADDE to see what I could see. It looks like you are decoding all point source data with the exception of NLDN lightning. Since MN gets _lots_ of lightning data in the summer, you will probably want to begin getting and decoding the data so you can use it in McIDAS. It also looks like you are getting the full complement of image data in both the CIMSS and RTIMAGES datasets. It looks like you are not, however, decoding any grid data, or, at least, I can't list any GRID files through ADDE. This is not really a problem since you can always point at a remote ADDE server that has the gridded data. If you want to test this, I would suggest pointing at papagayo.unl.edu: DATALOC ADD RTGRIDS papagayo.unl.edu >I assume that for waldo, I will need to configure the ADDE server in >order to let the other machines feed from it. The remote ADDE server is already setup on waldo (as my tests proved), so all you would have to do for the NIDS (formerly referred to as NEXRAD Level III products (I still like NIDS)) is setup a dataset on waldo so that other machines can point to it. As I understand things, your original email was concerned with NIDS images that a student was/is going to FTP from the NWS. Did you setup waldo to request the NIDS floaters that are now free? I am guessing not since you would have needed to update your LDM in order to be able to specify the FNEXRAD feed type in a 'request' line. (Aside: you can still request the data, but you will have to use a feed type name that won't look correct: FT13 -> FNEXRAD; FT30 -> NNEXRAD). >At present, we still >keep them all mounted to waldo's disc via nfs, as I was not sure all >commands had been converted over to ADDE; I see from the Release Notes >that this is now complete. Well, it is pretty much complete, but I don't like how the ADDE cross section plotting routine, UACROSS, works. It is OK for upper air data, but too restrictive for GRID data. >In the Release Notes section McIDAS-X Significant Changes >Vendor-supplied Compilers vs gcc/f2c > >This section states to set Vendor= blank when using gcc. > >Following the Web pg. for installing, it says set Vendor=-gcc and this >is what I use and what works for me, using Solaris Sparc, 2.8 but using >gcc as we do not have Sun's compilers. Thanks for pointing this out. I just corrected the Release Notes page to match the installation instructions. The reason this discrepency cam up is that SSEC defaults the compiler on Solaris x86 to gcc/f2c. Since I have a number of sites that use Sun compilers, I changed the default to be -vendor. >Looking at the Release Notes for McIDAS 7.7, regarding upgrades for >earlier versions, and not sure I recognize what problems might arise >when I upgrade waldo from ver 7.5. Perhaps I am missing something. The "biggie" is in the decoding of mandatory level upper air data. In pre-7.7 versions of McIDAS, decoding was only done up to 100 mb. In 7.7, decoding is done up to 10 mb. In order to accommodate this, the schema for the mandatory level upper air data files had to be changed. What this means in practice is that when doing an upgrade from a pre-7.7 version of McIDAS, one has to: o build the new version of McIDAS in the ~mcidas/mcidas7.7/src directory (as user 'mcidas') o stop the LDM (as user 'ldm') o cd xcd_decoder_output_directory o rename, move, or delete the current mandatory level MD file o replace the copy of SCHEMA in the output data directory with the copy that comes with 7.7 (~mcidas/mcidas7.7/data/SCHEMA) o delete the RAOB.RAT and RAOB.RAP files from the output data directory; while you are at this, you might as well remove all of the *.RAT and *.RAP files from the same directory. This is not mandatory, but it can't hurt o install McIDAS-X 7.7: cd ~mcidas/mcidas7.5/src make uninstall.all cd ~mcidas/mcidas7.7/src make install.all o from a McIDAS session as 'mcidas' run: BATCH XCD.BAT BATCH XCDDEC.BAT o restart the LDM (as 'ldm') >I have not snooped on waldo, and do not recall whether the 7.5 setup is >different. If you know of anything, or a specific section of the >Release Notes I need to read, please let me know. I think that the above pretty well covers the XCD show stopper. Another thing to look at the Release Notes for is the list of applications that have been deleted from 7.7. If you are running a number of "home grown" scripts/batch files, etc. then it may be the case that you will have to convert those scripts to use new routines. This might be especially true when upgrading from 7.5 to 7.7. >I would like to start the McIDAS upgrade on waldo within the next few >days, so if I am missing something, please let me know. Please let me know if the above is not clear enough. >At this point, >I assume I get the new version into /home/mcidas and proceed just as I >have on terminals where I have upgraded from ver 7.6. Yes. >I will stop the ldm first. You don't have to stop the LDM until you are ready to uninstall the old version of McIDAS and install the new one. >Thanks Tom You are welcome. Again, let me know if you want me to stick my nose in during the upgrade. Tom
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.