(Collaborative Radar Acquisition Field Test)

 

 

 

 

 

 

Report on work of Harry Edmond, Russ Rew, Linda Miller, Keith Brewster, Tom Condo and Gene Bassett and meetings including above and other people (as mentioned within) on 10-11 Sept 1998.

 

 

We installed the Unidata LDM 5.0.6 software and Edmon's 88D LDM software on the CAPS SPARC-10 connected to the KTLX RIDDS broadcast network at NSSL (North Campus).

The radar data was initially set up to flow to two machines in the Energy Center. After a brief test of that, it has been allowed to run nearly continuously to one OU SoM machine (satpc) in the Energy Center.

The data flow seems to be doing fine. There were some outages over the weekend; we suspect they may be related to power problems and/or the RIDDS data feed outages. Behavior has been reliable since Monday. Also we set-up the LDM to distribute the files from satpc to U of Washington, and the KATX (Seattle) radar data from Washington to Norman. Both of these data flows seem to be reliable. Harry Edmon checked a file from Norman converted to a NIDS-like image, and reports that it matches a NIDS image obtained over the internet from a NIDS provider. Legal disclaimer: we are just exchanging files, not making any material use of them.

The NSSL test radar can provide an additional datastream that could be used for testing the processing of multiple radars by the same LDM file generating computer. This has not been tested as of today.

Short term needs

1) define product

name (now generic "EXP")

headers

compression

CAPS has its own compression software. Although some effort was made to optimize it, there is not likely a large difference in the compression rate compared to that within Edmon's software. One difference between the two schemes is in the philosphy of downstream processing. CAPS uses the "on-the-fly" decompression of the file with a library that emulates the subroutines in NSSL's "a2io" library. U of Wash technique uncompresses the file and then uses software designed to read archive-II volume files applied to the uncompressed files. Another issue is whether the files need to be kept as volumes; arguments could be made for storing by tilt. This gets away from the philosphy of some current software, but offers some additional flexibility. An idea of allowing for random access by tilt within a file was also brought up.

It should be mentioned that the content of the files doesn't matter to the LDM software.

We agreed that it would be a good idea to survey the community and find out what packages people are using (such as Zebra, IRAS, and WATADS, aka WDSS, RADS), and to assess how the I/O for each might be affected by a compressed file format. Linda Miller seemed interested in spearheading this.

Harry Edmon is now working on documentation for his file format.

We may also need source code for some NSSL libraries we linked to(libnssl.a and libnexrad.a). Likely available from NSSL.

CAPS does not have documentation yet on the file structure but does have results of compression testing on two cases having dense radar echo coverage (with the aim of defining the "worst-case scenario" of data compression).

2) Networking issues

Tim Crum explained issues making placement of an LDM distributing computer in the FO's nearly impossible. NWS doesn't want other to be responsible for other people's computers within their walls, and space may be an issue. This means the network connection will be dedicated to some site outside the office using UDP broadcast as is currently used in the broadcast from KTLX RIDDS to the NSSL Sun network. That line will have to be able to handle the full data volume (up to 16 Mbyte/5 min, 426 kbit/s). James Deaton, representing OneNet for Chris Petroff indicated that this can be accomplished within OneNet. There are some unaddressed issues about the physical location of these machines (could be in Norman, OKC, or at a remote site somewhat close to the originating radar). It is also not know if the software and typical hardware can handle more than one radar at a time. If so, then a couple of machines in a relatively central location might be used to process the 4-7 radars that are expected from the Okla/N Tex/S KS/W Ark area.

 

We need further discussion with Chris Petroff on this and also with Mark Benner on spec'ing the hardware (CSU/DSU, multiple inputs to one PC, etc). Can OneNet house the boxes, provide emergency access, etc? Or better for them to be in Norman in CAPS space?

I have in my notes a concern about each RIDDS having the same IP address and whether that may be a problem for multiple radar processing. A question for Mark Benner and Chris Petroff, perhaps.

That about covers what I have in my notes/memory. Please correct any misinterpretations, falsehoods, omissions, etc.

 

-Keith Brewster

 

Click to return to CRAFT home page