>From: Richard Massa <address@hidden> >Organization: UC Davis >Keywords: 200210282019.g9SKJIX04447 McIDAS-XCD scour Rich, re: mcscour.sh entries >Thanks... I'll change those entries to nine. I've got a 160GB disk, so I >think I'll have enough space. Yea, but you don't want to use all of it for decoded McIDAS data. >And when I mean dmsyn.k had crashed... I meant that it was eating 99.9% of >the cpu for a long time. Sorry for being unclear. Hmm... another Linux site reported the same thing today. Looks like there is another section of code that goes into an infinite loop on Linux when it doesn't on other OSes. I jumped onto atm20 and run the debug version of dmsyn.k by hand. dmsyn.k dumped core almost immediately. When I ran gdb, I found that it was in the mdkeys_() routine (in the McIDAS library). Since this is strange, I decided to get a listing of the output SYNOPTIC MD file: & lwu.k LIST MDXX0051 0.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 2.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 4.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 6.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 8.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 10.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 12.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 14.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 16.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 18.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: 20.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: This will undoubtedly look like Greek to you, but it tells me that the output file exists, but is garbage (the -2139062144 number in McIDAS is a missing data indicator). This, in turn, tells me why the dmsyn.k is hammering your system: the input file that it is reading/writing is munged to the point of no return. I stopped dmsyn.k and then deleted the ouput MD file: lwu.k DEL MDXX0051 and then restarted dmsyn.k. After this, the output SYNOPTIC file created was created and is now correctly being updated by the decoder. Also, the other decoder run by dmsyn.k, for ship/buoy data, is also running correctly. So, it looks like that the changes that were made to the mcscour.sh script somehow caused the output MD files to be corrupted. This would also account for your inability to do a surface plot. The solution to all of this (since you modified your mcscour.sh script to keep 9 days of data instead of 10) is for you to: o stop the LDM <as 'ldm'> ldmadmin stop <wait until all LDM processes have exited> o deleted all output MD files created by XCD decoders (you only have ones from today, so this is not a draconian measure): cd /var/data/ldm/mcidas rm -f MDXX* o restart the LDM ldmadmin start The new files that will be created should be OK. >Thanks a bunch for all of your help. No problem. Tom >From address@hidden Mon Oct 28 15:38:49 2002 >Subject: Re: 20021028: Setting up LDM for McIDAS-XCD (cont.) re: stop LDM, remove bad MD files, restart LDM >Done! I'm keeping the nine days because I've got some grad students who are >interested in having that much data, and because I've got the spare disk. >Everyone will be saving their workdata to another disk anyways. Thanks, Richard
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.