20040408: Vietnam and GEMPAK GRIB decoding (cont.)

>From: Mai Nguyen <address@hidden>
>Organization: National Center for Hydro-Meteorological Forecasting of Vietnam
>Keywords: 200312020023.hB20N4p2027742 IDD LDM Linux GEMPAK

Mai,

>Thank you for your precise guidance.
>
>1) I've done the security procedures as recommended in
>your previous email.

I am glad.  Leaving a Linux machine open to security attacks is way too
easy to do and usually has disasterous consequences.  We will scan you
machine to see if everything is locked down later today or tomorrow (I
am going skiing today).

>2) ldmd is started fine in the booting. In fact, the
>files in /etc/rc5.d is not @S95ldmd but @S05ldmd But I
> guess it should be fine. The ldmd's queus are present
>and rc2.d, rc3.d, rc4.d and rc5.d. Is that what it
>supposed to be?

No, it is not as it should be.  I made a mistake in the order of
start/stop directives in /etc/init.d/ldmd.

Please do the following to correct my mistake:

<as 'root'>
cd /etc/init.d
chkconfig --del ldmd

- edit ldmd

  change:

  # chkconfig: 2345 05 95

  to:

  # chkconfig: 2345 95 05

chkconfig --add ldmd

The first number contains the run levels in which the script should be
run.  The second number contains the number that determines when in the
boot sequence the script should be run at the particular run level.
The higher the number (e.g., 95), the later in the boot sequence the
process will start.  We want the LDM to start late in the boot procss,
not early.  The third number determines the sequence in the shutdown
level that the script is run.  We want the LDM to be shutdown early in
the shutdown sequence.  The sum of the second and third numbers should
typically add to 100.

After then change, you should see links named K05ldmd in the
directories /etc/rc0.d, /etc/rc1.d, and /etc/rc6.d, and links named
S95ldmd in the directories /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, and
/etc/rc5.d.

I apologize for my mistake;  I didn't read down far enough in
the man page for chkconfig.

>3) The ingesting of surface observations from our
>local source is important for operational use, in the
>case the internet or your gateway is down. So, please
>keep it in your mind. In the mean time, i'll also
>trying to use your decoders.

The easiest way that new data is decoded is to inject them into the LDM
queue specifying their data feed type and let the GEMPAK decoders handle
them in the exact same way as the data being fed to the LDM from an
upstream node.  I believe that you can also run the decoder on files of
data also, but I had not checked with Chiz (Steve Chiswell our GEMPAK
guru) to make sure I understood the procedure.  I will forward your
inquiries about decoding the surface obs and model data this morning.

>4) I am surprised that there is no symbol for cloud
>types in the surface observation plots. It seems like
>US forecasters don't need to see that information?

I am suprised by this.  GEMPAK is pretty complete, so I had assumed
that it would have the appropriate cloud type symbols.  I will forward
this to Chis as well.  He can comment authoritatively.

>Thank you as always.

I'm glad to help when and where I can.

>Have a nice day,

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.