[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20021021: Setting up LDM for McIDAS-XCD (cont.)
- Subject: 20021021: Setting up LDM for McIDAS-XCD (cont.)
- Date: Mon, 21 Oct 2002 17:20:49 -0600
>From: Richard Massa <address@hidden>
>Organization: UC Davis
>Keywords: 200210150109.g9F19F112387 McIDAS-XCD LDM
Richard,
>Okay... I was wondering if you could tell me if there is any way to make the
>messages in XCD_START.LOG more verbose...
No, not directly. The logging level for McIDAS executables can be changed,
but the data monitors are being (re)started by startxcd.k with a preset
log level.
>I'm still banging my head on getting
>SAO/METAR DATA decoded properly, as I'm not seeing any MDxxxx files being
>created after I consolidated the xcd_run and ldm-mcidas directories, and I
>haven't even observed dmsfc.k running.
>SAO/METAR products are included in the IDS|DDPLUS or the HDS streams,
>arent they?
Yes.
>I'm seeing intermittent times when dmgrid.k becomes a zombie and I get the
>message that m0grabyt is returning -4 (and when I spied in the m0grabyt source
>code, it seemed that -4 indicated that mcidas isn't running along with a
>cryptic string). I can't find an action that causes this to happen.
This error typically indicates that the grid decoder pointer file, GRIBDEC.PRO
is empty (zero length).
>I'd appreciate your help. I've tried stopping and starting the ldm,
>re-installing and re-compiling both ldm and mcidas, and I'm sort of out of
>things to try at the moment.
I am logged onto atm20 at the moment and snooping around. I setup an
environment where I could run DMSYN by hand, and it terminated with
a segmentation violation. Since McIDAS turns off dumping of core files,
I have tried to setup a separate environment in which I can run DMSFC by hand
and tell McIDAS to dump a core file. I just got a segmentation violation
but no core file. OK, now I see it. Bash uses ulimit to control the
limits. I just set it the core dump size to unlimited (ulimit -c unlimited).
Hmm... Now, DMSFC (dmsfc.k) is decoding surface data (SAO/METAR), but
none of the other decoders are producing output data files. Very strange
since they were working at one point!
I'll keep looking and let you know what I find. Some of this will probably
have to happen tomorrow (I have to leave by 5:45).
Tom