20010301: mcidas7.7 replacing 7.5 at stc (cont.)

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 200102202133.f1KLXZL10511 McIDAS NEXRAD display

Alan,

>Looking at your message re: waldo and upgrading from ver. 7.5
>
>1.  waldo is not used for anything except as our ingest machine 
>    for the idd, running our ldm and maintaining our data files
>    for 7 or 8 other McIDAS terminals.  

OK.  Given this, it might function well as an ADDE server for the
spectrum of datasets that you create locally (XCD generated data
and the NEXRAD data).

>2.  re grid data; we are not decoding any right now.  I will try 
>    and take you up on looking at another site to instead of changing
>    our ldm for now.   How open are other sites in terms of allowing
>    access via ADDE?  papagayo is our idd backup, so I am not concerned, 
>    but is this sort of service widely available ?

Several sites have agreed to allow ADDE access to their data holdings.
To date, those sites are:

Unidata/NCAR-SCD
University of Nebraska-Lincoln
CU/CIRES (NOAA lab)
Plymouth State College
University of Georgia

Another site that will come online in the hopefully near future is the
University of Wisconsin-SSEC.  The machine to be installed at UW is
one that we (UPC) purchased as a replacement for the old, slow, failing
machine that now generates the Unidata-Wisconsin datastream.  The
datasets that the new machine will host will include high resolution
satellite imagery not currently available in the UW stream.

Another site that has expressed interest in participating more actively
in the IDD and in providing remote dataset access (through ADDE and DODS)
is the University of Oklahoma.

And, if that is not enough, I am always looking for more sites that would
be willing to help the community out by providing access to their
locally hosted data stores.  This effort is an integral part of the new
Unidata initiative we call THREDDS.  THREDDS sites will provide both
push (LDM/IDD) and pull (ADDE, DODS, Java RMI) access to datasets of
interest to the greater Unidata community.  This is an exciting new
undertaking for us since it promises to facilitate access to a wide
variety of data currently inaccessible (at least easily) to the Unidata
community.

>3.  since I will hold off on upgrading our ldm for now,  can you list or 
>    point me to a reference for the feed type names to use while still 
>    with ldm 5.0 ?   You mentioned a couple regarding NIDs data, but 
>    are there more ?

All of the data streams suppoted by the LDM can be found in:

LDM feedtypes
http://www.unidata.ucar.edu/packages/ldm/feedtypes/index.html

The generic names of FT0, FT1, ..., FT31 are always usable.  The
"Primary Name"s are aliases for these generic names.  As you will see
from the table, FNEXRAD is equivalent to FT13 and NMC3.  NMC3 is the
name that used to be the "Primary".  We replaced it with FNEXRAD for
the floater stream of _free_ NEXRAD images now available in the IDD.
NNEXRAD is the stream of _all_ free NEXRAD images in the IDD.  This is
a HUGE set of data, so huge that only the most robustly configured
sites (network and machine, and storage) can handle it.

All of the data in the NNEXRAD feed are available from the top level
IDD nodes.   This allows a site to request a specific set of radars for
local ingestion.  The trend we see is for sites to request all products
from 4, 5, or 6 NEXRAD sites in their area.  Well connected sites
(networkwise) seem to also want to ingest all of the base reflectivity
products also.

Sites that do not have the network resources to ingest all of the data
have a very nice alternative if they are running McIDAS:  ADDE access
to all of the data from all of the stations is provided all of the
time.  Any time you want, you can go to one of the ADDE sites that is
getting all of the NEXRAD data and look/copy/analyze whatever data you
want.  I think that this is very useful.

>4. If the switch to ADDE based commands is complete, does this mean that 
>   I no longer need to have the individual terminals mounted to waldo's 
>   data directory?  From your comment, I assume most commands (using 7.7)
>   get executed using ADDE, and a nfs mount is not necessary.

Yes.  When you transition your McIDAS use to all ADDE, then you no
longer have to have the partition containing data NFS mounted on your
clients.  I can guarantee, however, that you are not yet in this
position.  You may be after the 7.8 release of McIDAS if I can get the
MCGUI converted to full use of ADDE.

>5. Down to the specifics on upgrading from 7.5
>
>   rename or delete the current mand. level MD file  :  I assume the same
>   scheme is used to number these,  last digit of Jul day + 10 ?

Yes.  Sorry for not identifying the specific file(s) in the previous
email.  The mandatory upper air MD files are numbered 11 - 20,
inclusive.  What one has to do in the upgrade is rename or move the
current mandatory level upper air MD file so that the decoder will not
get confused.  You don't have to rename or move the previous days MD
files, however, since the decoder should not be writing to them.

>   replace the SCHEMA :  I will check for this in my decoder output dir. which
>   for us is /var/data/mcidas  (we use this for all our products)

You will find a copy of SCHEMA there.  I was necessary to copy SCHEMA
to the output data directory so that the ldm-mcidas FSL wind profiler
and NLDN lightning decoders could find and use it.  The reason for this
is they do not use McIDAS file location services to find files (i.e.,
they do not use REDIRECTions and MCPATH).  The XCD decoders, on the
other hand do use McIDAS file location services, so they don't care
where SCHEMA lives as long as the 'mcidas' account is setup (through
its MCPATH or through a REDIRECTion) to know where it is.  I have found
it easiest to simply copy the correct version of SCHEMA to the output
data directory AND setup a REDIRECTion in the 'mcidas' account to point
to this copy.  This is how your account is setup, so you will need to
copy the 7.7x version of SCHEMA to the output data directory as I
indicated previously.

>   delete RAOB.RAT, RAOB.RAP    again these should be in /var/data/mcidas

The reason for this is that they play a part in the upper air decoding.

>6. We do not have any homegrown stuff, so this should not be an issue.

OK, this makes life a little easier for you.

>Let me know if I have interpreted your comments correctly.

Yup, you have.  Again, please let me know if you want me to help out
in the upgrade.

>Thanks

Talk to you soon...

Tom