[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20011211: setup of ldm-mcidas, LDM, XCD, and McIDAS at COFC

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install


>Wow! I'll say it again. Wow!

Again, believe it or not, everything I did was documented in online web
pages (more or less).  I strongly agree with your comment that the
information is way too spread out to be easily comprehended by a new
user.  I, for one, will be using your and other's comments to try and
make my McIDAS web pages more compact, readable, and generally useful.

>> 1) corrected a typo in the 'xcd_run DDS' action in pqact.conf.  The
>>    action previously read:
>> DDPLUS|IDS      ^."     PIPE
>>         decoders/xcd_run DDS
>> HRS     ^.*     PIPE
>>         decoders/xcd_run HRS
>>    it should read (and now does):
>> DDPLUS|IDS      ^.*     PIPE
>>         decoders/xcd_run DDS
>> HRS     ^.*     PIPE
>>         decoders/xcd_run HRS
>       I confess, I stared at the above for five minutes before I spotted the 
>typo. Darned computer fonts are getting smaller every year.....

Me too!  It was a little easier for me since I had a good pointer to where
the problem had to be.  The ingestion of gridded data into XCD was working
fine, but the ingestion of test data was not.  This narrowed the search
to the:

DDPLUS|IDS      ^."     PIPE
         decoders/xcd_run DDS

lines.  After that, it was simply a matter of looking at each character.
And, yes getting older sucks!

re: NMC3 feed type for FNEXRAD data
>       How will I know to do that? Will this come out via one of the emailed 

The commentary is in the web pages for the LDM, but like I said
previously, the information is way too spread out.  I was planning on
helping you get fully setup with LDM/McIDAS, so you have not been
abandoned.  The good news is that once you have one package setup and
the LDM running, setting up another package is easier.  The main reason
for this is that you should have gained the confidence on being able to
modify files and change how the LDM gets and processes data.  The bad
news is that the XCD setup in pqact.conf is very simple, after all, we
only had to worry abougt 4 lines!  The same for GEMPAK is not.  The
good news there is that there are well documented entries that get
added to pqact.conf for GEMPAK use.

re: request for NLDN data
>       I sent the request off a couple of hours ago. Many thanks! This is a 
>datastream that I hope will prove particularly useful in my study of 
>sea breezes. In that message, I acknowledged the restrictions on the 
>distribution of this data and its depiction.

Good.  David is very responsive, so this request should be approved
rapidly.  Once they configure their LDM to allow weather.cofc.edu to
request NLDN data, you will start getting it automatically AND it will
be decoded and usable in McIDAS (because we already put in the
necessary action in pqact.conf).

>       I just did some of these things myself, from here at home. Alright! I 
>can see that I have a lot to learn about using MCGUI; is there a users' 
>manual for it yet?

Unfortunately, no.  It is relatively easy to use, so some experimentation
should get you going.

>F'rinstance, I couldn't figure out how to select the 
>particular GOES image I wanted; it appears to always select the latest 
>one. And is there anyway, once running, to drop out of MCGUI and go 
>back to the older image window?

The concept currently implemented in the MCGUI is for dispay of the most
current image of any type, OR the display of a loop of the most recent
images.  Selection of a particular image will be added in a future

>       I'll try it from the local terminal ASAP, almost certainly tomorrow.

Good.  I think you may run into the lack of colors thing, but you now
know that you can get around this by exiting other applications that
are sucking up all of the colors.

>       "Where to from here?" is next on my mind. I'm convinced that finishing 
>my McIDAS installation at home has to have some priority,

You should be able to do this in short order.  A complete build/install
on my 400 Mhz machine at home takes on the order of 35 minutes.  The
speed record for building McIDAS is held by Plymouth State College
who built on a dual 1 Ghz P4 machine running FreeBSD in about 7 minutes.

Configuration of McIDAS to serve data takes more time, but your machine
at home doesn't need to serve data (except for TOPO which should always
be accessed as LOCAL-DATA).  All you have to do is:

o build
o install
o bring up your first McIDAS-X session by running 'mcidas config'
o run a McIDAS session with MCGUI and open the Client Routing table
  configuration widget and setup where you want to access data
o look at the weather
o provide me feedback on what you would like to see done with the MCGUI

>but I suppose 
>that installing GEMPAK at the college should get first crack. With the 
>holidays coming up, I'll have more free time (minus a week's vacation 
>in Ohio, hopefully) and I'm sure that you have some holiday plans too. 

My holiday plans are to work on the MCGUI :o)

>The McIDAS/linux installation is something I can probably piddle around 
>with on my own, now that I have an operating McIDAS/Unix in front of 

It really shouldn't atke long.

>The hardest obstacle may be setting things up to get the data from 
>'weather' to my home computer, although I _think_ I know how to do it.

Again, why move the data to your machine.  ADDE makes this unnecessary.
If you will want to run GEMPAK from home, on the other hand, you will
need to either NFS mount data file systems or run an LDM and ingest
and decode data at home.  I think that this is where McIDAS really shines.

>       My track record, then, favors going for installing the GEMPAK program 
>on 'weather' before holiday plans intervene.

I would finish any McIDAS related items now before you totally forget where
you were in the process.

>About all I remember about 
>that from last year is that I need a separate password for the download 
>page; or is it the same as the UNIDATA stuff now?

The download of Unidata packages now requires that you register as a
Unidata participang (my.unidata.ucar.edu) and then go to the appropriate
package home page and download.  Getting a separate password for an
FTP is now not necessary.  You will, of course, have to remember the
password that you chose when registering.

>I may give 
>downloading GEMPAK a whirl while I'm downtown.
>       Any thoughts?

I think that GEMPAK installation and configuration will take some time
since you are new to it.  I would recommend that you try and finish
McIDAS stuff and then go on to GEMPAK, but I think you are almost finished

>       Again, many thanks for your 'clean up' action today,

No worries.

>Tom. I do indeed 
>save all your messages and I find that I'm learning a lot by going 
>through this with you. That's not to say I fully understand all that 
>you've said, but at least it gives me something comprehendable. I've 
>read the online docs, but they seem easier to understand in retrospect 
>than they do upon first encounter.

I am happy to hear you say this.  The problem with me writing the web
pages is that I know how things work, so the information on the web
pages is old hat.  For someone new, I can well imagine that the
learning curve is daunting.

>I may also try again to set up 
>another user account that we can use for training others while I'm 
>downtown; for sure I won't forget to do 'mcidas config' this time!

The setup in your account looked very good.  All I did was move the
definition of path down below the McIDAS stuff, and that was most
likely not necessary.  Everything else looked good and worked right
out of the box, so to speak.

With your permission, I may jump on later and setup NEXRAD data
ingestion; filing; and McIDA ADDE service of it.  Also, one last thing
left unattended to was the scouring of imagery being written into the
/export/home/mcdata/ldm/gempak tree.  This will require an FTP and an
additional crontab entry or two in the 'ldm' account.  



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.