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 Gerry, re: > Quick note: I changed the ldmd.conf request that triggers this to get > CONDUIT and a product including pgrb2f. We're also pretty specifically > requesting RUC2. This gets the 2 files in for processing we need. I'm > still decomposing the individual gribs, but they should also be > available on the dc-ldm2 ldmd logs... I am not sure if this means that I should be looking at something... A quick comment from me: I notice that you have a couple 'pqact' exec actions in the ~ldm/etc/ldmd.conf file on dc-ldm2 that specify the use of the same pattern-action file for different feeds. I recommend that you separate actions pertinent to a specific feed/set of feeds into its own pattern action file. For example, I see the following: exec "pqact -f IDS|DDPLUS etc/pqact.conf" exec "pqact -f FSL2|FSL3|FSL4 etc/pqact.conf" These lines will cause two invocations of 'pqact' and _both_ will be forced to consider actions not specific to the feeds they are told to act on: - the first will have to compare each product from the IDS|DDPLUS feed against every FSL2|FSL3|FSL4 action in ~ldm/etc/pqact.conf - the second will have to compare every product from the FSL2|FSL3|FSL4 feeds against every IDS|DDPLUS action in ~ldm/etc/pqact.con For efficiency sake, I suggest creating a separate pattern-action file with actions for just the IDS|DDPLUS and a second one with actions just for the FSL2|FSL3|FSL4 feeds. The same comment applies to the two currently active 'pqact' exec lines for CONDUIT: exec "pqact -f CONDUIT -p ruc2......pgrb20f etc/pqact.conduit.conf" exec "pqact -vf CONDUIT -p gfs etc/pqact.conduit.conf" Another question comes to mind from the observation that you are requesting CONDUIT with pattern 'gfs' from three different machines: - are you sure that each of the machines is ingesting the same set of CONDUIT data? If they are not, then you could miss products when your rpc.ldmd connection changes from secondary to primary or visa versa. 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: BOA-542231 Department: Support LDM Priority: Normal Status: Open