>From: "James R. Frysinger" <address@hidden> >Organization: College of Charleston >Keywords: 200111061842.fA6Igt112242 LDM binary install Jim, >Hmmmm. I've heard that reading that trilogy can become ... Nevermind. An obsession? Yes. >You know the rest. Years ago a shipmate of mine got hooked on the >trilogy and then my wife read them. I couldn't seem to get interested, >but I'm wiser now. Maybe I'll give it another go. The first three times I tried reading The Hobbit, I just could not get into it. I think it took the pressure of physics finals while I was a Masters student to put me in the proper frame of mind to need that level of escapism. Since then, I have reread the Hobbit and Trilogy on the order of once eer other year, although this time it has been over 5 years. >Going to see the movie? Absolutely. >I've got to confess. We're obviously getting some data showing up >because I've been sitting here playing with, uh, make that >investigating today's GOES East pix around St. Thomas. My colleague and >I may do a micro-environment weather study of that area in association >with the University of the Virgin Islands for their astronomical >observatory. If you are looking at the images using McIDAS, you have to remember to check to see who you are requesting the data from (who you are pointing to for the ADDE dataset you are looking at). The way to do this is to run; DATALOC LIST If you are using the MCGUI, you can also do this by clicking on the ADDE Client Routing Table configuration button at the top of the GUI (the button immediately to the right of the button with the big, red Z. >He's got a portable wx sta and we may need to go down >there someday to set it up to serve as a weather data source. Purely >for the sake of Our Country and Science, mind you; we would promise not >to enjoy ourselves. Sounds like an ugly job, but someone has to do it ;-) >Of course, those plans would include piping the >data up to weather.cofc.edu then serving it to the community. Yes, of course. I have often wished for a site down in the Virgin Islands so that I could make a site visit. >Anyway, I'm reading current GINIEAST data, at least. I'll tackle the >guidance you've provided on the decoders next and see if I can increase >our resources. Hmm... GINIEAST data is not part of the IDD data offerings. You must, therefore, be pointed at one of the servers that has the data. This, of course, is the beauty of ADDE! >By the way, I've already got scour set up in the cron file. (Plus >those other crontab lines.) Didn't want the bit bucket to overflow onto >the floor while I was futzing around. The scour program periodically >complains about various subdirectories not being there -- probably >because I haven't set up the decoders to make/fill them. Excellent. >Later, I'll remove the user ldmcidas. I'll also want to clean up any >unused directories left over from my aborted make from source for ldm. >That's later.... Sounds good. >From address@hidden Sat Dec 8 20:14:51 2001 >Did the stuff below; also chopped off the obsolete material at the end >of that file. Also did the ldmadmin pqactcheck and got a report of >"syntactically correct". Good. >Seems like there was a command that I could use last year to watch the >stuff coming in and getting sent to the decoders. The easiest thing to run is: ldmadmin watch This just runs pqutil for you. >Checked the man pages and tried > > pqutil -rvw /export/home/mcdata/ldm/data/ldm.pq > >but that didn't show me anything that ldmadmin watch did. Bailed out >with ^C. If ldmadmin watch doesn't show anything, you aren't receiving anything. The other thing to try is notifyme: notifyme -vxl- -o 3600 This asks to see all of the stuff in your LDM queue going back one hour (3600 seconds). Since '-h <host>' is not specified, the request is to your own machine (localhost). If you see nothing, verify that your upstream feed site is getting data: notifyme -vxl- -o 3600 -h <your uptream LDM feed host's name> >I've also tried the pqmon command and get some nifty looking numbers, >but the man page for that doesn't say what they mean, nor does the LDM >System Adminstrator's Handbook (html version on the ldm-mcidas page) >that I can find. It's supposed to be really useful for determining >whether the queue size is correct, they say. Yes, it is. If your queue is on the order of 600 MB, you are AOK as an LDM leaf node. >Before my dime gets used up, here's my crontab file: > > weather crontab -l > 0,20,40 * * * * bin/ldmfail -p "pluto.met.fsu.edu" -f >"cirp.met.utah.edu" > 35 * * * * bin/ldmadmin dostats > 0 0 * * * bin/ldmadmin newlog > 0 1,4,7,10,13,16,19,22 * * * bin/ldmadmin scour You will eventually need to add running of the McIDAS mcscour.sh routine to this list: # # Scour McIDAS XCD data files # 00 21 * * * decoders/mcscour.sh >Again, please feel free to ssh in and to scope out the setup. I will later today. I am trying to track down a bug in the McIDAS MAP command that only surfaces when the code is compiled and linked using the gcc/g77 combination. As soon as I can solve this one, I will be releasing an Addendum to McIDAS that should allow all systems to build using gcc/g77 instead of vendor compilers or the gcc/f2c/mcfc combinations that now work. This should make life easier for folks since g77 is typically bundled witg gcc distributions. Tom
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.