REGIONAL RADAR VOLUME DEVELOPMENT PLAN FOR FY97
Figure 1.The three WSR-88D radars (identified
by "*"s) for the '97 regional radar volume.
Range rings at 230km indicate the maximum range for
velocity data.
Prepared by William F. Roberts,
Quingfu Liang, and Steve Albers
NOAA Forecast Systems Laboratory
Boulder, Colorado
December, 1996
ACKNOWLEDGEMENTS
Several groups and individuals outside of the Forecast
Systems Laboratory have supported the development of the Regional Radar
Volume work to date. Dave Pace (FAA) carried out the WSR-88D wideband request
process and provided RIDDS maintenance funds for FY97. Tim Crum (NWS/OSF)
has provided important guidance and information on the request process
and the RIDDS implementation along with Mike Eilts and Kevin Kelleher from
NSSL. Bob Saffle (NWS/OSD) has provided additional funding and support
for this effort. Early data interface development was done in collaboration
with Keith Brewster at Uv. of Oklahoma and others. Finally, we thank the
Denver, Cheyenne, and Goodland forecast offices for allowing access to
the radars for this important development activity.
1. OVERVIEW
This plan addresses major components for developing and
implementing an initial Cartesian radar volume product comprised data from
three WSR-88D radars that scan over a small regional domain (see cover
figure). This product is referred to as the Regional Radar Volume (RRV).
RRV development will serve as an initial step for creating a CONUS B National
Radar Volume comprised of data from all NEXRAD radars within the conterminous
United States (CONUS).
The initial concept for this work was presented as part
of the Forecast System's Laboratory's Tri-annual Scientific and Technical
review in August, 1993. At that time Sandy MacDonald, FSL Director, proposed
creating a real-time national radar volume of reflectivity and velocity
data from the NEXRAD radar network. This product would be developed in
the laboratory along with other CONUS data sets for use by the National
Weather Service and others later this decade. While no specific requirements
yet exist for a
national radar volume, several uses are envisioned
for this product. They include integration into high-resolution models
who use asynoptic data (LAPS and MAPS, for example), displayable radar
mosaic products for AWIPS
1,
and for aircraft routing.
Following the tri-annual review, William F. (Woody) Roberts,
explored the feasibility of retrieving horizontal (u/v) winds from areas
scanned by multiple radars. This work indicated that overlapping scanning
areas in the network were sufficient to retrieve u/v winds over a large
percentage (~40%) of the CONUS area . Initial time/height u/v wind retrievals using archived 88D data
from Oklahoma compared well with profiler data collected nearby.
Coincident with the development activities discussed
above, the National Severe Storms Laboratory under direction from the NWS
Operational Support Facility (OSF) have developed Radar Interface and Data
Distribution System (RIDDS) which provides a wide-band interface to the
WSR-88D Radar Product Generator (RPG). This interface has been developed
in order to retrieve level 2 base data from selected radars to test and
refine NEXRAD algorithms and local area models. The Denver radar (KFTG)
currently has this interface. Radars at Pueblo, Co., Grand Junction, Co.
Goodland, KS., and Cheyenne, WY., among others, have also been designated
to receive them.
Original plans had included connections to twelve radars
and a regional domain stretching from southern Wyoming through northern
Texas. Due to several considerations, plans have been modified to for this
initial FY97 deployment. These considerations include budget constraints,
lack of RPG wide band ports at DOD radar sites (in Oklahoma), and RPG open
systems development work at NWS. Nonetheless, this small network should
provide many insights into developing a national radar volume. It is expected
that the FY97 RRV will benefit mesoscale modeling efforts, and provide
real-time displayable mosaiced radar products. Additional sites may be
added in the future.
The January/March 1997 time frame is the target for deployment to the Cheyenne
(KCYS) WY., and Goodland (KGLD), KS. sites. Connections to the Denver radar
(KFTG) were completed in FY96. Routine product generation should begin
about one month after the KCYS and KGLD installations depending on software
development schedules.
The following plan discusses the various components of
the RRV development and includes product requirements, software processing
components, and hardware/communications components, and resource estimates.
2. PRODUCT REQUIREMENTS
The following describes a set of requirements for RRV
products. The intent here is to include sufficient data resolution to satisfy
both model assimilation requirements and displayable radar product requirements
with consideration given to constraints for on-site processing and communications
band width.
2.1 RRV Fields
Four basic RRV data fields will initially be produced on a routine
basis. These fields are:
Radar reflectivity - one value per radar per grid point
Radial velocity - one de-aliased value per radar per
grid point
U wind - one value per grid point
V wind - one value per grid point
Spectrum width - (deferred)
Reflectivity and radial velocity fields will have multiple values for grid
cells if multiple radars scan that cell. U and V wind fields will, of course,
require nearly orthogonal radial winds from multiple sites and will have
only one value per grid cell. Spectrum width will require considerably
higher bandwidth since all gates have a value associated with it. Thus,
we will defer spectrum width processing unless there is sufficient capabilities
beyond those required for other fields.
Quality control information has not been explicitly determined, however,
each computed value should have some quality control information or some
statistical measure of the representativeness of each grid value.
2.1.1 RRV Data structures
RRV data structures will be "dynamic" given that the number of radars
scanning each cell will be
different and may change from time to time. Further, separate designations
will be used to identify locations outside the sampling domain (data void)
and those locations that are scanned but are below the minimum detectable
signal.
Proposed data structure for each grid cell:
Cell ID: x,y,z
derived u wind component
derived v wind component
u/v Quality control info.
Radar 1 ID:
Radar 1 Reflectivity value
Radar 1 Radial velocity value
Radar 1 Quality control info.
Radar 2 ID:
Radar 2 Reflectivity value
Radar 2 Radial velocity value
Radar 2 Quality control info.
.
.
.
Radar n ID:
Radar n Reflectivity value
Radar n Radial velocity value
Radar n Quality control info.
The order of radars for the each grid cell will be determined
by each radar's proximity to that cell location. The closest radar in range
will be listed first, then the second closest, etc.. This will allow for
fast processing for products requiring data only from the closest radar.
Additionally, any given cell will only be listed if data above the minimum
detectable signal from one or more radars is recorded. This should minimize
the RRV file size since there will typically be large data-void (i.e. clear-air)
regions within the volume.
2.1.2 RRV Metadata
Metadata for each radar will be stored in an array which
will contain each radar's lat/lon/elevation as well as range and azimuth
from each grid cell. Thus users will be able to derive radial components
from the azimuth values in a static file and radial velocity. Range information
may also be useful for determining the representativeness of any value
due to beam spreading, etc. (Users may find it more efficient to simply
compute the azimuth/range values on-the-fly using the grid point lat/lon
and radar's location.)
2.2 Spatial Requirements
Horizontal and vertical spatial requirements are driven primarily by modeling
and analysis needs for high resolution in both the horizontal and vertical
dimensions. Beam spreading considerations indicate, at some ranges, spatial
scales of the raw radar data will exceed the spatial scale of the grid.
(i.e. there will not be independent samples for some grid locations over
the grid domain.) Vertical levels will be determined from sea level (MSL).
Finer grid resolutions may be adopted in the future dependant upon on-site
processing capacity and communications bandwidth.
2.2.1 Horizontal scale
5 km. using the CONUS-B domain as the reference.
2.2.2 Vertical scale
0.5km increments from sea level to 3km MSL (~700mb) and 1.0km
increments from 3km to 16km MSL (~100mb). [This vertical scale is defined
in order to provide model input with greater vertical resolution near the
surface (i.e., ~50mb increments).
2.2.3 Projection
Lambert Conformal (as specified for AWIPS)
2.3 Temporal requirements
15 minute volumes will be created using the latest volume available from
each radar (as opposed to merging multiple volumes from one radar). An
advection correction may be applied to the individual volumes in order
to create the best possible fit for all radars. [Note - a time field will
be required if an advection scheme is applied.]
2.4 Product availability time
No later than 15 minutes after data cut-off. Data cut-off times will
be on the hour and at 15 minute increments past the hour.
2.5 Data format - netCDF.
3. DATA PROCESSING STEPS
The data processing steps are shown schematically in Figure 2. The order
of processing steps are subject to change depending on several factors
including processing capabilities and communications. The initial approach
used for each processing step is discussed along with some alternative
methods that may be employed in the future. All code is being developed
for the UNIX environment using C and Fortran programming languages. Whenever
possible, existing software has been adapted for this development. (The
numbers in parentheses at the end of each item approximate development
times during FY97.)
Figure 2. RRV processing steps.
3.1 Initial data capture
The Radar Interface and Data Distribution System consists
of a Sun Microsystems© SPARCstation®5 workstation running SunOS
4.1.3_U1; a Channel Service Unit/Data Service Unit (CSU/DSU), which receives
base data directly from the WSR-88D RPG Base Data User Port; an Advanced
Channel Service Unit/Data Service Unit (ACSU), which provides T1 termination
and signal conversion; and a High Speed Interface Serial/Sbus (HSI/S) card,
which strips low level communications protocol and passes the data to the
RIDDS software.
The RIDDS software allocates a segment of the workstation memory to
serve as an interim storage location to receive radar data in realtime
from the WSR-88D User Port. This buffer area, implemented as a "circular
buffer" model, ingests real-time data and makes it continually available
to other workstations connected to the RIDDS workstation via a dedicated
Eithernet connection.
3.1.1 Initial data resolution
Radial velocity and spectrum width out to a range of 230km with range
resolution of 0.25km and data resolution of 1.0 m/s. Reflectivity to 460km
with range resolution 1km and data resolution ~0.3dB.
3.1.2 Temporal resolution
5 to 10 minutes per volume depending on the volume coverage pattern
(VCP) employed at the time. [Assumption here is that all available volumes
will be initially processed at the site.]
3.2 Velocity de-aliasing
The initial development uses FSL-developed (Steve Albers) de-aliasing
code using LAPS winds to adjust the Nyquist interval. De-aliasing is currently
accomplished at the central facility. Nyquist information is stored and
sent along with the radial velocities in order to accomplish this.
A simple and reliable de-aliasing method is being developed based on
the remapped data over a Cartesian grid. This code will use sounding information
to adjust the Nyquist interval. This processing will be moved to the remote
sites. Other options may be tested in the future depending on the success
of this initial scheme. (Two months fte. for development, and testing).
3.3 Data remapping/interpolation
A lambert conformal projection will be used for remapping. The remapping
scheme uses the center beam point for each gate to map the gate to the
closest grid point (i.e. closest point technique). Other interpolation
options may be considered in the future including bi-linear, Cressman,
exponential, and uniform weighting functions. (Two months fte. for development,
and testing).
3.3.1 Static remapping coordinates
A program was developed to convert NWS AWIPS 10 km grid system into
a CONUS C 5 km grid system. Based on user-input 4-letter WSR-88D identifiers
(KFTG in this case), this program reads the radar's latitude and longitude
and determines which CONUS-C grid point the radar falls closest to. Then
it goes out a given distance (300 km in this case) in four directions and
defines a square RRV domain for each radar. The local RRV grid elevation
in meters is linear interpolated from the four AWIPS grid points surrounding
it. (This work was completed in FY96.)
3.4 Data Compression/Decompression
Data compression will be the last step to occur prior to data transmission
from each radar site. De-compression will be the initial central processing
step. The "GZIP" utility will be used as the initial compression scheme.
50:1 compression rates should be achievable. (One month fte. for development
and testing of other compression schemes.)
3.5 Data Transmission to Central Facility
Leased narrow-band (i.e. analog/voice-grade) links have been ordered
for CYS and GLD. 28.8kbps modems will be connected at both ends of the
line. This should provide sufficient band width to transfer individual
volumes within a five-minute time frame. (Two weeks fte. facility time
for problem analysis, system design, and quotes.)
An existing T1 link is being use to transmit the wideband data to Boulder
for KFTG. KFTG "on site" processing is actually accomplished in Boulder
so that code testing can be done locally.
3.6 Data Mapping to Common Conus Grid
Data from all radars will be mapped to a common CONUS grid for CONUS
product processing. A 1000km x 1000km sub-area of the CONUS C grid will
be used for the RRV. Corner points for this grid are:
This will produce a 201x201 grid or 40,401 grid points for each level (at
5km grid resolution). There will be 808,020 grid points for a 20-level
volume.
3.7 Conus Product Processing (Four months fte.)
3.7.1 Reflectivity fields and radial winds are mapped for each grid
point.
3.7.2 U/V wind synthesis - LAPS has multiple Doppler wind synthesis
software that will be employed. Other packages may also be reviewed.
3.7.3 Quality assessment/comparison fields computed - details to be
determined
3.8 RRV Displays (Two months fte.)
Reflectivity, radial velocity, and u/v winds will be created for the
surface (projection of the lowest tilt), and at altitudes coinciding with
standard pressure levels for the state, WFO, and regional scale displays.
A subset of products will be made available to the contributing sites
via the internet for evaluation/assessment purposes. Access to these display
will be password protected in order to limit access to participants.
There are currently no provisions to store or display the RRV grids
on the WFO-Advanced workstation. Thus, additional work will be required
in order in integrate and display this information. (Two months fte. additional
for software development and testing).
3.9 Data Archive
Details to be determined.
4. DOCUMENTATION
Product descriptions will be available for training and
subsequent development.(Two weeks fte.).
5. PRODUCT MONITORING/QUALITY CONTROL
Due to the developmental nature of this product, real time monitoring
(via WEB products) will be useful for diagnosing problems and overall quality
control. Further, compiling statistical information on basic and derived
fields will be helpful for evaluating the feasibility of a national product.
(2.0 months fte.).
6. HARDWARE COMPONENTS
Figure 3 shows the primary hardware components for data capture and
processing for the RRV product. On-site hardware is shown at the top of
the figure and central processing hardware is shown at the bottom. On-site
RRV processing is accomplished on a SPARC-II RISC machine and data is transmitted
to the central facility via 28.8kbps modem. The on-site RIDDS hardware
components provided by NSSL have been discussed in Section 3.1. Central
processing is done on a SPARCserver 670.
Figure 3. Primary hardware componets for the
RRV.
7. SCHEDULES
7.1 Approvals for wide-band links (including
1. KFTG - Approved via FAA request
2. KGLD - Approved via FAA request
3. KCYS - Approved via FAA request
4. KPUB - Approved via FAA request
5. KGJT - Approved via FAA request
7.2 RIDDS interface
1. KFTG - Installed FY96
2. KCYS - Scheduled for January 1997
3. KGLD - Scheduled for March 1997
Other sites - to be determined
7.3 Communication lines
1. KCYS - Scheduled for February 25, 1997
2. KGLD - Scheduled for March 1997
Other sites - to be determined
7.4 On-site RRV processors
1. KCYS - March 1997
2. KGLD - March 1997
7.5 Routine Product availability - 1 April 1997
7.6 Product Evaluation Period - 1 April 1997 through 31 December 1997.
(Initial evaluation period covering one warm-season and one cool-season
time period)