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 Steve, We have been having email exchanges with folks at the WOC about the best way to include new products into the CONDUIT feed (CONDUIT originates on machines at the WOC). Here is the body of an email that Patrick O'Reilley sent us yesterday about how they are thinking of adding the products: Here's a rough dataflow diagram of the path of these data: TOC system socket => WOC system socket => WOC socket LDM => WOC CONDUIT LDM => Unidata and others where the "socket" is a client/server software. When the WOC socket software inserts it into the "socket" LDM, there is a default feedtype it is assigned. There's not any flexibility to assign different feed types. So since in the future, there may be products coming from the TOC to the WOC that aren't destined for CONDUIT via this path, I guess it's a good idea to assign it to EXP, and make that permanent. With this in mind, is there an easy or standard way to change the feedtype between LDMs? After the test, the products will be coming into the WOC CONDUIT LDM as EXP and we need them assigned to the CONDUIT feed type. We can think of a couple indirect ways but thought there may be a more straightforward method. Thanks! Patrick In recap, the issue is that they want to send the new products to the CONDUIT injection machines using the LDM EXP feed type, and then have the new products re-inserted into the CONDUIT injection machines LDM queues in the CONDUIT feedtype. I commented to Patrick that it might be possible to re-insert the same product into a queue where the original is still resident by assigning an MD5 signature to the re-inserted product (assign one, not let pqinsert calculate one). Questions: - would this circumvent the duplicate product rejection? I think that it would, but I wanted to make sure that there were not 'gotchas' - if the answer to the first question is yes, it seems to me that the best thing to do is to assign the artificial MD5 signature to the product in the EXP feed and let pqinsert calculate the signature when the product is re-inserted as a CONDUIT product Any comments would be most useful... 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 ****************************************************************************