[LDM #LJY-425624]: NEXRAD Level II Feed

Hi Alan,

> I have two separate top tear feeds of the Level II data, one from the
> ERC co-located with NCDC in Asheville, NC and one from Maryland U that
> feeds a server at NGDC in Boulder, CO.  The two streams don't entirely
> match, which is a problem for an archive.
> 
> 
> In comparing the two, I find slight differences.  For example:
> 
> Volume Scan                                    NCDC                  NGDC
> KMTX20080528_223427.Z            857,923               852,897
> 
> KMTX20080529_115442.Z            963,695               989,259
> KMTX20080529_143454.Z            0                          255,315
> KMTX20080529_144329.Z            602,275               605,057
> KMTX20080529_144748.Z            607,697               615,711

The NEXRAD2 data-feed doesn't have *.Z files, so those files must have
been created somewhere from accumulated NEXRAD2 data-products.  Where
was this done?  May we please see the pqact(1) configuration-file
entries that were used to accumulate the data-products?  What can you
tell us about the decoder that's used?

> It is not always the case that NGDC is larger, just happens to be so in
> this case study.
> 
> NCDC archived the following 8 hour tarfiles:
> May 28 294 tar files:
> 265 tar files that were larger than what was received at NGDC
> 17 tar files were retrieved from NGDC because the tar file was larger
> 12 were exactly identical
> 
> May 29 271 tar files:
> 226 tar files that were larger than what was received at NGDC
> 27 tar files were retrieved from NGDC because the tar file was larger
> 18 were exactly identical
> 
> I have no real explanation for the differences and there could be
> several possibilities.  Would it be possible to trouble shoot this with
> someone at Unidata?  I am willing to share my code and methods hoping
> for improvements and willing to take all criticisms.

I suspect the most likely cause is the decoder responsible for
accumulating the NEXRAD2 data-products.  Because the data-products
for a single sweep don't necessarily arrive in temporal order,
it's possible for a simple pqact(1)-entry/decoder to prematurely
decide that a sweep is complete.
 
> Thanks,
> Alan.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: LJY-425624
Department: Support LDM
Priority: Normal
Status: On Hold