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 Justin, First, we should have moved this inquiry to support-idd area in our inquiry tracking system since it really is more of a how can I configure my LDM to process data the way that I want instead of a I am having problems with my LDM installation. Admittedly, this is a minor thing for you, the end-user; it is more for us so that someone other than Steve would be responsible for answering the question. re: reply to Steve in support-ldm > I had assumed unidata made or amended the script since I saw Tom Y. > reference the script and mention about questions regarding it > > http://www.unidata.ucar.edu/support/help/MailArchives/ldm/msg06360.html > https://github.com/Unidata/TdsConfig/blob/master/idd/pqacts/util/hhmmssRadarII.pl The 'hhmmssRadarII.pl' script was developed for use with our THREDDS Data Server (TDS) package. It is generally useful for others who want to reassemble the NEXRAD Level II pieces back into a single volume scan, but it was not engineered/documented fully enough to make its alteration as easy as it could be. By the way, the challenge in reassembling Level II volume scans from the pieces that are distributed by the NWS is that there is no guarantee that the pieces of a volume scan will be received in order coupled with there being a indication of which is the first piece and which is the last piece of the full volume scan. Way back before the NWS adopted redundant top level sources for the the NEXRAD2 feeds, one could be reasonably confident that the pieces would be received in order. This meant that one could create two LDM pattern-action file entries that would effectively reassemble the pieces in order: the first starts a new file when the first piece was received and concatenates all of the rest of the pieces into a single output file, and the second was, in effect, used as a notification that all of the pieces had been received. Because one can not be sure that the pieces are all received in order now, the simple approach is no longer robust enough to use. re: > I took a look at the line you mentioned. It looks like it references > where the data is kept initially for the script to run and process > data from the tmp dir (maybe I am mistaken?). I believe that the procedure creates a temporary directory when a new volume scan is started; writes all of the pieces as files in that temporary directory; and then kicks off the hhmmssRadarII.pl script which will then attempt to determine if all of the pieces for the volume scan has been received, and, if they have, it will reassemble the pieces into a single file and move it to the target directory, and they have not all been received, it will sleep for a certain amount of time and then recheck to see if everything has been received. I must say that this is the way that the procedure worked originally; I have no idea if the logic was changed since. re: > I was looking for the final product created to be moved to a different > directory. Again, maybe I am just misunderstanding it. The way the original procedure worked, the reassembly of pieces into a full volume scan was done in the temporary directory, and then the completed scan was moved to the target directory. There may be assumptions about what these directories are -- in the original implementation the temporary directory was a subdirectory of the target directory. Whether or not this is still the case is unknown to me. Since the developer of this script has since retired, we would have to read and "grok" the logic implemented in the script. Please let us know if you need us to do this. re: > Thank you for your time. No worries. 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: CDE-681099 Department: Support LDM Priority: Normal Status: Closed