20000211: Unidata-Wisconsin products removed in July of 1999 (cont.)

>From: "Karli Lopez (McIDAS)" <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200002010754.AAA03412 datastreams ROUTE PP BATCH LDM

Karli,

>Alright, the Sat/Topo imagery is being generated once again! At least
>it seems to since the new dates are shown in the routing table.  I
>checked lwtoa3 again just to be sure, and the files are there.  It
>seems it just was a batch.k misconfiguration problem (I wasn't aware we
>needed to make such changes, I know now...).

Sounds good.

re: discontinued products
>Yeah that's what I meant.  We've never gotten Administrative Messages
>in the first place.  And what about that Wind Profiler? (this is just
>out of curiosity)

The FSL wind profiler data is avaiable in hourly summary and 6-minute
forms throught the FSL2 feed in the IDD.  The ldm-mcidas decoder,
proftomd, can decode either/both of these products into McIDAS compatible
MDXX files.  The profiler network is basically in the central portion  of
the US, so it would probably not be of much interest to you.

re: North American and Global Initialization GRID files
>and so we will never see them again...?  (well what I mean is are there
>alternate sources?)

The IDD contains all of the model data from NCEP.  Instead of just looking
at these two small pieces of the full data set, you can decode all of
it into McIDAS GRID files.  The thing that is different is that the
ordering of the grids in the XCD GRID files is not set.  The Fkey menu
actions for plotting gridded data used to rely on that ordering.  With
the conversion to ADDE, the Fkey menu no longer needs the specific ordering.
The MCGUI, on the other hand, was not ADDEized since ADDE was not finished
enough to make the change.

Now, if you wanted to, and if you are decoding all of the model data
in the IDD using XCD, you could run the UWGRID command to recreate
the North American and Global initialization GRID files locally.  This
would allow you to keep working just the way that you were before the
products were removed from the datastream.  In order to facilitate this,
I wrote the Bourne shell script, uwgrid.sh.  This is simply a wrapper
around the UWGRID command (like batch.k is around BATCH).  uwgrid.sh
gets installed in the ~mcidas/workdata directory.  You should look
through it to see what you need to do in order to create the NA and Global
GRID files.

The other alternative is to change a couple of McIDAS environment
variables and point  at the RTGIRDS/NGM and RTGRIDS/AVN datasets.
After doing this, and assuming, of course, that you are decoding the
grids with XCD, the Fkey menu will work directly off of the new files.
I can give you more details if you decide to go down this route, or
you can look up information in the online McIDAS Support email archives:

Unidata McIDAS-X Home Page
http://www.unidata.ucar.edu/packages/mcidas/mcx

Select the 'Support archives' link in the left hand side frame under Support.
Use uwgrid, ngm, and avn for search keys.
  
>As for the this problem I suspected ADDE would be involved, and I had
>wondered why it was taking so long for the image to load, and why I
>would get up to date Topo/Sat images.

You have to admit that this was pretty cool notwithstanding the time it took
to load the images.  Your requests were coming all the way to Boulder
and being fulfilled without you even knowing it (modulo the slowness
factor).

>I have not much with setting up
>ADDE so the cause for the problem was both the server they were setup
>for and a misconfigured ADDE.

I figured that the problem.

>Calling DATALOC I got the following output:
>
>DATALOC LIST
>------------------------------------------------------------------------------
> ------------------------
>
>Group Name                    Server IP Address
>--------------------         ----------------------------------------
>BLIZZARD                     144.92.109.163
>MYDATA                       <LOCAL-DATA>
>PLANET                       <LOCAL-DATA>
>RTGRIDS                      <LOCAL-DATA>
>RTIMAGES                     ZERO.UNIDATA.UCAR.EDU
>RTNIDS                       <LOCAL-DATA>
>RTNOWRAD                     <LOCAL-DATA>
>RTPTSRC                      <LOCAL-DATA>
>RTWXTEXT                     <LOCAL-DATA>
>TOPO                         <LOCAL-DATA>
>
><LOCAL-DATA> indicates that data will be accessed from the local data director
> y.
>DATALOC -- done

OK, a couple of things here

First, you were pointint to our machine, zero, for the realtime images.
Second, you were pointing to a machine at SSEC for access to the BLIZZARD
datset.

>DATALOC ADD RTIMAGES LOCAL-DATA
>DATALOC: Problem writing strings, probable setup error

This is a problem.  It seems to be telling us that ~mcidas/data/ADDESITE.TXT
is not writable.  What do you get when you do a:

DMAP ADDESITE.TXT

This will tell us exactly where this file is.  If it is not in
~mcidas/data (I am assuming that you are doing this as the user
'mcidas'), then you have setup problems.

Also, what is the setting for MCTABLE_WRITE in your Unix session?

Each user can have a private copy of a file named MCTABLE.TXT and can
share any number of other files through settings of his/her 
MCTABLE_READ environment variable.  This variable contains a list of
fully qualified file names to search through when trying to figure
out which server to go to for a particular dataset.  The recommended
setting for the user 'mcidas' is:

MCTABLE_READ="${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT"
MCTABLE_WRITE="/home/mcidas/data/ADDESITE.TXT"

MCTABLE_READ says that the user 'mcidas' reads both ${MCDATA}/MCTABLE.TXT
and /home/mcidas/data/ADDESITE.TXT to find out where to go to fulfill
a data request.  $MCDATA in the user 'mcidas' case should be
/home/mcidas/workdata.  MCTABLE_WRITE says that when the user 'mcidas'
does a DATALOC, the information should be written into
home/mcidas/data/ADDESITE.TXT.  The error you got when trying to do this
seems to indicate that this file is unwritable for some reason (or
your MCTABLE_WRITE setting is incorrect).

Users other than 'mcidas' have the following settings for their
MCTABLE_READ and MCTABLE_WRITEs:

MCTABLE_READ="${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT"
MCTABLE_WRITE="${MCDATA}/MCTABLE.TXT"

These look the same as for the user 'mcidas' except that MCDATA for
the non-'mcidas' user will be ~user/mcidas/data, a directory local to
that user's account.
 

>> What you need to do is see if your datasets are setup:
>>
>> <login as 'mcidas'>
>> <start a McIDAS-X session>
>> DATALOC LIST                       <- see who you were getting images from
>> DATALOC ADD RTIMAGES LOCAL-DATA    <- get them locally
>> DSINFO IMAGE RTIMAGES              <- see if they are setup
>>
>> If they are setup, then do the following:
>>
>> IMGLIST RTIMAGES/GE-VIS.ALL
>>
>> You should get back a listing of all of the GOES-East VIS images on
>> your system.
>>
>> If you do not get back a listing, or if the files are all old, then the
>> ingestion/decoding of your imagery and/or setup of your ADDE datasets
>> is suspect.

>To be honest I don't know what the BLIZZARD dataset

The BLIZZARD dataset is the one that goes along/is used by the online
Learning Guide:

http://www.unidata.ucar.edu/packages/mcidas/mclearn/learn_guide.html

>(is it Radar or NLDN related).

Nope.  The dataset has satellite imagery, point source, and gridded
data.

>Anyway I couldn't change the information with RTIMAGES
>so I know somethig's still wrong with the configuration.

Check for write permission problems.

>So far we had
>the mcadde account created, and ADDE partially set-up for out previous
>version of McIDAS (7.5 I think).  We have the account running, as well
>as the server, but all I did for setup this time was run the uninstall,
>make and install processes.  I will be going to review and apply if
>necessary the Account configuration steps to make sure I didn't miss
>anything.

OK, a quick 'telnet breeze.uprm.edu 500' shows that the port is setup
correctly.  A quick DATALOC from my machine shows that the server
setup is not complete/correct:

DATALOC ADD RTIMAGES BREEZE.UPRM.EDU

Group Name                    Server IP Address
--------------------         ----------------------------------------
RTIMAGES                     BREEZE.UPRM.EDU

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done

DSINFO IMAGE RTIMAGES
    No Datasets found of Type: IMAGE in Group: RTIMAGES
DSINFO -- done

>I do have another semi-related question: For all of the accounts that
>we have previously set up under McIDAS 7.5 (or 7.1) should we redo the
>Redirections (REDIRECT REST LOCAL.NAM, etc.) and BATCH "MYDATA.BAT
>configuration steps?

You will only have to do these if the locations of McIDAS data files
changed.  I suspect that they have not changed.

The setup for the ADDE remote server shouldn't take much time.  The
steps are detailed in:

Installing the McIDAS-X ADDE Remote Server
http://www.unidata.ucar.edu/packages/mcidas/mcx/adde_mcx.html

The gist of the configuration is:

o the user 'mcadde' is kind of an alias for the user 'mcidas': it shares
  the same HOME directory, but you should not be able to login as it

o the file ~mcidas/.mcenv sets up environment variables needed for
  McIDAS sessions.  This file is read by the remote ADDE server processes

o 'mcadde' finds McIDAS files exactly the same way that 'mcidas' does;
  this is true since 'mcadde' is essentially 'mcidas' (see above)

>Thanks again Tom.

It sounds like you are almost finished; hang in there.

Tom