A bias in Zdr of -.08 dB was found through analysis of vertical
pointing data. An adjust of +.08 dB has been added to all Zdr in the
final data set.
Details of this work will be prepared.
Corrupted Data Recording
This is a significant problem that was noted in the field, but the
cause could not be determined until the post-processing phase.
Extensive post-processing from multiple data sources can eliminate
most of the data problems, but there is still some net data loss
(total loss is estimated at less than 1%).
The PIRAQ Radar Signal Processor had trouble making a transition
between the usual 0.0° and 0.5° SUR scans. The processor
would require a small amount of time to re-initiate the processor
during the transition, due to changes in scan parameters
(particularly, the number of samples per beam). The problem manifests
itself as several (three to five) bad beams at the start of the
0.5° SUR scan. The collection of beams often has a banded, or
"barber pole" structure; frequency of occurance is about one out of
every three 0.5° SUR scans. The problem extends through the
active range of the clutter filter (out to 120 km).
A scan control configuration error caused problems with the standard
surveillance scanning on 4/5 June. SUR scans during this time are
partial scans, only, before the antenna "notches up" to the next
elevation. Time period affected is about 22:40 UTC 4-Jun thru 14:43
5-Jun. There is no post-processing method to correct for this
Incomplete RHI Scans, 15/16 June (and possibly other days)
The last RHI in a sequence of RHIs (a scan volume) was often
prematurely terminated on 15/16 June. This likely was caused by an
attempt to maintain precise schedule for conducting 0° SUR scans
for refractive index. This behavior is mentioned to avoid confusing
the data drop-out with the Corrupted Data
Recording problem. The nature of the incomplete RHI scans was
verified through review of the preserved real-time data stream.
There are artifacts in the data that may be caused by natural or
man-made phenomenon, or by very occasional problems with the radar
itself. These should not be confused with systematic problems in the
SOLO display rendering artifact
There are additional features in the data that are there by design.
Bad scanning, 15/16 June
On 15/16 June, poor scan parameters were programmed into the scan
controller. Many volumes were scanned at a rate of 64 samples per
beam (not good for dual polarimetric parameters, and really pushing
the tape drives and processor). As part of the problem, many 0.0°
refractive index scans were not able to complete.
A more precise time bracket for this problem needs to be defined.
DBZ vs DZ; VR vs VE
Not truly a problem, but a quirk.
In the realtime IHOP sweep data files there were fields called DBZ and
VR; in the post-processed data, these same fields are labelled DZ and
VE. There's a difference in the PIRAQ-to-DORADE real-time vs
post-processing translator code that seems to do this. A flag that
can be set to name the fields the same way, but this has not routinely
been used to produce a final project data set.
Tape Writing Failure, 14-Jun-2002, 18:27 to 22:33
The tape writing process on the second Radar Data Acquisition system
failed. This, combined with the tape cache corruption, resulted in
scans for this time being very choppy. Consideration should be given
to using the realtime data stream for this time period.
--- Bob Rilling ---
/ NCAR Atmospheric Technology Division
Created: Mon Oct 28 16:17:22 MST 2002