20010228: NEXRAD Level III data display in McIDAS-X (cont.)

>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