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

20011218: setup of ldm-mcidas, LDM, XCD, and McIDAS at COFC (cont.)



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

Jim,

re: the list of servers is growing
>       Just when I was thinking it couldn't get any better than this...

Hopefully, we can make McIDAS easier to use as we evolve the cooperating
server network that will bring sites more-and-more data over time.

re: GEMPAK

>       No, I haven't seen that yet, but I've got both the binary and the 
>source code at home here. I was thinking of giving the binary a quick 
>and dirty try this afternoon just to see where the smoke starts coming 
>out of my box.

OK.

re: Learning Guide

>       I've got the older McIDAS 7.7 Learning Guide printed out from last 
>year (on a shelf downtown) and I had worked my way through that on 
>McIDAS 7.8 before we killed the computer. Of course, a year has passed, 
>more brain cells have died, and McIDAS has been revised. Sounds like a 
>trip through the new Learning Guide would be well worth the time spent.

It can't hurt.  If the information is old hat, the reading is quick.  If
not, it will be useful.

re: using unremapped data for analyses

>       OK. I didn't know enough to know that there was a difference. First, 
>I'll look up "remapping" and see just what you mean by that; I'm 
>guessing it has to do with the type of geographic projection in the 
>graphical map.

Exactly.  The idea is to use the data in as close to its original state
as possible.  This way, uncertainties introduced from projection
transformation can be kept down to a miniumu.

>But in the meantime, you've probably saved me from 
>spending time and disk space on less than optimum images for my study. 
>This sea breeze bit is very small scale so resolution is extremely 
>important as compared to, say, Cat 5 hurricanes!

OK, so for right now you will wanting to be looking at the GINI data
for VIS because it is higher in resolution than the VIS images in
the Unidata-Wisconsin feed.

>       And the rest of your message has given me a good worksheet to use in 
>order to learn and use the commands. It also helps out my efforts to 
>sort out the data structure involved here -- who does what to whom.

Super.

>By 
>the way, I don't know if I've mentioned it, but I have found it 
>extremely useful to use McGUI to make something happen and then to look 
>at the command window to see what mcidas commands got issued to make 
>that happen. That McGUI sure saves a lot of typo-prone typing (BOB says 
>"thank you!") but the command details are going to prove necessary for 
>writing batch files. I've already flipped to the command line on 
>occasion to 'tweak' a display.

Wonderful.  This was, of course, the intention of including the GUI
Console in the first place.

>       One advantage to what I'm doing now is that I'm sorting out what 
>displayed information is useful for first-look interpretation. (For 
>instance, it would be neat if I could kluge SSTs and GOES images 
>overlaid with wind vectors or data and temperature contours or data in 
>the same image frame, but I don't think that's possible.)

This _is_ possible.  Nearly anything you can imagine is possible in
McIDAS, you just have to figure out how to do what you want to do.  One
thing about combining SSTs, cloud imagery, and observational data:  if
the SST you are interested in is in an image, you have to combine that
image with the satellite image, not overlay it.  Overlaying with
observational data (plots and contours) is, as you should have seen
with the MCGUI a piece of cake.

>A handy 
>button for McGUI would be a "refresh all graphics and images", I think. 

Meaning recreate the same display using all newly available data?

>There's probably a way to write a batch file or to define a user 
>function key to do this, but since I'm still in the process of trying 
>out various combinations and watching them over time, that magic button 
>would be handy.

Yes, it could be done reasonably easily in a BATCH file or other script.

>       Maybe I'll migrate into building a loop with half-hour frame spacings 
>and see what that looks like running in a loop. I know now how to save 
>images in various formats. Is there a neat way to load those images 
>back into McIDAS to redisplay for students using the looping features? 

Actually, I am just about to release an addendum to Unidata McIDAS (Version
7.804) that contains a GUI interface to saving frames/loops of frames
in McIDAS PIX format and then being able to restore them.  For right
now, you can play with SVF (save the frames), LVF (list information about
saved frames) and RVF restore the saved frames to see what can be done.

>Else, I could use a batch program to loop images separately inside an 
>HTML frame which would make it easier to display on non-mcidas 
>machines, such as our smart classrooms' Muck'n'slosh computers. (Ooops, 
>a little attitude leaked out there....)

Check out the image loops available at:

http://mcdemo.unidata.ucar.edu

>       Geez, I really did mean for this to be a short reply! Gotta take my 
>thinking cap off and get to work learning the basics.

Got to run.

Tom