20040615: soliciting second-tier-IDD NEXRAD Level II relay sites (cont.)

>From: Robert Leche <address@hidden>
>Organization: LSU/SRCC
>Keywords: 200406152001.i5FK1TtK019041 NEXRAD Level II

Hi Bob,

>The host we are planning to use in processing the Level II NEXRAD data is:
>
>  pavan.srcc.lsu.edu (130.39.191.9)

OK, thanks.

>1) Pavan will need access to up stream feeders.

I will pass along this information to the LDM administrator at the ERC
(the site that will feed LSU) as soon as they are setup for relay
(should be soon).

>2) Would it make sense to move the existing IDD downstream feeders to 
>Pavan from Seistan.srcc.lsu.edu?

It is not necessary to have a single machine at a site relaying
all of the data, but it is OK to do so.  Turning pavan into the
single relay machine would necessitate that all downstreams feeding
from seistan change their request line(s) to point at pavan and
then stop and restart their LDM.

>We could leave Seistan online as a 
>fail-over backup site. Once Pavan is operational, I will turn decoding 
>off on Seistan.

I am curious about why you are rehosting the decoding on pavan.  Is
the thinking to move the decoding/filing to pavan so that you can keep
the Level II data on its RAID?

It might make more sense to move all data relay to pavan and feed
seistan and continue to have it do the decoding that you need/want.

>3) I am in the process of installing the LDM decoder along with the 
>associated programs on Pavan. I need to know if you have need of any 
>special programs to add to the LDM mix?

Kevin Robbin's email suggested that you were going to save Level II
data on the loaner's RAID (which I assume is pavan).  If this is true,
then you will want to either adopt the pqact.conf entries needed to
file the data, or run the data through a GEMPAK decoder that
uncompresses it.  Please note that the current release of GEMPAK does
not require that the data be uncompressed in order to be used.
Previous versions did, however.

As far as any other programs go, I can tell you that we have started
the process of putting together a new LDM release that has a fix in a
subroutine used by both 'pqbinstats' and 'rtstats'.  The fix is needed
to correctly report the volume of data being received in the CRAFT
stream (because of the large number of different inject sites used for
the data, one per radar).  The fix has nothing to do with the LDM's
ability to receive and relay any datastream -- that is working
correctly.

>And along with the IDD programs, what about configuration?

I can provide you with pqact.conf actions that will FILE the Level II
data.

>Left to my own devices, I will test the system 
>with the configuration that is generated by the Gempak installer.

The current release of GEMPAK can create a file of the actions needed
to FILE the Level II data, so if you are going to run GEMPAK decoders,
you should make sure to use the latest distribution.

>If other configurations are needed, let me know.

I developed a couple of Tcl scripts for data scouring in a test to see
if they would be more efficient than the Cshell scripts that most folks
used to 'prune' directory trees.  These scripts are running nicely on a
machine at Texas A&M and one destined for Barbados here in my office.
I can make these available if you like.

Questions:

- What is your intention for saving the Level II data?  If you want to
  keep several days of data on disk, you should make sure that you have
  at least 25 GB per day of data you want to keep.  Also note that
  this number will grow as the radars are upgraded to include more tilts,
  twice the number of radials, and the range gates are halved.

- what OS will pavan be running

Cheers

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.