[LDM #GLG-935498]: CONDUIT GFS data

Hi Hsie,

We have some bad news for you that we noticed when trying to switch from
LDM-6.11.7 to a newly built 6.12.14:

Evidently, all of the decoding actions in your GEMPAK pattern-action
file, ~ldm/etc/pqact.conf_gempak, and some of the decoding actions
in your McIDAS pattern action files, ~ldm/etc/pqact.conf_mcidasA and
~ldm/etc/pqact.conf_mcidasB, have not been working probably since
the upgrade of your LDM from v6.10.1 to 6.11.x.  As far as I can tell,
this switch was likely to have been made back on April 5, 2013.

We determined this by looking more carefully at the error messages
in the LDM log file(s), ~ldm/logs/ldmd.log*.  A characteristic log
message that indicates that a GEMPAK decoder is not being run looks
like:

Jun 10 19:20:44 rainbow pqact[12623] ERROR: [filel.c:305] Deleting failed PIPE 
entry: pid=12670, cmd="decoders/bin/dcuair -b 24 -m 16 -d logs/dcuair.log -e 
GEMTBL=/home/gempak/NAWIPS/gempak/tables -s snstns.tbl 
data/gempak/upperair/YYYYMMDD_upa.gem" 
Jun 10 19:20:44 rainbow pqact[12623] ERROR: pipe_prodput: trying again:      
111 20160610192044.984 IDS|DDPLUS 184738101  UFUS45 KPSR 101920 /pABV1Y9 
Jun 10 19:20:44 rainbow pqact[12672] ERROR: No such file or directory 
Jun 10 19:20:44 rainbow pqact[12672] ERROR: [filel.c:1423] Couldn't execute 
decoder "decoders/bin/dcuair" 
Jun 10 19:20:44 rainbow pqact[12672] NOTE: Exiting 

Note that this log message was generated by LDM-6.11.7.

What is the problem?

The problem is that the majority of the actions in the GEMPAK pattern-action
file, and lots of the actions in the McIDAS pattern-action files implicitly
assume that the current working directory when the action is run is
the HOME directory of the LDM.  Starting with LDM v6.11.x, the current
working directory for 'pqact' (the LDM utility that executes the pattern-action
file actions) is defined in the LDM registry, ~ldm/etc/registry.xml, by
the tag <datadir-path></datadir-path>.  The current setting for this tag
is /home/ldm/data.  Let's examine one (the first one, actually) of the many
actions in the GEMPAK pattern-action file, ~ldm/etc/pqact.conf_gempak:

# NAM #211 80km grid CONUS
HDS     (/mNAM|/mNMM).*#211
        PIPE    decoders/bin/dcgrib2 -d logs/dcgrib2_NAM211.log
                -e GEMTBL=/home/gempak/NAWIPS/gempak/tables 

The reference to the GEMPAK decoder to be executed is a relative path:

decoders/bin/dcgrib2

If the current working directory for 'pqact' was /home/ldm, then this
relative path reference would be OK.  However, since the current working
directory for 'pqact' is /home/ldm/data, then the decoder will not be
found.  The exact same comment can be made for the log file to be
written:

-d logs/dcgrib2_NAM211.log

This says to write the log messages for this action in 
/home/ldm/data/logs/dcgrib2_NAM211.log.
The problem is that there is no /home/ldm/data/logs directory.

What can be done?

We could change the <datadir-path></datadir-path> tag(s) in the LDM registry
from /home/ldm/data to /home/ldm and then restart the LDM, and then the
GEMPAK and McIDAS decoded data files will once again be created and written.
The potentially huge downside to this change would be that the processing
load on rainbow would undoubtedly get much, much higher, and this might
well negatively impact your ability to process (FILE) the CONDUIT data
that you have been looking at recently.

Aside:  The other thing we noticed is that the OS on rainbow is now very,
very old: RedHat Enterprise 5.11.  How upgrading to a current release of RHEL
would affect rainbow's operation we can not say.

What to do?

So, the question to you is if you want us to modify the LDM setup on rainbow
to alter the configuration so that GEMPAK and McIDAS decoding would once
again work ** realizing that the increased CPU use might actually negatively
affect your ability to FILE the CONDUIT data **?

As I write this, rainbow is running LDM-6.11.7...

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: GLG-935498
Department: Support IDD
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly 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.