[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #CDE-681099]: Pqact.threddsradar

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

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.

> 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.

> 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.

> Thank you for your time.

No worries.


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

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.