[IDD #YCI-227804]: Multiple Matches?

Hi Ben,

re:
> Thanks for your help.

No worries.

> I tried your suggestions, and everything looked
> fine.  After receiving the assurance that you couldn't see any problems
> up front I decided I'd look a little deeper.  And it appears that we ARE
> getting everything after all (or at least I'm not missing KLGU like I
> thought).

Very good.

> The problem was that it is going to a different file than I
> expected: KWBC.metars.  So my new question is: Is this expected?

Yes, because the station name included in the product metadata is
the issuing station, and that is not necessarily the reporting
station (KWBC can issues bulletins for multiple reporting stations).

> And if
> so, can you explain to me why I'm not getting KLGU in a file named
> KLGU.metars by itself?

See above.

> (I'm happy to keep everything as it is now that I
> feel like I'm storing everything I want to, I just would like to
> understand what is going on a little better).

The problem is one of understanding that the headers of the bulletins
in the datastream are not necessarily the same as the stations in the
bulletins.  You can convince yourself of this by watching the output
of the LDM 'notifyme' utility for products matching your pattern:

<as 'ldm'>
notifyme -vxl- -f "IDS|DDPLUS" -p ^SAUS

You will see in your listing LOTS of reports with the KWBC id.  Since you are
fileing those reports, you can look through them and see that the stations
contained in them _never_ match KWBC since KWBC is the issuing station/center,
not the station ID.

> For your convenience I'll
> repaste the pqact entry in question:
> > # Archive all records to a single file per station for backup purposes
> >
> > IDS|DDPLUS    ^SAUS.. (....)
> >
> > FILE     -close data/awos/\1.metar

Take a look through your ~ldm/data/awos/KWBC.metar file to see what I am
driving ato above.

> Thank you!

No worries.

> P.S.  Just in case it would help with my current question, here are the
> answers to your previous questions:

> - how large is your LDM product queue
> LARGE.  It appears about 400 MB

In this era of LOTS of data, 400 MB is considered to be a _small_ queue,
not large :-)

> - how much data are you ingesting
> The metars data in question, a few watches, and UNIWISC imagery

OK, so a 400 MB queue is plenty big enough for what you are ingesting.

> - how many 'pqact' processes do you have running trying to process your Data
> Only one pqact process

OK.

> - how many actions do you have in your pqact.conf file(s)
> 10

A very small number, indeed.

> - what is the age of the oldest product in your LDM queue
> Pqmon reports 7410 (~2 hours)

Looks good.

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