This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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