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

20030324: NLDN display at usf (cont.)

>From: "Happel, Shelly" <address@hidden>
>Organization: USF
>Keywords: 200301091811.h09IBGt26938 ldm-mcidas nldn2md

Hi Shelly,

>Pesky me again! A couple of things... I'm not exactly sure what the issue
>is.
>
>The NLDN is saying that the SCHEMA isn't registered, according to the
>attached ldm-mcidas.log.

Since the NLDN decoding was working fine, and since the indication is
now that the NLDN schema is not registered in SCHEMA (being registered
means it can be found in SCHEMA), it probably means that your SCHEMA
file in the data output directory got munged.  So, in troubleshooting,
the first thing I would do is a long list of SCHEMA in the appropriate
directory.  Since your system is setup to decode McIDAS data in
~ldm/data/mcidas, I would run:

ls -alt ~ldm/data/mcidas/SCHEMA

This file should be reasonably big.  For instance, the SCHEMA file in
the v2002 release of McIDAS is 481792 bytes.

>Also, our webserver at www.metlab.cas.usf/sridhara is supposed to have
>meteograms radiosonde and surface data - none of which are working and our
>web guy (sridhara) says it isn't on his side. Probably the adde server. 

Since the setup in the 'mcidas' account on metlab is to point at your
own data holdings now, I would bet that the MD files needed for
meteorogram and surface plots are no longer there.  If SCHEMA were
damaged/deleted as I speculate above, the result would be that you
wouldn't have these files.

>Do you have any spare time to help me with this? Nothing has changed with
>regards to the setup of the ADDE server other than the changes you made
>(which I SOOOOOOOOOO appreciate!). I'm hoping this is just a little tiny
>blip of a problem. 

OK, I logged on to metlab and did as I said above.  I found what I
expected:

[ldm@metlab ~]$ ls -alt data/mcidas/SCHEMA
-rw-rw-r--    1 ldm      mcidas          0 Mar 24 11:22 data/mcidas/SCHEMA
[ldm@metlab ~]$ cp ~mcidas/data/SCHEMA data/mcidas
[ldm@metlab ~]$ ls -alt data/mcidas/SCHEMA
-rw-rw-r--    1 ldm      mcidas     481792 Mar 24 15:16 data/mcidas/SCHEMA

Decoding can resume now since the decoders will be able to find the
needed schema in ~ldm/data/SCHEMA.

However, the question remains as to _why_ the SCHEMA file got munged
(it probably got deleted; the next time a McIDAS or ldm-mcidas decoder
went to get info from it, it got recreated, but with zero length)?

OK, I think I understand the problem.  You have a cron entry for 'ldm'
to run the LDM scour:

#
# Purge LDM data
#
0 1,4,7,10,13,16,19,22 * * * bin/ldmadmin scour >/dev/null 2>&1


What 'ldmadmin scour' scours is determined by the contents of the
file ~ldm/etc/scour.conf.  That file has the following entry:

~ldm/data/                      3

Which says to recursively scour all directories under ~ldm/data and
leave 3 days of data on them.  ~ldm/data/mcidas will be one of those
directories that gets scoured, and this is _bad_.  The reason it
is bad is that files whose time stamps do not change get deleted,
and the SCHEMA file is a prime example of such a file.

McIDAS data file scouring should only be done by a cron initiation of
the script mcscour.sh.  You _do_ have this entry in your 'ldm' cron:

#
# Scour McIDAS XCD data files
#
00 23 * * * decoders/mcscour.sh

What we need to do now (and I just did this) is to stop 'ldmadmin scour'
from scouring the ~ldm/data/mcidas directory.  There are a variety
of ways of doing this, but I chose to edit ~ldm/etc/scour.conf and
change the scouring of ~ldm/data to three entries:

~ldm/data/gempak                3
~ldm/data/images                3
~ldm/data/ldm                   3

This leaves off the ~ldm/data/mcidas directory, so you should not have
a repeat of the scouring that blew away SCHEMA.

However, all the work was not done.  Scouring of SCHEMA had a chain
reaction effect that caused the decoding of the TEXT data (like
fronts, etc.) in McIDAS to stop.  The fix for this was:

- stop the LDM

<as 'ldm'>
ldmadmin stop

- resetup XCD data decoding

<as 'mcidas'>
cd workdata
batch.k XCD.BAT
batch.k XCDDEC.BAT

- restart the LDM

<as 'ldm'>
ldmadmin start

Now, things should get back to normal.  We will know for sure in a
couple of hours.

>Sorry to be always bugging you! I hope you had a good weekend and that
>things are warming up in colorado. It's beautiful here! 

It snowed over 3.5 feet at my house last Tuesday-Thursday.  It was pretty,
but it was also a LOT of shoveling (2.5 days worth) just to be able to
get our of my long driveway.

>Warm regards,

Talk to you later...

Tom

>From address@hidden Tue Apr  1 09:32:47 2003
>Subject: RE: 20030324: NLDN display at usf (cont.) 

Hey Tom,

I neglected to write to you to THANK you for your help!!! Thank you thank
you thank you!!!!

I've been incapacitated by a lymphatic infection. What next?!? Geez! I'm
taking antibiotics every six hours. Bleh! 

So please accept my apology for not getting back to you sooner and I really
really appreciate you taking the time to fix our system. Stay warm!!

shelly