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 Brad, re: > Can anyone shed some light on the readnoaaport log format entries. For > example, below the same product normally comes in with "cat 1" however on > the 1514 issuance it came in with "cat 101" and the downstream LDM did not > request the product from the queue and thus did not store it. I am a bit suspicious about the comment "the downstream LDM did not request the product from the queue and thus did not store it". The LDM REQUEST lines use regular expressions that match on the LDM/IDD Product IDs. If the REQUEST pattern used by the downstream matched the first product, it should have also matched the second product since, as far as I can tell from the listing you sent, the Product IDs are identical. Questions: - is your view that the downstream LDM did not request the product from the upstream based on not seeing the product processed on the downstream? - did you use the LDM utility 'pqcat' to list products in the LDM queue on the receiving machine and prove that the product was not received (NB: this would have to have been done before the product got automatically scoured out of the LDM queue)? re: > Wasn't sure > (1) what the cat field is, (2) how it is determined, and (3) what might > cause the difference between the two be it an error in the product etc... The 'cat'egory field is taken from the WMO ID of the product (for non-GRIB products) or from a table for GRIB products. It seems that two different products had the same WMO ID (FXUS10s are not GRIB messages are they?), and so 'readnoaaport' created the same LDM/IDD Product ID. Since the product sizes are different (and so, their MD5 signatures would be different) and the times between LDM product queue insertion is large (so, presumably, the old product would no longer be in the downstream LDM's product queue), the product should have been sent to the requesting LDM. Whether or not it is seen in the downstream's file system depends on what the action was that did the processing (for instance, the product created by the receipt of the new product could have overwritten the one created by the previous on, etc.). re: > CORRECT FORMAT: > > Jan 20 05:28:10 cpsbn1-hpcn readnoaaport[29052] NOTE: FXUS10 KWNH 200528 > /pPMDHMD inserted [*cat 1* type 4 ccb 2/0 seq 68910095 size 4791] > > INCORRECT FORMAT (only happened once thus far): > > Jan 20 15:14:50 cpsbn1-hpcn readnoaaport[29052] NOTE: FXUS10 KWNH 201514 > /pPMDHMD inserted [*cat 101* type 4 ccb 2/0 seq 69705248 size 2236] Please let me know if the above does not make sense. 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: GOE-694008 Department: Support IDD Priority: Normal Status: Closed