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

20021028: Setting up LDM for McIDAS-XCD (cont.)

>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