This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Clint Rowe <address@hidden> >Organization: University of Nebraska-Lincoln >Keywords: 200009151802.e8FI2Ob09947 McIDAS-XCD decode LDM pqact xcd_run Clint, re: who deleted xcd_run entries in pqact.conf >Oops! That would (of course) be me. Thought so ;-) >However, I must have done that when >I started decoding the LNG compressed images Wow, where are you getting LNG compressed images :o) (UW stream are PNG) >-- way back in late June or early >July -- and nobody told me we weren't getting data all summer! Thanks for >setting things straight. OK, one thing I ran into was the lack of disk space on your machine. Since it was obvious that McIDAS GRID decoding was going to run you out of space, I disabled it: <login as 'mcidas'> cd workdata decinfo.k SET DMGRID INACTIVE >I still can't start mcidas as mcidas, though (see >below). I will scope this out later today. >Mark also sends his thanks, since he now is looking at the data in >synoptic class. OK. >You can give him a hard time about not looking at any data al >summer next time he stops at Unidata. Yes, but how often is that!? re incorrect/future times on XCD ingested/decoded data files >I noticed this, too. I think this has to do with NFS mounted disks and clock >syncronization. The clock on chinook (data ingest) was a couple minutes behind >the clock on zephyr (data storage and server), so when zephyr puts a timestamp >on the file, that time will be in the future for chinook. See below: > >zephyr% ls -ltr *XCD >-rw-rw-r-- 1 ldm apps 284929520 Sep 17 19:02 DD002610.XCD >-rw-rw-r-- 1 ldm apps 190283776 Sep 18 11:49 DD002620.XCD >zephyr% date >Mon Sep 18 11:50:32 CDT 2000 > > >/apps/ldm% ls -ltr /data/mcidasd/*XCD >-rw-rw-r-- 1 ldm apps 284929520 Sep 17 19:02 DD002610.XCD >-rw-rw-r-- 1 ldm apps 190416640 Sep 18 2000 DD002620.XCD >/apps/ldm% date >Mon Sep 18 11:48:22 CDT 2000 > >If I sync the clock on chinook to that on zephyr, the problem disappears ># rdate zephyr. > >Mon Sep 18 11:55:33 2000 ># ls -ltr /data/mcidasd/*XCD >-rw-rw-r-- 1 ldm apps 284929520 Sep 17 19:02 DD002610.XCD >-rw-rw-r-- 1 ldm apps 192741376 Sep 18 11:55 DD002620.XCD ># Makes sense. >I don't plan on fixing this, since I hope to get our new server up and >running this month. OK, I just wanted to make sure that you were aware of the discrepency. >I did the mcscour.sh as mcidas on zephyr, since that's where the data are >physically located. OK. You will want to look at this setup: o possibly remove the scouring from 'ldm's chinook account o revisit the setup in ~mcidas/workdata/mcscour.sh (McIDAS environment variables potentially have to be (re)setup) o in the future, it may be best to scour the data files from the machine that is running the LDM and let 'ldm' do it >You didn't see it when you were on chinook, since the >crontabs are set up on a machine-by-machine basis. I'll remove it from >ldm's on chinook, so I'm not trying to do it twice. OK. re: Harry's noticing that the images were missing >Is his inquiry in the e-mail archives for posterity? Yes, and so are Dave Dempsey's now (he checked in this morning). Tom