[IDD #GXK-220586]: WMO Data/NLDN Access

Hi Warren,

re:
> Thank you for the reply, I did some more tracing earlier and discovered that 
> there was
> an issue in the pqact with the PIPE decoders/ portion of the respective data 
> filings,
> which explained why data was received but not filed. I did manage to get 
> warnings filed
> by assuming that the command could not be executed with decoders/ since no 
> path exists
> that contains the program it is seeking, thus I removed the prefix from all 
> of the
> decoded products and it could execute the command since the 
> gemenviron.profile is linked
> to our ldm user as well as gempak users.

OK.  The explanation for the need to remove the relative path location to the 
decoders
long used by GEMPAK users (e.g., decoders/dcnldn, etc.) is:

- in recent versions of the LDM, the ~ldm/etc/registry.xml foile defines
  data paths for pqact and pqsurf entries

  These definitions basically define the 'current working directory' for
  these applications when run as part of the LDM (the typical/normal
  situation).  Because of this, the relative reference to decoders/dcnldn
  is interpreted as ~ldm/var/data/decoders/dcnldn, and that directory
  does not typically exist nor is it intended to exist.

A solution/fix for this is to simply redefine the <datadir-path> entries
in the ~ldm/etc/registry.xml file to be the HOME directory of the user
'ldm'.  These are the entries that I use:

  <pqact>
    <config-path>/home/ldm/etc/pqact.conf</config-path>
    <datadir-path>/home/ldm</datadir-path>
  </pqact>
  <pqsurf>
    <config-path>/home/ldm/etc/pqsurf.conf</config-path>
    <datadir-path>/home/ldm</datadir-path>
  </pqsurf>

The net effect of this is that the current working directory for actions
run by 'pqact' is $HOME.  Since a GEMPAK installation has one copy the
GEMPAK decoders to the ~ldm/decoders directory, the fully qualified
path used in the stock GEMPAK pattern-action file actions is
~ldm/decoders/dcnldn, etc.

re:
> The curious thing is that some things are not plotting in GEMPAK utilities. 
> For
> instance, setting the warnings variable to last in GPMAP doesn't yield any 
> results even
> with new warnings supposedly coming in, and neither does explicitly pointing 
> to the
> polygon folder (this could be user error on my part). I'm calling out warning 
> products
> but some other decoded products also seem to cause trouble, though all make 
> it through
> filing as .GEM files. I assume the issue has to do with the decoders and the 
> pqact file,
> but I suppose this might also be more of a GEMPAK question than an IDD 
> question. (Things
> definitely working are NEXRAD3,NIMAGE,NLDN)

This really is a GEMPAK question.  It would be good to open a new GEMPAK ticket
by sending your question(s) to address@hidden.  I can create this
ticket for you if you like; please let me know.

re:
> We will go ahead and add/replace NGRID and NEXRAD3 to our REQUEST line, if 
> anything to
> sort out issues like these.

OK.  The other thing that you should pay attention to is the latencies 
experienced
in receiving products.  If they are "high" (a relative meaning to be sure), then
you will likely want to split your REQUESTs into several mutually-exclusive 
ones.
Here is an example to illustrate splitting feed REQUESTs:

change:

REQUEST IDS|DDPLUS|NEXRAD2|HDS|NIMAGE ".*" idd.meteo.psu.edu
REQUEST IDS|DDPLUS|NEXRAD2|HDS|NIMAGE ".*" idd.tamu.edu

to:

REQUEST IDS|DDPLUS|HDS ".*" idd.meteo.psu.edu
REQUEST NEXRAD3|NIMAGE ".*" idd.meteo.psu.edu
REQUEST NGRID ".*" idd.meteo.psu.edu

REQUEST IDS|DDPLUS|HDS ".*" idd.tamu.edu
REQUEST NEXRAD3|NIMAGE ".*" idd.tamu.edu
REQUEST NGRID ".*" idd.tamu.edu

The idea behind splitting feed REQUESTs is to balance the number of
products that flow through each connection.  Splitting a feed
REQUEST into mutually-exclusive subsets becomes very important
when the volume/number of products flowing becomes "large".  The
only way to judge if you need to split one or more feed REQUESTs
is by examining the latencies you are experiencing.  A quick check
of the latencies that your machine is reporting indicates that you
have not been running long enough for enough statistics to have been
gathered to make an informed decision:

Unidata HomePage
http://www.unidata.ucar.edu

  Data -> IDD Operational Status
  http://rtstats.unidata.ucar.edu/rtstats/

    Statistics by Host
    http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex

      pat-mcen_112_21.uncc.edu [6.11.7]
      
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?pat-mcen_112_21.uncc.edu

The 'latency' link for each feed type is what needs to be examined and
evaluated.

re:
> We contacted UAlbany regarding NLDN and they have added us to their .conf 
> ALLOW entries.

Excellent!

re:
> I've never been able to differentiate between NLDN and NAPLN, both appear to 
> be fairly
> equal, but then again this is obviously our first 'real-time' look at these.

They are completely different lightning networks, so the information contained 
in
each may be (slightly) different from the other.  I personally would use _both_
sets of lightning data and do my own comparisons.

re:
> As you can tell, we have managed to get our LDM/AWIPS system rolling along, 
> it's just
> coming down to working out the 'kinks'.

I am getting the feeling that when you say AWIPS you are really referring to
NAWIPS which is also know as GEMPAK.  AWIPS is completely different package
that is not available from Unidata.  AWIPS-II, on the other hand, is being
developed by NOAA/NCEP/Raytheon as a replacement for AWIPS and NAWIPS.  How
much of NAWIPS/GEMPAK it will eventually supplant is yet to be determined.

re:
> Thanks again,

No worries.

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