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

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

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.

  • 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