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 Gini, > The NWS TOC trying to gauge impact of upgrade of MAX Internet 2 LDM > Servers. > We are currently considering upgrade of MAX from ldm 6.1.0 to ldm 6.4.4 > Although the current LDM version is 6.6.4 -- we have experience with > upgrade to 6.4.4 and > proved ability to feed to NCEP from TOC LDM Internet 2. > Not sure of advantages or disadvantage of using more recent > versions--please advise The major features that were added in version 6.5 are: The LDM configuration-file now supports "include" statements. The "pqact" program now identifies the last, successfully-processed data-product in a persistent file. This allows "pqact" processes in a subsequent LDM session to start processing where the previous ones left-off. Under sufficient product-latency or bad-clock conditions, a upstream LDM would not send data-products that it should upon reconnection by a downstream LDM. This has been fixed. Be advised, however, that LDM versions 6.5.0 through 6.6.4 have an operating-system dependent bug in "pqact" that can cause the wrong time to be assigned to a textual data-product with a WMO header (the NEXRAD Level II products are not in this category) near month transitions. This will be fixed in version 6.6.5, which I'm about to release. The major feature that was added to version 6.6 is: Downstream LDM processes now identify the last, successfully-received data-product in a persistent file. This allows a downstream LDM process in a subsequent LDM session to start where the previous process left off. More information on these features and on bug fixes can be found in the file CHANGE_LOG, which is in the top-level source-directory of every LDM distribution. > -- but > but I understand SR is going to LDM 6.4* . The MAX systems are > maintained remotely and > without anyone on site to hit the reset button if needed and therefore > we would like to choose the > safest path with minimal disruption. > > We would appreciate Unidata advice on proposed upgrade -- see details > attached. Due to the product-time bug in "pqact", I wouldn't upgrade to version 6.5 -- unless you don't do any "pqact" processing of textual WMO bulletins. It should be safe to upgrade to version 6.6.5 -- when I release it -- but, I understand that upgrading to it might be a hard sell because it would be the latest release. If you decide to upgrade to version 6.4.4, then I recommend upgrading to version 6.4.6, instead, because of the bug fixes. > Do those sites receiving the filtered data set need to upgrade or > configure ldmd.conf to maintain the filter? I take it that the new products will be sent from Southern Region to the Max and should then be relayed to a few, selected downstream sites -- and only those sites -- and that the feedtype of the new products is also NEXRAD2. In that case then, yes, the LDM on the Max will have to be upgraded to 6.4, at least, in order to enable "upstream filtering" and prevent the new products from being relayed to the wrong downstream sites (which, undoubtably, request them using the feedtype/pattern pair "NEXRAD2/.*". In order to devise new LDM configuration-file entries that will ensure proper relaying, I need to know the pattern for the product-identifier for the new products and how it differs from the current product- identifier. Would you please send that to me. I'm looking for something in the product-identifier that can be easily matched in order to differentiate between the two classes of NEXRAD2 products. This difference is key to upstream filtering as well as proper processing of the new products via "pqact". > Can you advise what might happen if those sites that are planned for > exclusion from the new data set do receive it? If the new data-products have a feedtype and a product-identifier that matches an entry in a "pqact"s configuration-file, then the "pqact" process will attempt to process the product. I'm afraid I don't know how successful that will be because I don't know the processing details (e.g., can the current NEXRAD2 decoder handle the new format?). > Thanks for your help > Gini Galvin > System Administrator > NWS/OCIO/TOC/TSB > 301 713 0882 x 176 > 240 393 3348 c Regards, Steve Emmerson Ticket Details =================== Ticket ID: RES-637932 Department: Support LDM Priority: Normal Status: On Hold