19990527: Out of time.

>From: Jim Heimbach <address@hidden>
>Organization: UNCA
>Keywords: 199905262030.OAA14674 McIDAS-X 7.5

Jim,

>     Many thanks for your rapid and comprehensive response to my latest
>set of queries.  For awhile I thought I had the tiger by the tail, but am now
>feeling utterly clueless.  The bottom line is that I have simply run out of
>time with today being my last day at UNCA this AY.  So it looks like I
>am foundering until next fall, and that part of what I have will die on July
>1.  

I am sorry to hear this.  If you like, I can help you out by configuring
McIDAS-XCD for you on the system you are running the LDM from.  This
would, at least, get you by the Unidata-Wisconsin datastream changes
that will occur on July 1.

>     Here's the deal.  I am running ldm on an ULTRA-2 (great machine)
>which also has McIDAS-X 7.1 on it.   This ldm is doing the McIDAS data
>ingestion via the IDD and has been doing it for some time quite flawlessly. 
>Typhoon has been writing the McIDAS data to another older server,

So, 'typhoon' is the machine the LDM is running on, AND it is the machine
on which McIDAS-X 7.5 is installed on; true?

>and
>has its /home and /data nfs'd to other machines including two PC's running
>Linux.

OK.

>I had hoped that things would blend nicely with the PC's, and
>indeed they did for the AREAs and some others.  But now I see the
>scheme I have is pretty messy with the paths and locations being out of
>line.  

Having the file system where the actual data files cross mounted to
several machines is the typical way that other sites are running.
As users progress into ADDEland, they will find that they no longer have
to have this kind of NFS mounting.  It has been our experience that
ADDE access to data can be a lot faster than direct access to the same
data files on NFS mounted drives.

>     Tom, I'm having a problem with the excessive amount of time needed
>to stay current with McIDAS.

I understand your frustration.  McIDAS-X underwent a significant 
transformation when ADDE was introduced.  The bad news is that there is
new stuff to learn.  The good news is that the use of ADDE can actually
simplify one's installation in the long run.

>(I hasten to add that once a new setup is
>running, it is very stable and it requires minimal attention.)  I'm a
>meteorologist who has a sideline in UNIX systems.  The department does
>not have a systems guy and probably will never have one, so I'm it.  I
>enjoy working with such stuff, but I cannot devote the time that is needed
>to keep up with the changes.  Alex Huang and I have been talking over
>strategies on this matter.  First we have to decide what is the minimum
>weather data needed for our program, then what the sources will be. 

OK, this is the same sort of evaluation that a number of small programs
are going through now.

>Presently we are receiving DIFAX, DD+ (both through ALDEN), and
>McIDAS and NLDN through IDD.  We were receiving NIDS through the
>IDD, but budgetary constraints cut that.

The good news a short way down the road will be the availability of
a 10 km national composite radar product in the IDD stream and the
eventual free availability of NIDS products further down the road.
This development is fairly new, but indications from the NWS point
in this direction.

>My hope was to have all these come through typhoon.

There is no reason that they can't.

>Some time ago I went to a GEMPAK workshop. 
>Good stuff, but not as applicable to an undergraduate program as McIDAS. 

Actually, the newer versions of GEMPAK and GARP (a graphical interface
for GEMPAK capabilities) make it extremely useful for undergraduate
programs.

>If we are to continue with McIDAS, I think my best hope is to get to a
>workshop and get the XCD / ADDE under my belt in an intense, focused,
>session.  

Attending a workshop would help a bunch.  The changes must seem pretty
overwhelming from your perspective, but they are actually pretty easy
to come up to speed on.  My GUI development work aims at making the
use of McIDAS as easy as it could possibly be.

>     If I could offer a vote:  I would like to see a simple basic system
>which resides on a given machine.  This system would be a somewhat
>specialized browser, having function keys and a command line.  Data
>would reside on some centralized computer(s) and would not necessitate
>the dissemination to local sites.  Images could be saved and printed locally
>at a touch of a key.  A new widget is added?--simply download a new
>browser, preferably as a binary.

What you write sounds exactly like the Java development effort that we
have embarked on.  Simple-to-use graphical interface; distributed data
sets; automatic updating of executable code; all at the touch of a
button AND support for any Java compatible computing platform (like
Windows, for example).

>Or is this the goal of ADDE?

ADDE really can make part of your wish list true.  You really don't have
to be ingesting data locally IF you have a site that is willing to let
you and your program access their machine that is ingesting/decoding
data locally.  Once you use ADDE like this, you _will_ be a convert;
I was.

>     Thanks for your patience, and I'll contact you next fall.

No problem.  If you havn't already left (or if Alex hasn't left) then
let me know if I can help you get things configured using XCD.

Tom