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

[IDD #VRK-635010]: idd data

Hi Marck,

Below is my update on what I changed when I logged into your LDM
machine on Saturday morning:

<as 'ldm'>
-- I modified entries in ~ldm/etc/registry.xml to set the current
   working directory (as set by a couple of <datadir-path> tags)
   to be the HOME directory of 'ldm', /home/ldm

<as 'gempak'>
-- I changed the read/write/execute permissions AND ownership on
   a variety of directories in the GEMPAK 6.10 installation

   I did this so that 'ldm' could read and execute from the
   directories changed

<as 'ldm'>
-- I copied the GEMPAK 6.10 decoders (files named dc*) to the
   /home/ldm/decoders directory

   When I ran 'which dcmetr', I found that all GEMPAK executables
   had been copied to the ~ldm/bin directory.  This is something that
   one should _never_ do since LDM installations use a runtime link
   that points at the bin directory for the LDM version installed.
   Copying non-LDM executables to an LDM bin instance might work
   if one keeps running the same version of the LDM, but it will
   break once the LDM is upgraded (if one follows the instructions
   for installing a new version of the LDM.

   I deleted everything in the ~ldm/bin (which is actually ~ldm/runtime/bin
   which, in turn, is currently ~ldm/ldm-6.11.6/bin) and reran the
   LDM installation.

<as 'ldm'>

-- I thought that things should be good to go after doing the above, but
   I found that all pattern-action file entries being used for GEMPAK
   processing had been changed, so nothing would work

   I understand that the pattern-action file actions were likely changed
   in an attempt to get things working.   A much better approach, however,
   is to figure out why things were not working as things stood, and
   correct that problem.  I did this through the ~ldm/etc/registry.xml
   modifications that I listed above.

After rolling back out of the pattern-action file editing changes, I
restarted the LDM, and things started working as designed.  I then had
to drop the investigation to work on my house :-)

The next thing I did was setup GEMPAK log scouring in 'ldm's cron.
This was done by:

<as 'ldm'>
-- copy ~gempak/NAWIPS/bin/dcrotatelog.csh to ~ldm/util and modify
   it to correctly source ~gempak/NAWIPS/Gemenviron so that GEMPAK
   environment variables would get properly set

-- correct the cron entry for running the LDM scour utility

After waiting for what seemed like enough time, I did a gross check
to see if decoded output GEMPAK files were getting created:

<as 'ldm'>
ls ~/data/gempak/surface   etc.

I saw that point data was being decoded, but I did not see any decoded
model output:

ls ~/data/gempak/model/*

In order to make sure that the setup was correct, I decided to turn on
ingest of the HDS datastream by adding an appropriate REQUEST line
in the ~ldm/etc/ldmd.conf file and restarting the LDM.  Both last night
and this morning I verified that the addition of the HDS data was not
having a detrimental impact on the latency for the other feeds being
REQUESTed, IDS|DDPLUS, NIMAGE and NGRID.  In fact, the latencies for
all feeds looks very good (meaning near zero)!

So, the next thing to be reviewed and decided is if the models being
ingested and decoded are sufficient for your processing needs.  If
they are not, the only other option would be to ingest some of the
fields in the HIGH volume CONDUIT feed.  If this is done, removing
REQUEST for some/all of HDS might be necessary since the bandwidth
of your connection will, at some point, be totally used by data
flowing in the various IDD connections.

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: VRK-635010
Department: Support IDD
Priority: Normal
Status: Closed