NASA/CR—2014–218444 

 

Configuration and Evaluation of a 

Dual-Doppler 3-D Wind Field System 

Winifred C. Crawford 

ENSCO, Inc., Cocoa Beach, Florida 

NASA Applied Meteorology Unit, Kennedy Space Center, Florida 

 Click here: Press F1 key (Windows) or Help key (Mac) for help 

November 2014
NASA STI Program ... in Profile 

Since its founding, NASA has been dedicated 

to the advancement of aeronautics and space 

science. The NASA scientific and technical 

information (STI) program plays a key part in 

helping NASA maintain this important role. 

The NASA STI program operates under the 

auspices of the Agency Chief Information Officer. 

It collects, organizes, provides for archiving, and 

disseminates NASA’s STI. The NASA STI 

program provides access to the NTRS Registered 

and its public interface, the NASA Technical 

Reports Server, thus providing one of the largest 

collections of aeronautical and space science STI 

in the world. Results are published in both nonNASA channels and by NASA in the NASA STI 

Report Series, which includes the following report 

types: 

x TECHNICAL PUBLICATION. Reports of 

completed research or a major significant 

phase of research that present the results of 

NASA Programs and include extensive data 

or theoretical analysis. Includes compilations of significant scientific and technical 

data and information deemed to be of 

continuing reference value. NASA counterpart of peer-reviewed formal professional 

papers but has less stringent limitations on 

manuscript length and extent of graphic 

presentations. 

x TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 

preliminary or of specialized interest, 

e.g., quick release reports, working 

papers, and bibliographies that contain 

minimal annotation. Does not contain 

extensive analysis. 

x CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

x CONFERENCE PUBLICATION. 

Collected papers from scientific and 

technical conferences, symposia, seminars, 

or other meetings sponsored or 

co-sponsored by NASA. 

x SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, 

often concerned with subjects having 

substantial public interest. 

x TECHNICAL TRANSLATION. 

English-language translations of foreign 

scientific and technical material pertinent to 

NASA’s mission.

Specialized services also include organizing 

and publishing research results, distributing 

specialized research announcements and 

feeds, providing information desk and personal 

search support, and enabling data exchange 

services. 

For more information about the NASA STI 

program, see the following: 

x Access the NASA STI program home page 

at http://www.sti.nasa.gov 

x E-mail your question to help@sti.nasa.gov 

x Phone the NASA STI Information Desk at 

757-864-9658 

x Write to: 

NASA STI Information Desk 

Mail Stop 148 

NASA Langley Research Center 

Hampton, VA 23681-2199 

This page is required and contains approved text that cannot be changed. 
NASA/CR—2014–218444 

 

Configuration and Evaluation of a DualDoppler 3-D Wind Field System 

Winifred C. Crawford 

ENSCO, Inc., Cocoa Beach, Florida 

NASA Applied Meteorology Unit, Kennedy Space Center, Florida 

 Click here: Press F1 key (Windows) or Help key (Mac) for help 

National Aeronautics and 

Space Administration

Kennedy Space Center 

Kennedy Space Center, FL 32899-0001

November 2014
Acknowledgments 

The author thanks Ms. Jackie Shafer and Dr. William Bauman of the AMU and Mr. Erik 

Magnuson of ENSCO, Inc. for their assistance in setting up the Linux PC and assisting with 

Linux training; WDSS II developers and experts Dr. Valliappa Lakshmanan, Benjamin Herzog, 

and Jeff Brogden for their assistance in determining the appropriate tools and tool options to 

use in WDSS-II; Mr. Pete Blottman for supplying the TDWR data, Mr. Todd McNamara for 

supplying the WSR data, and Mr. Fritz O’Hora for his knowledge of working with the WSR data.

 Click here: Press F1 key (Windows) or Help key (Mac) for help 

Available from: 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 

443-757-5802 

 Click here: Press F1 key (Windows) or Help key (Mac) for help 

This report is also available in electronic form at 

http://science.ksc.nasa.gov/amu
Executive Summary 

Customer: NASA’s Launch Services Program (LSP), Ground Systems Development and 

Operations (GSDO), and Space Launch System (SLS) programs; and the National Weather 

Service in Melbourne, Florida (NWS MLB). 

Current LSP, GSDO, and SLS space vehicle operations are halted when wind speeds from 

specific directions exceed defined thresholds and when lightning is a threat. Strong winds and 

lightning are difficult parameters for the 45th Weather Squadron (45 WS) to forecast, yet are 

important in the protection of customer vehicle operations and the personnel that conduct them. 

A display of the low-level horizontal wind field to reveal areas of high winds or convergence 

would be a valuable tool for forecasters in assessing the timing of high winds, or convection 

initiation and subsequent lightning occurrence. This is especially important for areas where no 

weather observation platforms exist. Developing a dual-Doppler radar capability would provide 

such a display to assist forecasters in predicting high winds and convection initiation. The wind 

fields can also be used to initialize a local mesoscale numerical weather prediction model to 

help improve the model forecast winds, convection initiation, and other phenomena. 

The 45 WS and NWS MLB tasked the Applied Meteorology Unit (AMU) to develop a dualDoppler wind field display using data from the 45th Space Wing radar, known as the Weather 

Surveillance Radar (WSR), NWS MLB Weather Surveillance Radar 1988 Doppler (KMLB), and 

the Orlando International Airport Terminal Doppler Weather Radar (KMCO). They also 

stipulated that the software used should be freely available. The AMU evaluated two software 

packages and, with concurrence from NWS MLB and the 45 WS, chose the Warning Decision 

Support System-Integrated Information (WDSS-II). 

The AMU collected data from two significant weather cases: a tornadic event on 14 April 

2013 and a severe wind and hail event on 12 February 2014. For the 14 April case, the data 

were from WSR and KMLB. For the 12 February case, the data were from KMCO and KMLB. 

The AMU installed WDSS-II on a Linux PC, then processed and quality controlled the radar data 

for display and analysis using WDSS-II tools. Because of issues with de-aliasing the WSR 

velocity field, the AMU did not use data from this radar in this study and only analyzed the 12 

February case. 

Merging the data to create the dual-Doppler analysis involved several steps. The AMU used 

instructions from the WDSS-II website and discussion forum to determine the correct tools to 

use for the analysis, and was successful in creating a merged reflectivity field, which was critical 

to the success of creating a merged velocity field. However, the AMU was unable to create a 

merged velocity field. The AMU researched the WDSS-II forum for discussions on similar 

issues, asked questions on the forum, and tested different options and values in the merger tool 

with no success. 

Developing a dual-Doppler wind field was the main goal of this task, but that was not 

accomplished. It could be an issue of not using the correct options or the correct value for the 

options used, or there could be issues with the radar data. There is a follow-on AMU task to 

install the operational version of WDSS-II in the NWS MLB office. This will provide more 

opportunities to try different options and input values in order to create a merged wind field from 

KMCO and KMLB. 
4

Table of Contents 

Executive Summary ................................................................................................................... 3 

Table of Contents ....................................................................................................................... 4 

List of Figures ............................................................................................................................ 6 

List of Tables ............................................................................................................................. 8 

1 Introduction ......................................................................................................................... 9 

1.1 Previous Work ............................................................................................................. 9 

1.2 Current Work ............................................................................................................... 9 

2 Radar Data and Analysis Tools ..........................................................................................10 

2.1 Radar Data .................................................................................................................10 

2.1.1 WSR-88D ............................................................................................................10 

2.1.2 WSR ....................................................................................................................11 

2.1.3 TDWR ..................................................................................................................11

2.2 Analysis Tools: Software and Hardware ......................................................................13 

2.2.1 Software ..............................................................................................................13

2.2.2 Hardware .............................................................................................................13 

3 WDSS-II Preparation .........................................................................................................14 

3.1 WDSS-II Setup ...........................................................................................................14

3.2 WDSS-II Data Processing ...........................................................................................15 

3.2.1 Reflectivity Data QC .............................................................................................15 

3.2.2 Velocity Data De-aliasing .....................................................................................15 

3.2.2.1 KMLB ............................................................................................................16 

3.2.2.2 WSR .............................................................................................................18 

3.3 WDSS-II Display .........................................................................................................20

4 Data Merger in WDSS-II ....................................................................................................24

4.1 Merger Grid.................................................................................................................24 

4.2 Reflectivity Merger ......................................................................................................25 

4.3 Velocity Merger ...........................................................................................................27 

5 Conclusions .......................................................................................................................30 
5.1 Summary ....................................................................................................................30 

5.2 Using WDSS-II ............................................................................................................30 

5.3 Recommended Future Work .......................................................................................31 

Appendix: WDSS-II Setup and Use Details ...............................................................................32 

References ...............................................................................................................................49 

List of Acronyms .......................................................................................................................50
6

List of Figures 

Figure 1. Google Earth image showing the locations of the MCO TDWR, 45 SW WSR, and 

NWS MLB WSR-88D. ..............................................................................................10 

Figure 2. The form on the WDSS-II website used to get access to the software package. ......14 

Figure 3. KMLB 8.0° velocity at 0040 UTC on 15 April 2013, a) aliased velocity and b) dealiased velocity. The locations of the WSR-88D and 45 SW WSR radars are 

shown by the yellow circles, and the circle and ellipse highlight locations of the 

aliased (a) and de-aliased (b) velocities. ..................................................................17 

Figure 4. WSR 10.9° velocity at 0040 UTC on 15 April 2013, a) aliased velocity and b) dealiased velocity. The locations of the WSR-88D and 45 SW WSR radars are 

shown by the yellow circles, and the circles highlight locations of aliased (a) and 

de-aliased (b) velocities. ..........................................................................................19 

Figure 5. The initial screen in WDSS-II when issuing the wg command in a terminal 

window. The processes used to load data are highlighted by red rectangles with 

red arrows showing the sequence to get the dialog box that allows the user to 

browse for the data directory. ..................................................................................21 

Figure 6. The WDSS-II GUI with data and map background displayed. The Sources 

section contains a tab named “Feb12-KMCO” with the choices of radar product 

(left column), elevation angle (middle column), and scan time (right column) for 

KMCO on 12 February 2014. The highlighted items in each list determine what is 

displayed: the 0.3° QC’d reflectivity at 213527 UTC.................................................22 

Figure 7. Same data as Figure 6, but showing the Products tab containing a list of the data 

sets that have been loaded for display and the controls for changing elevation 

angles and times. ....................................................................................................23 

Figure 8. Google Earth image of the dual-Doppler lobes and associated merger grid outline 

for KMCO and KMLB. ..............................................................................................25 

Figure 9. The KMCO reflectivity at 2316 UTC 12 February 2014, elevation angle 0.3 

degrees. The yellow circles show the locations of the KMCO and KMLB radars. .....26 

Figure 10. As in Figure 9 but for KMLB reflectivity at 2318 UTC, elevation angle 0.5 

degrees. ..................................................................................................................26 

Figure 11. The KMCO and KMLB merged reflectivity at 2316 UTC 12 February 2014, height 

of 1 km. ....................................................................................................................27 

Figure 12. The KMCO velocity at 2212 UTC 12 February 2014, elevation angle 1.0 degrees. 

The yellow circles show the locations of the KMCO and KMLB radars. ....................28 

Figure 13. As in Figure 12, but for the KMLB velocity at 2211 UTC, elevation angle 1.3 

degrees. ..................................................................................................................28 

Figure 14. The KMCO and KMLB merged velocity at 2211 UTC 12 February 2014, height of 

3 km.........................................................................................................................29
Figure 15. The top portion of the WDSS-II home page. The links with information on how to 

install and use WDSS-II are in the left column under the Documentation link. .........31 

List of Appendix Figures 

Figure 1. Content of the .bashrc file. .......................................................................................32 

Figure 2. The new dialog box displayed after clicking the Browse... button on the initial 

dialog box (section 3.3, Figure 5). The chosen directory is surrounded by the red 

box, the desired code_index.xml file is highlighted in blue on the right side. ............37 

Figure 3. The initial dialog box (section 3.3, Figure 5) showing the chosen input file in the 

URL text box and the user-supplied name in the Name text box. .............................38 

Figure 4. The WDSS-II display showing KMCO data on 12 February 2014 at 213527 UTC. 

The Sources section displays the loaded radar data parameters to choose for 

display. The left column contains the radar products, the middle column contains 

the elevation angles, and the right column contains the time of each scan. .............39 

Figure 5. WDSS-II with the map background that comes with the software. The data are 

the same as in Figure 4, but zoomed out. ................................................................40 

Figure 6. Contents of the maps.xml file in the w2config/maps directory. .................................41 

Figure 7. The Add New Map dialog box is displayed after clicking on Add... in the Maps 

menu. The State map is highlighted. ........................................................................41 

Figure 8. The WDSS-II GUI displaying the state and county boundaries using the same 

data and zoom level as Figure 6. The Earth map is highlighted to show how to 

eliminate a map background without deleting it from the list by checking the box 

next to Hide in the Maps section. .............................................................................42 

Figure 9. Similar to Figure 6 in section 3.3, except the Sources tab contains a second tab 

named “Feb12-KMLB”. The highlighted items in each list determine what is 

displayed: the KMLB 0.5° QC’d reflectivity at 213307 UTC. .....................................43 

Figure 10. Similar to Figure 9, except for the de-aliased velocity at 213324 UTC and 

showing the Products tab contents. The buttons with a red box control the time 

displayed and the buttons with a green box control the elevation angle displayed. ..44
8

List of Tables 

Table 1. The VCPs used for the NWS MLB WSR-88D, 45 SW WSR, and the MCO TDWR 

during the 14 April 2013 and 12 February 2014 case study time periods. For the 

WSR, the Default VCP was used on 14 April. The 45 SW VCP is included for 

completeness. .........................................................................................................12
1 Introduction 

Current Launch Services Program, Ground Systems Development and Operations, and 

Space Launch System space vehicle operations are halted when wind speeds from specific 

directions exceed defined thresholds and when lightning is a threat. Strong winds and lightning 

are difficult parameters for the 45th Weather Squadron (45 WS) to forecast, yet are important in 

the protection of customer vehicle operations and the personnel that conduct them. A display of 

the low-level horizontal wind field to reveal areas of high winds or convergence would be a 

valuable tool for forecasters in assessing the timing of high winds impacting operations, or 

convection initiation and subsequent lightning occurrence. This is especially important for areas 

where no weather observation platforms exist. Developing a dual-Doppler weather radar 

capability would provide such a display to assist forecasters in predicting high winds and 

convection initiation. The wind fields can also be used to initialize a local mesoscale numerical 

weather prediction model to help improve the model forecast winds, convection initiation, and 

other phenomena. Finally, data combined from multiple radars would lessen radar geometry 

problems such as the cone of silence and beam blockage. This display would aid in using 

ground processing and space launch resources more efficiently by stopping or starting work in a 

timelier manner. 

1.1 Previous Work 

A previous Applied Meteorology Unit (AMU) task (Huddleston 2012) investigated the 

technical, hardware, and software requirements necessary to create a dual-Doppler capability 

using the 45 Space Wing (45 SW) Radtec 43/250 and the National Weather Service in 

Melbourne, Florida (NWS MLB) Weather Surveillance Radar 1988-Doppler (WSR-88D) radars. 

The evaluation showed that the creation of a dual-Doppler capability using the existing 

operational radar systems was feasible. However, data security and cost considerations had to 

be taken into consideration in light of current budgetary constraints. 

NWS MLB also expressed interest in this task, and suggested including data from the 

Federal Aviation Administration Terminal Doppler Weather Radar (TDWR) at Orlando 

International Airport (MCO). In addition, in the event of a radar outage at one of the sites, the 

multi-radar algorithms would provide continuing coverage of the area through use of the data 

from the remaining operational radar sites. 

1.2 Current Work 

With the positive results in Huddleston (2012), the 45 WS and NWS MLB tasked the AMU to 

develop a dual-Doppler wind field display using data from the 45 SW radar, known as the 

Weather Surveillance Radar (WSR), NWS MLB WSR-88D (KMLB), and the MCO TDWR 

(KMCO). They also stipulated that the software used to derive the wind field over east-central 

Florida should be freely available. The AMU evaluated two software packages and, with 

concurrence from NWS MLB and the 45 WS, chose the Warning Decision Support SystemIntegrated Information (WDSS-II; www.cimms.ou.edu/~lakshman/WDSS2/index.shtml). 
10

2 Radar Data and Analysis Tools 

The AMU collected data from the three local Doppler radars identified in section 1.2. The 

tools needed for the analysis included software and a computer with sufficient computing power 

and memory to run the software and store the input and output data. 

2.1 Radar Data 

As stated previously, data from three local Doppler radars were used in this task: KMLB, 

WSR located west of the Kennedy Space Center (KSC)/Cape Canaveral Air Force Station 

(CCAFS) area, and KMCO. Figure 1 shows the radar locations. 

Data from two significant weather events were collected for the analysis: 14 April 2013 and 

12 February 2014. During the evening of 14 April, two F-0 tornados, winds in excess of 50 kt, 

and 1-inch hail occurred in and surrounding Brevard County, Florida, which is in NWS MLB’s 

county warning area (CWA) and contains KSC/CCAFS. On 12 February, winds in excess of 50 

kt and quarter-size hail were reported in some central Florida locations beyond Brevard County, 

but near and within the CWA. 

Figure 1. Google Earth image showing the locations of the MCO TDWR, 45 SW WSR, 

and NWS MLB WSR-88D. 

2.1.1 WSR-88D 

KMLB is a Doppler radar with dual-polarization technology. It is an S-band radar with a 10-

cm wavelength. The beam width is 1° and gate spacing along the beam is 0.25 km. The WSR88D uses several volume coverage patterns (VCPs), which are sets of elevation angles the 

radar goes through in a specific sequence. The choice of VCP depends on the weather 

conditions and is controlled by the operator. 
Data for both severe weather events described in section 2.1 were downloaded from the 

National Climatic Data Center (NCDC). The files were in Level II format, which contain the base 

data values for reflectivity, mean radial velocity, and spectrum width, and the dual-pol data 

values for differential reflectivity, correlation coefficient, and differential phase. Each file contains 

a complete volume scan with data from all elevation angles in the VCP. On the days used in this 

task, KMLB was predominantly in VCP 12, which has 14 elevation angles and was designed for 

use during severe convective events. The angles associated with VCP 12 and the order in 

which they are scanned are shown in Table 1. The first three angles are scanned twice, first for 

reflectivity and then for velocity. It took approximately 4 min 40 sec to scan through the elevation 

angles in VCP 12. Level-II format files can be processed by WDSS-II routines. 

2.1.2 WSR 

The 45 SW WSR is also a Doppler radar with dual-polarization technology. It is a C-band 

radar with a 5.3-cm wavelength. The beam width is 0.95° and gate spacing along the beam is 

0.25 km. The 45 SW VCP is based on recommendations from the AMU (Short 2008) and meets 

a 45 SW requirement for minimizing the vertical gaps between beams. It has 13 elevation 

angles that scan in an interleaving pattern, going through every other angle on the way up and 

down. It takes approximately 2 min 50 sec to scan through the elevation angles in the 45 SW 

VCP. This scan strategy provides the 45 WS forecasters with improved monitoring of 

x low-level convergence in the boundary layer that contributes to thunderstorm 

development; 

x the atmospheric electrification layer (+5 C to -20 C) for evaluating lightning launch 

commit criteria (LLCC) and predicting lightning onset; 

x the layer where convective cloud tops and anvil clouds typically occur (25-40,000 ft) for 

evaluating LLCC; and 

x thunderstorms approaching from the southwest due to the reduced cone of silence 

(Roeder and Short 2009). 

Data from the 14 April case were collected from this radar. The files were provided by Mr. 

McNamara of the 45 WS. WSR data are in Vaisala’s Sigmet Interactive Radar Information 

System (IRISTM) format, and the files contain the same base and dual-pol values as the WSR88D Level II data. Each file contains data from one elevation angle. The VCP used during the 

14 April event was the system default. As a result of an ongoing software upgrade project, the 

VCP sometimes changed to the default setting when the system was changed to a baseline 

configuration. The forecasters and LWOs were sometimes unaware of this change unless they 

noticed something different on the display. Once noticed, they would make the change back to 

the 45 SW VCP. Maintenance and a baseline change had recently been done on the WSR in 

April 2013, causing the system default VCP to be used for this case. This will not be an issue 

once the software upgrade project is complete. Table 1 shows the elevation angles in the 45 

SW VCP and the elevation angles in the default VCP used in this data set in the order they are 

scanned. The IRIS files can be processed by WDSS-II algorithms. 

2.1.3 TDWR 

KMCO is a Doppler radar but does not have dual-polarization capability. Like the WSR, it is 

a C-band radar with a 5.3-cm wavelength. The beam width is 0.55° and gate spacing along the 

beam is 0.15 km. TDWR has two VCPs: VCP 90, called Monitor mode, and VCP 80, called 

Hazardous mode. The specific elevation angles for each VCP vary among TDWR sites, and are 

dependent on the range of the radar from the airport. Table 1 shows the angles in both VCPs for 

MCO. The VCP in use is chosen automatically by the TDWR software based on echo intensity, 
12

coverage, and range to the airport. It takes approximately six minutes to scan through the 

elevation angles in both VCPs. In VCP 90, the elevation angles are scanned sequentially from 

lowest to highest in a volume scan. In VCP 80, the lowest angle is scanned every minute and 

the upper angles are scanned in two sequences. 

Files for the 14 April case were sent to the AMU by Mr. Paul Biron of the FAA, but WDSS-II 

could not process the file format. WDSS-II does have algorithms that can process the files taken 

directly from the Supplemental Product Generator (SPG). TDWR data are archived on the SPG 

for eight days and then overwritten. Work on this task started well after the 14 April case, 

meaning files for that day were no longer available on the NWS MLB SPG. Therefore, data from 

the other severe weather case on 12 February were collected from the SPG located in the NWS 

MLB office by Mr. Blottman of NWS MLB. The MCO TDWR primarily used VCP 80 on 12 

February. 

Table 1. The VCPs used for KMLB, WSR, and KMCO during the 14 

April 2013 and 12 February 2014 case study time periods. For the 

WSR, the Default VCP was used on 14 April. The 45 SW VCP is 

included for completeness.

KMLB WSR KMCO 

VCP 12 Default 45 SW VCP 90 VCP 80 

0.5 0.2 0.2 0.3 0.3 

0.5 0.4 2.2 0.3 0.3 

0.9 3.2 5.7 1.0 1.0 

0.9 6.6 8.9 3.3 3.3 

1.3 10.9 12.5 6.1 6.6 

1.3 16.1 17.6 11.0 0.3 

1.8 22.4 28.3 15.9 10.0 

2.4 26.0 22.0 20.8 13.4 

3.1 19.1 14.5 25.7 16.8 

4.0 13.4 10.6 30.6 0.3 

5.1 8.6 7.3 35.5 29.9 

6.4 4.8 4.0 40.4 60.0 

8.0 1.8 1.2 45.3 3.3 

10.0 50.2 0.3 

12.5 55.1 6.6 

15.6 60.0 10.0 

19.5 13.4 

0.3 

16.8 

29.9 

60.0 

0.3 
2.2 Analysis Tools: Software and Hardware 

The AMU considered two free software packages to conduct the analysis and determined 

the computing resources needed for each. 

2.2.1 Software 

Huddleston (2012) identified three software packages that can be used to create a dualDoppler analysis: a set of programs from The National Center for Atmospheric Research 

(NCAR), WDSS-II, and an add-on product for the 45 SW’s IRIS software called NDOP. 

Vaisala’s cost for NDOP at the time of that study was $16,000. Since the AMU was tasked to 

find freely available software because the 45 SW and KSC Weather Office budgets did not allow 

for software purchase, NDOP was not considered for this task. However, it should remain a 

consideration should funds become available in the future. 

The NCAR radar processing programs can, among other capabilities, create dual- and multiDoppler analyses (https://wiki.ucar.edu/display/raygridding/Home). This software was used in 

Dolan and Rutledge (2007) to create multi-Doppler analyses in real time. It is also used by 

researchers at the University of Alabama in Huntsville (Dr. Lawrence Carey, personal 

communication). Mr. Jay Miller, retired from NCAR, is the contact point for the software and 

stated that he is working on updating the software and creating tutorials. That update is 

ongoing. 

The WDSS-II package was developed jointly by the Cooperative Institute for Mesoscale 

Meteorological Studies (CIMMS) at the University of Oklahoma (OU) and the National Severe 

Storms Laboratory. It has several capabilities including routines to merge Doppler radar velocity 

data onto a grid. The version available for free download can only be used in research mode. A 

license is needed for the operational version, but the licensed version is free for the NWS. 

(www.cimms.ou.edu/~lakshman/WDSS2/index.shtml). 

After considering the positives and negatives of each software package and consulting with 

NWS MLB, the AMU chose the research version of WDSS-II to conduct the analysis. The 

ongoing updates to the NCAR software and the multiple programs involved could make it 

difficult to work with. WDSS-II has other capabilities besides merging radar data and is in use at 

several NWS offices. 

2.2.2 Hardware 

Through contacting the developers and consulting the websites of the NCAR and WDSS-II 

software, the AMU learned that any PC running a current Linux operating system is sufficient to 

run either package. The AMU has a 64-bit PC that was configured for this purpose. It has dual 

2.4 GHz processors, 6 GB RAM and 1 TB of hard drive space. The freely available Linux 

Community Enterprise Operating System (CentOS) Release 6.4 was installed on the PC. This 

operating system (OS) is compatible with the RedHat Linux OS. 
14

3 WDSS-II Preparation 

This section will describe how to use WDSS-II for the dual-Doppler analyses, starting with a 

brief overview of how to set it up. Details are in the Appendix. Installing and running the WDSSII software requires a working knowledge of the Linux OS. Anyone who wants to use this 

software package should get Linux training if not already knowledgeable. 

3.1 WDSS-II Setup 

The AMU accessed the WDSS-II package through a form on the website 

www.cimms.ou.edu/~lakshman/WDSS2/download.shtml by choosing a build (Figure 2), 

providing an email address and clicking on the “OK” button. Once on the page, scroll down to 

“WDSS-II Download Request” to find the form. Based on the PC configuration described in 

section 2.2.2, the AMU chose the first configuration in the list. After clicking the “OK” button, an 

email from CIMMS will be sent to the address given containing a link to download the requested 

build. 

Figure 2. The form on the WDSS-II website used to get access to the software package. 

Installation and quick-start instructions are provided on the WDSS-II installation webpage 

(www.cimms.ou.edu/~lakshman/WDSS2/installation.shtml). The AMU first set up the Linux 

environment variables specific to running WDSS, which can be found on the installation and 

quick-start website above. Next, the command ldd wg was executed. This displayed all the 

libraries needed to run WDSS-II graphics and which ones existed in the path. Only two graphics 

libraries were missing. Mr. Erik Magnuson, a system and software engineer with ENSCO, Inc., 

assisted in setting up the graphics with the appropriate drivers and libraries. After Mr. 

Magnuson’s assistance, the AMU executed the command wg in a terminal window to open the 

WDSS-II display with success. 

For setup details, go to the Download and Setup section in the Appendix. 
3.2 WDSS-II Data Processing 

Once the display was working, the next step was to prepare data for the display. The data 

used and produced by WDSS-II tools are in netCDF format. Therefore, the data from all radars 

must first be converted to this format before creating and displaying radar products. Fortunately, 

WDSS-II has tools to process WSR-88D Level-II, TDWR, and Sigmet IRIS data formats and 

convert them to netCDF format. A list of WDSS-II tools and details on their usage can be found 

on the tools webpage: www.cimms.ou.edu/~lakshman/WDSS2/algdoc.shtml. 

WSR-88D Level-II files can be converted directly into netCDF format with the ldm2netcdf

tool. The instructions to process Level-II data are on the installation webpage (section 3.1) 

under the heading “Creating Netcdf Products from Level-II files.” The AMU processed the KMLB 

data according to these instructions. 

Before processing the TDWR and Sigmet IRIS data, information on their locations and VCPs 

must be entered into specific configuration files so WDSS-II will process them correctly. The 

AMU added the location information for both radars in the WDSS-II configuration file 

“radarinfo.xml”, and created new VCP files for each. The next step was to convert the data to a 

format that could be processed by the ldm2netcdf tool. The AMU used the tools 

sigmetIngestor and tdwrLogIngest to do this conversion for the WSR and KMCO data, 

respectively, then ran ldm2netcdf on both output data sets to create netCDF files for working 

with and displaying the data in WDSS-II. The AMU then used WDSS-II tools to quality control 

(QC) the reflectivity data and de-alias the velocity data before further processing and display. 

For details on the options used with the data processing commands, read the Data Processing 

section in the Appendix. 

3.2.1 Reflectivity Data QC 

The AMU QC’d the KMLB and KMCO reflectivity data using the WDSS-II tool w2qcnn. It 

uses reflectivity, velocity, and spectrum width data gate-by-gate in a neural network to 

determine if a return is meteorological or not (Lackshmanan et al. 2007). The AMU ran this tool 

using the netCDF data output from the ldm2netcdf tool. The WSR data were not QC’d with 

w2qcnn because that radar software has an internal routine that QC’s the reflectivity data and 

outputs them separate files from the non-QC’d reflectivity data. For the case data in this study, 

very few reflectivity gates were removed during the QC processes, perhaps due to the fact that 

the time periods in the data sets contained mostly meteorological targets during the severe 

weather events. Details on the command using w2qcnn are in the Appendix under the 

Reflectivity QC subsection in the Data Display section. 

3.2.2 Velocity Data De-aliasing 

Doppler radars have a maximum unambiguous radial velocity called the Nyquist velocity. If 

the wind speeds exceed the Nyquist velocity, the direction will change from toward (away from) 

the radar to away from (toward) the radar, and the magnitude of the radial winds will change in 

increments of twice the Nyquist velocity. For example, if the Nyquist velocity is 30 ms-1 and the 

wind speed is 35 ms-1, 

Actual velocity toward the radar: -35 ms-1 + 2*30 ms-1 = 25 ms-1

Actual velocity away from the radar: 35 ms-1 - 2*30 ms-1 = -25 ms-1

In this case, actual velocities toward the radar will be displayed as away from the radar and vice 

versa. For stronger wind cases, the sign of the value indicating winds toward or away from the 

radar may not change, but the magnitude will be incorrect. Also, more than one multiple of 

2*Nyquist may be needed to reduce the velocity magnitude to a value with in the Nyquist 

velocity interval, ±30 ms-1 in this example. 
16

The KMCO velocities are de-aliased within the TDWR system and output as separate files 

from the aliased velocities. Therefore, the AMU did not run WDSS-II de-alias tool for this data 

set. The KMLB and WSR velocities, however, have no such algorithm in their systems and 

required de-aliasing. 

3.2.2.1 KMLB 

The KMLB velocity data were de-aliased with an added option, -D, to the ldm2netcdf

command. The use of this option is described further in the Appendix in the KMLB Data 

Processing subsection of the Data Processing section. 

Examples of aliased and de-aliased KMLB velocity data are shown in Figure 3a and b, 

respectively. In the color legend at the top of each image the cool colors to the left of the center 

gray block (0 kt) represent negative velocity values toward the radar and the warm colors to the 

right represent positive velocities away from the radar. The Nyquist velocity of -55.7 kt towards 

the radar occurs in the light purple region just left of the green, and 55.7 kt away from the radar 

occurs in the yellow area just right of the red. 

In the lower left of Figure 3a, aliased velocities are represented by the yellow and red values 

in the center of the area surrounded by the circle. Going from the left of this circle toward the 

right, velocities were toward the radar and increasing in magnitude from -50 to -55 kt 

represented by the colors changing from green to light purple. Continuing to move toward the 

right in the center of the circle, the values abruptly changed to 53 kt away from the radar in the 

yellow and 40 kt away from the radar in the red. If real, this would be an area of very strong 

convergence, but it is more likely indicative of a level with winds stronger than -55.7 kt toward 

the radar. Similar aliasing is in the area surrounded by the ellipse in the upper right, except the 

actual velocities in this case were away from the radar. The speeds increased to 55.7 kt going 

from the red to yellow, but changed to -53 kt toward the radar where the color changed to light 

purple in the center of the yellow area. Velocity aliasing is evident in other areas of the display 

as well. These two areas were chosen for demonstration. 

The results of the de-aliasing algorithm are shown in Figure 3b. In the circle, the velocities of 

53 to 40 kt away from the radar in yellow and red became velocities toward the radar of -58 to -

71 kt represented by light to medium purple. The aliased velocities in the ellipse changed from 

around -53 kt toward the radar to 58 kt away from the radar. The new de-aliased values were 

more consistent with the surrounding velocities in both speed and direction. 
Figure 3. KMLB 8.0° velocity at 0040 UTC on 15 April 2013, a) aliased velocity 

and b) de-aliased velocity. The locations of the WSR-88D and 45 SW WSR 

radars are shown by the yellow circles, and the circle and ellipse highlight 

locations of the aliased (a) and de-aliased (b) velocities. 
18

3.2.2.2 WSR 

The WSR velocity data were de-aliased with the dealias2d tool. The use of this tool is 

described further in the Appendix Velocity De-aliasing subsection of the Data Processing 

section. 

Before the data were QC’d, Ms. Crawford noticed more aliasing in the velocity data than for 

KMLB. The Nyquist velocity for the WSR is 21.3 m/s, or 41.4 kt. This can be seen clearly in 

Figure 4a. The legend at the top of the image has the same colors and values in kt as in Figure 

3. The Nyquist velocity of -41.4 kt towards the radar occurs in the bright green region on the left, 

and 41.4 kt away from the radar occurs in the bright red area on the right. The circle to the left of 

the WSR radar in Figure 4a is in an area of velocities toward the radar, and the two to the right 

of the WSR are in an area of velocities away from the radar. Velocity aliasing is evident in these 

three circles as well as other areas in the display. In all three circles, velocities between the 

red/green boundary change abruptly from 40 kt toward the radar in the red to -41 kt away from 

the radar in the green. 

The de-aliased velocities are shown in Figure 4b. The aliased velocities toward the radar in 

the circle to the left of WSR were changed from the aliased ~40 kt away from the radar to a dealiased -84 kt toward the radar (purple). The correct de-aliased values should be in the range of 

-40 to -50 kt toward the radar. The velocities in the circle to the upper right of WSR experienced 

the same issue. Where the velocities toward the radar (green) should have been changed to 40 

to 45 kt away from the radar, they were actually changed to 84 to 87 kt away from the radar. In 

the circle below to the lower right of WSR, the velocities toward the radar should have been dealiased to away from the radar, but were not. The AMU noted that the WDSS-II display stated 

the Nyquist velocity was 62.2 kt. Looking further into the netCDF files the Nyquist velocity was 

found to be 31.98 ms-1, or 62.2 kt. It is clear when looking at the aliased velocities in Figure 4a 

that the Nyquist velocity should be 41.4 kt. It is not clear how it came to be defined as 62.2 kt. 

It is clear that these incorrectly de-aliased velocities cannot be used to derive a dual-Doppler 

wind field as the result would be erroneous. Because of this issue, the AMU decided to put 

these data aside and work on creating a dual-Doppler analysis between the KMLB and KMCO 

radars. 
Figure 4. WSR 10.9° velocity at 0040 UTC on 15 April 2013, a) aliased velocity 

and b) de-aliased velocity. The locations of the WSR-88D and 45 SW WSR 

radars are shown by the yellow circles, and the circles highlight locations of 

aliased (a) and de-aliased (b) velocities. 
20

3.3 WDSS-II Display 

The first-time the AMU opened the WDSS-II graphical user interface (GUI), it had a black 

screen with a gray control area at the bottom (Figure 5). It is through this control area that the 

data are displayed. The darker gray buttons on the left in the control area are the top-level 

functions for the display. The first step was to load radar data. The AMU did this by clicking the 

Sources tab on the left to access the options needed to load and display the processed radar 

data. To add data, the AMU clicked the Add... button in the Sources tab section. This 

displayed the dialog box in the center of the display area in Figure 5. The AMU clicked the 

Browse... button next to the URL text box in the New Source area at the bottom of the dialog 

box, navigated to the directory containing the prepared 12 February KMCO data, provided the 

name “Feb12-KMCO” for the data set in the Name text box, and then clicked the Add button at 

the bottom right of the dialog box. Using the default “All” in the History text box loaded all the 

files in the directory. 

After several more steps, including loading a map background, the AMU displayed the 

KMCO data for the severe weather event on 12 February 2014, shown in Figure 6. A tab with 

the name provided for the data set appeared in the Sources tab section containing three 

columns: radar products on the left, available elevation angles in the middle, and scan times on 

the right. For this example, the AMU chose the product ReflQC, which is QC’d reflectivity, the 

0.3° elevation scan, and the initial time in the data set at 213527 UTC. Several data sets can be 

added through the Sources tab, with each having its own tab. 
Figure 5. The initial screen in WDSS-II when issuing the wg command in a terminal 

window. The processes used to load data are highlighted by red rectangles with red 

arrows showing the sequence to get the dialog box that allows the user to browse for the 

data directory. 
22

Figure 6. The WDSS-II GUI with data and map background displayed. The Sources 

section contains a tab named “Feb12-KMCO” with the choices of radar product (left 

column), elevation angle (middle column), and scan time (right column) for KMCO on 12 

February 2014. The highlighted items in each list determine what is displayed: the 0.3° 

QC’d reflectivity at 213527 UTC. 

The features in the Products tab, which is at the top left in the control area, allow the user 

to choose which radar product to display and to scroll through elevation angles and times of the 

displayed product. Figure 7 shows the Products tab contents for the same data as in Figure 6. 

The time, date, and elevation angle of the displayed data are shown at the top, choices to 

control what is displayed are under this on the left, a text box area with columns for the radar 

source and product is to the right of that, and controls for the elevation angle and time displayed 

are on the right. Multiple products can be chosen in the Sources tab to add in the Products tab 

text box. More details and examples are in the Data Display section of the Appendix. 
Figure 7. Same data as Figure 6, but showing the Products tab containing a list of the 

data sets that have been loaded for display and the controls for changing elevation 

angles and times. 
24

4 Data Merger in WDSS-II 

The goal of this task was to use data from two or more Doppler radars to create a threedimensional (3-D) wind field over east-central Florida and the KSC/CCAFS area. Given the 

velocity de-aliasing issues identified with the WSR data in section 3.2.2.2, the AMU used the 

KMLB and KMCO data as a proof-of-concept for the analysis. The method successful in 

merging the KMLB and KMCO data could be used later to merge the WSR data with either of 

the other two radars. 

The AMU researched the WDSS-II forum for how to merge data from two or more radars 

and found that the merging process takes several steps. First, a 3-D grid area must be created 

for the merge command to access. Next, a simulator tool is started that reads the processed 

data from two or more radars and reorders it according to time. The merger tool can then be 

started in another terminal window. This tool uses the output from the simulator as input, 

processes the data using the merging procedure described in Lakshmanan et al. (2006), and 

then outputs the merged data. 

4.1 Merger Grid 

The grid over which the merger takes place is defined by a northwest latitude/longitude 

(lat/lon) and grid top height, a southeast lat/lon and grid bottom height, and the horizontal and 

vertical grid spacing. The AMU first created the dual-Doppler lobes for KMCO and KMLB. The 

baseline, or distance, between the two radars is 38 NM (70.5 km), which is within the optimal 

range for conducting a dual-Doppler analysis as reported in Huddleston (2012). The northwest 

and southeast corner lat/lons of a box that encompassed both lobes, as shown in Figure 8, were 

used to define the merger grid corners. 

The WDSS-II tool createCache creates the gridded area and must be run for each radar in 

the analysis. It computes where the data from each radar should be inserted in the 3-D grid. The 

output is used by the merger tool described later. Using this tool for both radars, the AMU 

defined a grid with a northwest corner lat/lon of 29.5 N/82 W and top of 10 km, a southeast 

corner lat/lon of 27 N/80 W and bottom of 0 km, and grid spacing of 0.009x0.009 degrees 

horizontal and 0.5 km vertical. There are approximately 111 km per degree latitude and 

approximately 97–99 km per degree longitude at the latitudes in the grid. The horizontal grid 

spacing of 0.009 is roughly equal to 1 km in both dimensions, slightly shorter in the east-west 

dimension than north-south. This resolution can be changed depending on operational or 

numerical model needs. 

Details of how the AMU used the createCache tool are in the Data Merger Grid Setup 

section of the Appendix. 
Figure 8. Google Earth image of the dual-Doppler lobes and associated 

merger grid outline for KMCO and KMLB. 

4.2 Reflectivity Merger 

According to information in the WDSS-II forum, the velocity merger requires merged 

reflectivity data as input. Also, the mergers must be run separately when using archived data. 

Therefore, the AMU created the merged reflectivity data first. Note, however, that the reflectivity 

and velocity mergers will be run concurrently in the real-time WDSS-II. 

For mergers, two tools must be run simultaneously in separate terminal windows: 

w2simulator and w2merger. The first, w2simulator, reorders the radar scans by time and 

writes them out, and then w2merger fuses the data from the multiple radars onto the defined 3-

D lat/lon grid using the procedure in Lakshmanan (2006). The inputs to w2simulator are the 

files output by ldm2netcdf for all radars being merged, an output directory, and the beginning 

and ending time for the merger, if desired. The inputs to w2merger are the output files from 

w2simulator, an output directory, and several options related to merging reflectivity. The AMU 

followed these procedures and was successful in merging the reflectivities between KMCO and 

KMLB. Details on the inputs to the tools used by the AMU are in the Reflectivity Data Merger 

section of the Appendix. 

Figure 9 shows the reflectivity from the KMCO 0.3 degree elevation scan at 2316 UTC on 12 

February 2014. The location of each radar is surrounded by a yellow circle. Note the small cone 

of silence, the black circle inside the yellow circle, at the KMCO radar. Figure 10 shows the 

reflectivity from the KMLB 0.5 degree elevation scan at 2318 UTC, the closest KMLB scan in 
26

time to the KMCO scan in Figure 9. The cone of silence at the KMLB radar is larger than that of 

KMCO. 

Figure 9. The KMCO reflectivity at 2316 UTC 12 February 2014, 

elevation angle 0.3 degrees. The yellow circles show the locations 

of the KMCO and KMLB radars. 

Figure 10. As in Figure 9 but for KMLB reflectivity at 2318 UTC, 

elevation angle 0.5 degrees. 

KMCO

KMLB

KMCO

KMLB
Figure 3 shows the merged reflectivities at 2316 UTC. Note the reflectivities over the cones 

of silence seen in Figure 9 and Figure 10. The resolution is coarser than for either radar, KMLB 

has a gate spacing of 0.25 km and KMCO has a gate spacing of 0.15 km. The grid can be 

changed in the createCache tool if higher resolution is desired, but the 1-km grid spacing may 

be more appropriate for the merged wind field, which is the ultimate goal of this task. 

Figure 11. The KMCO and KMLB merged reflectivity at 2316 UTC 

12 February 2014, height of 1 km. 

4.3 Velocity Merger 

The process to create merged velocities is similar to that for merged reflectivities with some 

differences in the inputs to the tools. The merged reflectivity must be created first as it is used 

as input to the velocity merger routine. The w2simulator tool is used to access the input data 

for the velocity merger, but it has the merged reflectivity as additional input. As with the 

reflectivities, the AMU started w2simulator first, and then started w2merger for the velocity 

merger in another terminal window. 

The inputs to w2simulator are the same files are the same files as for the reflectivity merger 

with the addition of the output from w2merger for reflectivity, an output directory, and the 

beginning and ending time for the merger, if desired. The inputs to w2merger are the output 

files from w2simulator, an output directory, and several options related to merging velocity. The 

AMU followed these procedures and was unsuccessful in creating a merged wind field with the 

KMCO and KMLB velocity data as shown in Figure 6 of Lakshmanan et al. (2006). Details on 

the inputs to the tools used by the AMU are in the Velocity Data Merger section of the Appendix. 

The AMU searched the WDSS-II forum for ideas on what input to use in w2simulator and 

w2merger, asked questions on the forum when those ideas did not work, searched the WDSSII website for documentation on using the merger tool for velocity, and tried several 

configurations of input to the tool. 

Figure 12 shows the velocity from the KMCO 1.0 degree elevation scan at 2212 UTC on 12 

February 2014. The radar locations are indicated by yellow circles. Figure 13 shows the velocity 

KMCO

KMLB
28

from the KMLB 1.3 degree elevation scan at 2211 UTC, the closest KMLB scan in time and 

space to the KMCO scan in Figure 12. 

Figure 12. The KMCO velocity at 2212 UTC 12 February 2014, 

elevation angle 1.0 degrees. The yellow circles show the locations 

of the KMCO and KMLB radars. 

Figure 13. As in Figure 12, but for the KMLB velocity at 2211 

UTC, elevation angle 1.3 degrees. 

Figure 14 shows the 2211 UTC merged velocity field at 3 km. The text at the bottom of the 

image states that this is merged aliased velocity, but the AMU also used de-aliased velocity with 

the same results. The data field is uniformly purple, in the RF range of the scale at the top. The 

pattern of black concentric rings around KMCO is unique to this height and time, other heights 

and times exhibit different patterns of black rings and purple background. 

KMLB

KMCO

KMLB

KMCO
Figure 14. The KMCO and KMLB merged velocity at 2211 UTC 

12 February 2014, height of 3 km. 

 

KMLB

KMCO
30

5 Conclusions 

The AMU was tasked by the 45 WS and NWS MLB to develop a dual-Doppler display using 

data from three local Doppler radars and freely available software to derive the wind field over 

east-central Florida and the KSC/CCAFS area. A display of the low-level horizontal wind field to 

reveal areas of high winds or convergence would be a valuable tool for forecasters in assessing 

the timing of high winds impacting operations, or convection initiation and subsequent lightning 

occurrence. This is especially important for areas where no weather observation platforms exist. 

The wind fields would also be used to initialize a local mesoscale numerical weather prediction 

model to help improve the model forecast winds, convection initiation, and other phenomena 

important to space launch operations and public safety. 

5.1 Summary 

The Doppler radars include WSR, KMLB, and KMCO and the chosen software is WDSS-II. 

The AMU collected data from two significant weather cases: a tornadic event on 14 April 2013 

and a severe wind and hail event on 12 February 2014. For the 14 April case, the data were 

from WSR and KMLB. For the 12 February case, the data were from KMCO and KMLB. The 

AMU installed WDSS-II on a Linux PC, then processed and QC’d the radar data for display and 

analysis using WDSS-II tools. Because of issues with de-aliasing the WSR velocity field, the 

AMU did not use data from this radar in this study and only analyzed the 12 February case. 

Merging the data to create the dual-Doppler analysis involved several steps. The first was to 

define the 3-D grid over which the analysis would take place and create grid files that the 

merger tools could access. The merger itself required that a simulator tool be run in the 

background to access the data from both radars, reorder it according to time, then create output 

for the merger tool to access. The AMU ran the simulator and merger tools in separate terminal 

windows according to WDSS-II instructions, creating the merged reflectivity first as those data 

are needed as input for the velocity merger. For the archived data in this task, the 

simulator/merger tool combination had to be run separately for the reflectivity and velocity 

mergers. In real-time operations, one instance of the simulation tool will run in the background 

for both mergers, all taking place in separate terminal windows. 

The AMU was successful in creating a merged reflectivity field, which was critical to the 

success of creating a merged velocity field. However, the AMU was unable to replicate the 

results in Lakshmanan (2006) for a merged velocity field with wind barbs. The AMU researched 

the WDSS-II forum for discussions on similar issues, asked questions on the forum, and tested 

different options and values in the merger tool with no success. 

5.2 Using WDSS-II 

Installing and running the WDSS-II software requires a working knowledge of the Linux OS. 

Anyone who wants to use this software package should get Linux training if not already 

knowledgeable. To learn how to install and run WDSS-II and run the tools, the AMU consulted 

resources on the WDSS-II website, http://www.cimms.ou.edu/~lakshman/WDSS2/, including 

x discussion forum (http://forum.nssl.noaa.gov/viewforum.php?f=1), 

x training modules (http://www.cimms.ou.edu/~lakshman/WDSS2/w2training.shtml), 

x tools (http://www.cimms.ou.edu/~lakshman/WDSS2/algdoc.shtml), 

x scientific articles (http://www.cimms.ou.edu/~lakshman/WDSS2/papers.shtml), and 

x other links found on the WDSS-II home page in the left column (Figure 15). 
Figure 15. The top portion of the WDSS-II home page. The links with information on how to 

install and use WDSS-II are in the left column under the Documentation link. 

The discussion forum was the most helpful of all the resources. To post questions, the AMU 

had to register and receive a username and password from the moderator. Searching the 

discussion database does not require login. The training modules were helpful, but several have 

out of date information and others are more focused on the network at OU. The documentation 

for the tools was limited. Each option is explained, but many explanations require more in-depth 

knowledge of the system to fully understand them. The scientific articles do not go into detail on 

how to use WDSS-II, but they provide good information about the science behind the system 

and how it can be used. The AMU did not find resources outside of the WDSS-II website with 

detailed explanations on how to use the system. 

5.3 Recommended Future Work 

Developing a dual-Doppler wind field was the main goal of this task, but that was not 

accomplished. It could be an issue of not using the correct options or the correct value for the 

options used, or there could be issues with the radar data. 

The AMU is presenting the results of this task at the National Weather Association 39th 

Annual Meeting in October 2014. There could be other WDSS-II users present that could 

provide assistance in conducting this analysis. Since WDSS-II functionality favors WSR-88D 

radars, perhaps a merger between two of these radars could be tested to see if a velocity field 

can be produced. The baseline between WSR-88Ds is too large for a meaningful analysis, but if 

it works it would show that the issue is with the KMCO radar data. The AMU could then focus on 

the radar data and determine how it needs to be modified to produce a successful merged wind 

field. Finally, there is a follow-on AMU task to install the operational version of WDSS-II in the 

NWS MLB office. This will provide more opportunities to try different options and input values in 

order to create a merged wind field from KMCO and KMLB. 
32

Appendix: WDSS-II Setup and Use Details 

Download and Setup (Section 3.1) 

The download instructions for the WDSS-II software package are in section 3.1, which is a 

.tgz file. Specific and easy-to-follow instructions for installing WDSS-II with this file are on the 

webpage www.cimms.ou.edu/~lakshman/WDSS2/installation.shtml under the title “Installation” 

near the top of the page. There are also instructions for setting the environment variables in the 

.bashrc file that exists in the home directory on a PC with a Linux OS. The final version of the 

.bashrc file is in Figure . 

Figure 1. Content of the .bashrc file. 

To get the missing graphics libraries, type “yum provides */libgtkglext*” to search for the 

appropriate library files. Once found, use “yum install <librarypackagename>” to install the 

libraries. Once installed, type “wg” in a terminal window to open the WDSS-II display. If there is 

an error, it is likely the graphics driver. For the AMU PC, Mr. Magnuson had to update the Linux 

kernel, disable the nouveau graphics driver, and install the Nvidia graphics driver in order for the 

WDSS-II display to work. 

Data Processing (Section 3.2) 

The data files collected from the radars needed to be processed and converted to netCDF, 

the format used by WDSS-II. Descriptions of the tools to do this and other analyses in WDSS-II 

are on the Tools webpage: www.cimms.ou.edu/~lakshman/WDSS2/algdoc.shtml. 

KMLB Data Processing 

The AMU converted the KMLB data directly into netCDF format using the command 

ldm2netcdf -i <input directory> -o <output directory> -s KMLB -p 2014 -a -1 -D --verbose 

where 

x <input directory> is the full pathname of the directory containing the Level-II data, 

x <output directory> is the desired directory for the output, which must exist beforehand, 

x -s identifies the four-letter station name, 

x -p identifies a pattern common in all filenames that need to be processed, 
x -a takes no arguments and indicates the archived files will be read on startup, 

x -1 takes no arguments and indicates the program will run only once since it is not 

operating in real time, 

x -D de-aliases the velocity data, and 

x --verbose outputs verbose debugging information. 

This command works for WSR-88D data that have been archived at NCDC. For data collected 

directly from the local radar system, add the -L option to the ldm2netcdf command line. This 

option allows the command to read data files that are zipped radial-by-radial. 

The de-aliasing algorithm will work more accurately if a file containing a vertical profile of the 

winds observed near or during the radar data period is available for ldm2netcdf. The user 

creates this file for each case using sounding or profiler data available at the time. The name of 

the file must be “input.snd” and must be in the same directory in which ldm2netcdf is executed. 

The first line contains the number of data levels in input.snd, the second line contains the height 

of the radar in feet, and the following lines contain the observations with height in feet and 

1,000-ft intervals, direction in degrees, and speed in knots as in the example for the 15 April 

2013 case and KMLB: 

59 

120 

1000 162 20 

2000 178 17 

3000 184 17 

6000 202 18 

7000 205 17 

...

61000 249 10 

These data were from the 915- and 50-MHz profilers since no sounding was available on 15 

April. In this case, there were 59 data levels with two missing at 4,000 and 5,000 ft. The 

program interpolates through these missing data points and outputs a file named “ewt_table” 

containing the wind speeds converted to ms-1 and separated into u and v components. The dealiasing algorithm will use these data as a first-guess wind profile. 

KMCO and WSR Location Information 

The AMU had to prepare configuration files before running the algorithms to process the 

KMCO and WSR data files. The first step was to enter the location information for both radars in 

WDSS-II’s radarinfo.xml file. This file can be found in the directory 

/home/.../WDSS2/w2config/misc

where “...” is the user’s directory. The site information for KMLB is in the original file provided 

with WDSS-II. At a minimum, the entries include the radar name, a user-supplied site name, 

latitude and longitude location, and height of the radome above sea level in meters. The AMU 

entered the information for the WSR in the “Military Radars” section as 

<radar name="PAF" site="Eastern Range"> 

<location lat="28.3938" lon="-80.9509" ht="47.9"/> 

</radar> 

TDWR information also requires the magnetic offset and the radar frequency. The AMU entered 

the information for KMCO in the “TDWR for FAA Tech Center” section as
34

<radar name="MCO" site="Orlando International" magnetic_offset="6W" frequency="5640"> 

<location lat="28.3437" lon="-81.3257" ht="51.5"/>> 

</radar> 

The magnetic offset changes slowly over time and should be checked and updated when 

needed. The AMU used the website http://magnetic-declination.com/ to get the value for 

Orlando. The magnetic offset option in the file does not take decimals, so the AMU rounded the 

value, which is currently 6.1° west. 

KMCO and WSR VCP Files 

Files for the WSR-88D VCPs came with the WDSS-II build, but there were none for KMCO 

or WSR. Therefore, the AMU created one file each for the default WSR VCP, and the two 

KMCO VCPs shown in Table 1. The WSR VCP file is named vcp4513 and the two KMCO VCP 

files are named vcp203 and vcp204 for VCP90 (Monitor) and VCP80 (Hazardous), respectively. 

Each file contains some header information, then a list of the elevation angles in the order they 

are scanned. The first element is the VCP number, the next is a logical statement of whether the 

radar is a WSR-88D followed by another logical statement of whether it is a clear-air VCP, the 

final is the time in seconds to go through a complete volume scan. The following text is the 

summarized content of the vcp4513 file showing the header, first and last elevation angles, and 

“...” representing the intermediary angles. 

<vcp number="4513" isNexrad="false" isClearAir="false" totaltime="170"> 

<angle>0.20</angle> 

...

<angle>1.80</angle> 

</vcp> 

The TDWR VCPs have an extra logical element, named “canCache”, indicating whether a radar 

can change its VCP quickly. It is true for the TDWRs. The following two text groups are the 

summarized content of vcp203 and vcp204, respectively, showing the header, first and last 

elevation angles, and “...” representing the intermediary angles.

<vcp number="203" isNexrad="false" isClearAir="true" canCache="true" totaltime="360"> 

<angle>0.3</angle> 

...

<angle>60.0</angle> 

</vcp> 

<vcp number="204" isNexrad="false" isClearAir="false" canCache="true" totaltime="360"> 

<angle>0.3</angle> 

...

<angle>0.3</angle> 

</vcp> 

The AMU will provide these files to NWS MLB for the follow-on task. 

WSR Data Processing 

The AMU processed the WSR data using the command 

sigmetIngestor -i <input directory> -o <output directory -s PAF -p PAF -a -1 -b 1 -v 4513 -k 

where 

x <input directory> is the full pathname of the directory containing the Level-II data, 

x <output directory> is the desired directory for the output, which must exist beforehand, 
x -s is the four-letter station name, 

x -p is a pattern common in all filenames that need to be processed, 

x -a takes no arguments and indicates the existing archived files will be read on startup, 

x -1 takes no arguments and indicates the program will run only once since it is not 

operating in real time, 

x -b designates the beamwidth of 1° for the WSR, 

x -v specifies the VCP number to use, and 

x -k will stop the algorithm from deleting the archived files. 

The data in the output directory were in the format needed for ingest into ldm2netcdf. The 

AMU then converted the sigmetIngestor output to netCDF format using the command 

ldm2netcdf i <input directory> -o <output directory -s PAF -p PAF -a -1 –verbose 

where the input directory is the output directory for the sigmentIngestor command, and the 

output directory must exist beforehand. The options are the same as in the ldm2netcdf

command for the KMLB data except for the –D de-alias option. The reasoning for excluding -D 

is explained in the main text. 

KMCO Data Processing 

The AMU processed the KMCO data using the command 

tdwrLogIngest -i <input directory> -o <output directory -s MCO -p .log 

where 

x <input directory> is the full pathname of the directory containing the Level-II data, 

x <output directory> is the desired directory for the output, which must exist beforehand, 

x -s is the radar name, 

x -p is a pattern common in all filenames that need to be processed, 

The data in the output directory were in the format needed for ingest into ldm2netcdf. The 

AMU then converted the tdwrLogIngest output to netCDF format using the command 

ldm2netcdf i <input directory> -o <output directory -s MCO -p MCO -a -1 –verbose 

where the input directory is the output directory for the tdwrLogIngest command, and the output 

directory must exist beforehand. The options are the same as in the ldm2netcdf command for 

the KMLB data except for the –D de-alias option. The reasoning for excluding -D is explained in 

the main text. 

Convert ldm2netcdf Output 

The ldm2netcdf tool produces directories for every radar parameter and a directory named 

“code_index.fam” that is used as input (-i) to other tools and the GUI. The WDSS-II tools 

assume that this directory, and all directories with the *.fam extenstion, represents real-time 

data and will not exit upon completion. It must be converted to an xml file that WDSS-II will 

recognize as archived data. To convert the code_index.fam directory to an xml file, the AMU 

used the tool replaceIndex in the following command: 

replaceIndex -i <home/.../code_index.fam> -o <home/.../output code_index.xml>

where 
36

x <home/.../code_index.fam> includes the full pathname of the directory containing the 

code_index.fam directory, and 

x <home/.../code_index.xml> is the output xml file with the same full pathname as 

code_index.fam. 

Reflectivity QC 

The AMU ran the WDSS-II QC tool, “w2qcnn”, for the KMLB and KMCO data sets. The 

WSR system has a routine that QC’s the reflectivity data in real-time and outputs both the raw 

and QC’d reflectivity. The AMU used the following command to QC the reflectivity data: 

w2qcnn -i <home/.../code_index.xml> -o </home/...> -u -R <gate spacing x beamwidth x range> 

where 

x <home/.../code_index.xml> includes the full pathname of the xml file created by 

replaceIndex, 

x <home/...> is the same pathname for the directory containing the code_index.xml file,

x -u QC’s the data scan by scan,

x -R for KMLB is “-R 0.25x0.5x460”, and 

x -R for KMCO is “-R 0.15x0.5x460”. 

Velocity De-aliasing 

The TDWR system has a de-aliasing algorithm and transmits both the aliased and dealiased velocities, the latter called Conditioned Velocity, so this data set did not need to be dealiased. The AMU de-aliased the KMLB data using the -D option in ldm2netcdf, which is the 

recommended method for de-aliasing WSR-88D data in WDSS-II. The AMU also used the -D 

option in the ldm2netcdf command for the WSR data, but the values output were not correct. 

The WDSS-II developers recommend using the dealias2d tool with the data output from 

ldm2netcdf for non-WSR-88D radars. The AMU used the following input to dealias2d: 

dealias2d -i <home/.../code_index.xml> -o <home/...> 

where 

x <home/.../code_index.xml> is the input file including the full pathname of the xml file 

created by replaceIndex, 

x <home/...> is the output directory, which is the same directory containing the 

code_index.xml file, and 

x the ewt_table tile created by the ldm2netdf command for the KMLB data is copied into 

the same directory from which dealias2d is run. 

The results were similar to using the -D option in ldm2netcdf. A discussion of this issue with 

images is in section 3.2.2. Given this inability to properly de-alias the WSR data and other 

communication issues, the AMU did not use the WSR data in the dual-Doppler analysis. 

Data Display (Section 3.3) 

After processing, data from all three radars can be displayed in the WDSS-II GUI. The first 

step is to issue the wg command. Figure 5 in section 3.3 shows the initial display and describes 

the first few steps to load the data. 
Initial Display 

After clicking the Browse... button in the initial dialog box, a new dialog box is displayed with 

a list of directories on the left and a list of files and directories in the highlighted directory on the 

right (Figure 2). The user navigates to the directory containing the code_index.xml file of the 

radar data desired for display, clicks on the name of the file in the right column, and then clicks 

OK in the lower right. This closes the new dialog box and returns control to the initial dialog box 

(Figure 3). 

The full data path of the chosen data file is displayed in the URL text box in the New Source 

section of the initial dialog box. The user provides a name for the data set in the Name text box. 

In this case, the name is Feb12-KMCO, indicating the data are from KMCO during the 12 

February severe weather event (section 2.1). Using the default All in the History drop-down 

menu will load all the files in the directory. The drop-down list provides choices for the number 

of times to load. When all choices are made, the user clicks the Add button, and the Sources

section in the control area is populated with information about the radar data, as in Figure 4. 

Figure 2. The new dialog box displayed after clicking the 

Browse... button on the initial dialog box (section 3.3, Figure 5). 

The chosen directory is surrounded by the red box, the desired 

code_index.xml file is highlighted in blue on the right side. 
38

Figure 3. The initial dialog box (section 3.3, Figure 5) showing 

the chosen input file in the URL text box and the user-supplied 

name in the Name text box. 

The Sources section in Figure 4 displays the loaded radar data parameters to choose for 

display (compare with section 3.3, Figure 5). The left column contains the radar products such 

as velocity and reflectivity, the middle column contains the available elevation angles, and the 

right column contains the date and time of each scan. The user chooses the parameter, 

elevation angle and time to display. In this example, the QC’d reflectivity from the 0.3° elevation 

scan at 213527 UTC is displayed. 
Figure 4. The WDSS-II display showing KMCO data on 12 February 2014 at 213527 

UTC. The Sources section displays the loaded radar data parameters to choose for 

display. The left column contains the radar products, the middle column contains the 

elevation angles, and the right column contains the time of each scan. 

Map Background 

Figure 4 lacks a map background. In the control area at the bottom of the GUI, click the 

Maps tab to view available maps. The initial setup contains one map named Earth that is similar 

to an out-of-focus Google Earth map. Figure 5 shows this map overlain with the same data as in 

Figure 4. This is obviously not desirable. A map background showing clear state and county 

borders would be more useful. 
40

Figure 5. WDSS-II with the map background that comes with the software. The data are 

the same as in Figure 4, but zoomed out. 

To get a map background with state and county borders, the AMU followed several steps 

found in the WDSS-II forum under the topic “Where to get background map shapefiles?”: 

x Created a directory named w2config in the home directory. 

x Created a directory named shapefiles in the new w2config directory. 

x In the shapefiles directory, created a directory for each type of map named states, 

Counties, and Cities. 
x On website http://www.nws.noaa.gov/geodata, downloaded the zipped files for the state, 

county, and city boundaries, and put them in their respective directories created in the 

previous step. 

x Unzipped the files within each directory. 

x Created a directory named maps in the w2config directory created in the first step. 

x Created a file named maps.xml (Figure 6) containing information about the shapefiles 

needed by WDSS-II. 

x Edited the .bashrc file in the home directory adding another directory path to the new 

w2config directory for the W2_CONFIG_LOCATION parameter. Appendix Figure 1 has 

this necessary addition. 

Figure 6. Contents of the maps.xml file in the w2config/maps directory. 

x Restarted the WDSS-II GUI and clicked on the Maps tab in the control area. 

x Clicked on the Add... button and chose a map by clicking on the name in the Add New 

Map dialog box (Figure 7). 

x Clicked Add in the lower right of the Add New Map dialog box. The dialog box 

disappears, the name of the new map file appears under Map Name in the Maps

section, and the new map background is displayed (Figure 8). 

Figure 7. The Add New Map dialog box is displayed after clicking on Add... in the 

Maps menu. The State map is highlighted. 

The AMU added the state map, then the county map. The cities map was too busy and 

created a cluttered background to the radar data. To remove the Earth map display, the AMU 

clicked on Earth in the Map Name list and checked the Hide box to the left of Map Name in the 

Maps tab section. This left the state and county boundaries as the map background. To delete a 

map, click on the map then click the Delete button to the left of the Map Name list. 
42

Figure 8. The WDSS-II GUI displaying the state and county boundaries using the same 

data and zoom level as Figure 6. The Earth map is highlighted to show how to eliminate 

a map background without deleting it from the list by checking the box next to Hide in 

the Maps section. 

Choose Data to Display 

Section 3.3 of the report and Appendix Figure 2, Figure 3, and Figure 4 describe how to load 

and display one data set, specifically the 12 February 2014 KMCO QC’d reflectivity data at 0.3° 

elevation. Following the same procedure described in the Initial Display section above, more 

than one data set can be loaded in WDSS-II through the Sources tab. Figure 9 shows another 

tab added in the Sources content for KMLB data on 12 February. The highlighted product is the 
0.5° ReflQC (QC’d reflectivity) at 213306 UTC, the time closest to the KMCO data in section 

3.3, Figure 6. 

Figure 9. Similar to Figure 6 in section 3.3, except the Sources tab contains a second 

tab named “Feb12-KMLB”. The highlighted items in each list determine what is 

displayed: the KMLB 0.5° QC’d reflectivity at 213307 UTC.

Once all three parameters of product, elevation angle, and time are chosen from one of the 

data source tabs in the Sources tab section, the data are displayed in the display area of the 

GUI, and the product is added to the text box in the Products tab section. Figure 10 shows the 

Products tab contents after choosing QC’d reflectivity and de-aliased velocity data from the 12 

February KMCO and KMLB data. Information about the data is in the top text box. The choices 

along the left side of the Products tab area allows the user to hide the data, show only the 

selected data (no overlay with other data), display range rings and azimuth lines, delete the data 

set, or choose a filter for the data. The text box to the right of this area shows the products that 
44

were chosen for display in the Sources tab. Note there are more than one. The area to the right 

of the text box controls which elevation angle and time is displayed. The forward (right) and 

backward (left) time buttons are outlined in red, and the upward (top) and downward (bottom) 

elevation angle buttons are outlined in green. The values of the next time forward or backward 

and of the next elevation up or down are displayed on the button. Since the lowest elevation 

angle of 0.5° is being displayed in Figure 10, the downward button shows the highest elevation 

angle of 19.5° from the previous volume scan. The buttons to the right if these display the last 

scan in the data set of the value shown on the button. The Display and Speed boxes below 

these controls allow the user to add a component of speed from a specific direction to the 

velocity data. 

Figure 10. Similar to Figure 9, except for the de-aliased velocity at 213324 UTC and 

showing the Products tab contents. The buttons with a red box control the time 

displayed and the buttons with a green box control the elevation angle displayed. 
Data Merger Grid Setup (Section 4.1) 

The createCache tool must be run in the home directory. It creates a directory named 

.w2mergercache that contains the grid information accessed by the merger tools. The AMU 

used the following input to createCache for KMCO: 

createCache -i MCO -t “29 -81.5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” -v “203 204” --verbose 

and for KMLB: 

createCache -i KMLB -t “29 -81.5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” –verbose 

where 

x -i identifies the radar name, 

x -t defines the northwest corner lat/lon and top height in km of the grid, 

x -b defines the southeast corner lat/lon and bottom height in km of the grid, 

x -s defines the grid horizontal resolution in fractions of a degree and vertical resolution in km, 

x -v defines the VCP(s) used by the radar (not needed for WSR-88D radars), and 

x --verbose outputs verbose debugging information. 

Reflectivity Data Merger (Section 4.2) 

As stated in section 4.2, w2simulator must be started before w2merger. The AMU used the 

following input to w2simulator for the reflectivity merger: 

w2simulator -i “<home/...KMCO/code_index.xml> <home/...KMLB/code_index.xml>”

-o <home/.../w2sim> -c -r 1 -b 20140212-2210 -e 20140212-2300 --verbose 

where 

x “<home/...KMCO/code_index.xml> <home/...KMLB/code_index.xml>” includes the full 

pathname of the xml files created by replaceIndex for both radars, 

x <home/.../w2sim> is the directory for the w2simulator output, which can be any name 

chosen by the user, 

x -c processes only the times common to both radar data sets, 

x -r indicates multiples of processing speed, where 1 equates to real-time, 

x -b is the user-selected begin time of the data in the form YYYYMMDD-hhmm, 

x -e is the user-selected end time of the data in the same form as –b, and 

x --verbose outputs verbose debugging information. 

The elements -b and -e are not required, but are helpful to use when testing algorithms. A 

shorter time period takes less time to process and allows evaluation of the output sooner than 

processing the whole data set. 

Before hitting “Enter” to run the w2simulator tool, the AMU opened another terminal 

window on the Linux POC and typed the w2merger command line: 

w2merger -i “<home/.../w2sim/index_0.fam <home/.../w2sim/index_1.fam>”

-o <home/.../w2mrg> -r -t “29 -81.5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” 

-I ReflectivityQC -C 7 -3 -p 0.5 –verbose 

where 
46

x “<home/.../w2sim/index_0.fam> <home/.../w2sim/index_1.fam>” are the directories 

created by w2simulator,

x <home/.../w2mrg> is the directory for the w2merger output, which can be any name 

chosen by the user,

x -r indicates the algorithm is running in real-time even though it is an archived case,

x -t, -b, and -s are as for createCache,

x -I states to use the ReflectivityQC product as input (default is Reflectivity), 

x -C determines the way data values are combined if they overlap in space and time where 7 

is the default method, 

x -3 writes a single lat/lon/height grid with all the data, 

x -p is the round-off precision, and 

x --verbose outputs verbose debugging information.

The AMU chose these elements for the w2merger command because they were recommended 

on the WDSS-II forum. 

Once both commands were typed in separate terminal windows, the AMU executed the 

w2simulator command. As soon as the text “You can start your algorithms now” displayed in 

the w2simulator window, the AMU executed the w2merger command in the other terminal 

window. 

The w2simulator command stopped and exited because it used .xml files as input, but the 

w2merger command did not exit since its inputs were the index_*.fam directories output by 

w2simulator (see Convert ldm2netcdf Output section above). When the w2simulator

command had exited and the w2merger command had stopped, the AMU issued a Ctrl-C 

command in the w2merger window to force the command to exit. 

The w2merger output is a code_index.fam directory that should be converted using 

replaceIndex before displaying. Once converted, follow the directions outlined in the Data 

Display sections above. An example of the merged reflectivity field is shown in section 4.2 

Figure 11. 

Velocity Data Merger (Section 4.3) 

For the velocity merger, w2simulator must be executed again and run in conjunction with 

w2merger just as for the reflectivity merger. Before executing the commands below, run 

replaceIndex on the home/.../w2mrg/code_index.fam directory following the directions in the 

Convert ldm2netcdf Output subsection in the Data Processing section above. The AMU used 

the following input to w2simulator for the velocity merger: 

w2simulator -i “<home/...KMCO/code_index.xml> <home/...KMLB/code_index.xml> 

</home/.../w2mrg/code_index.xml>” -o <home/.../w2sim> -c -r 1 

-b 20140212-2210 -e 20140212-2300 --verbose 

where 

x “<home/...KMCO/code_index.xml> <home/...KMLB/code_index.xml>

</home/.../w2mrg/code_index.xml>” includes the full pathname of the xml files created 

by replaceIndex for both radars as for reflectivity and the xml file from the w2merger

reflectivity output, 
x <home/.../w2sim> is the directory for the w2simulator output, which can be any name 

chosen by the user, 

x -c processes only the times common to both radar data sets, 

x -r indicates multiples of processing speed, where 1 equates to real-time, 

x -b is the user-selected begin time of the data in the form YYYYMMDD-hhmm, 

x -e is the user-selected end time of the data in the same form as -b, and 

x --verbose outputs verbose debugging information. 

The elements -b and -e are not required, but are helpful to use when testing algorithms. A 

shorter time period takes less time to process and allows evaluation of the output sooner than 

processing the whole data set. 

Before hitting “enter” to run the w2simulator tool, the AMU opened another terminal window 

on the Linux POC and typed the w2merger command line: 

w2merger -i “<home/.../w2sim/index_0.fam> <home/.../w2sim/index_1.fam> 

<home/.../w2sim/index_2.fam>” -o <home/.../w2mrg> -r -t “29 -81.5 10” 

-b “27.5 -80.2 0” -s “0.009 0.009 0.5” -I Velocity -C 8 -3 -p 0.5 -z 

MergedReflectivityQC:all -Z <home/.../w2mrg/code_index.xml> --verbose 

where 

x “<home/.../w2sim/index_0.fam <home/.../w2sim/index_1.fam> 

</home/.../w2sim/index_2.fam> ” are the directories created by w2simulator,

x <home/.../w2mrg> is the directory for the w2merger output, which is the same as that 

for the reflectivity merger,

x -r indicates the algorithm is running in real-time even though it is an archived case,

x -t, -b, and -s are as for createCache,

x -I states to use the Velocity product as input (default is Reflectivity), 

x -C determines the way data values are combined if they overlap in space and time where 8 

is the method for velocity mergers, 

x -3 writes a single lat/lon/height grid with all the data, 

x -p is the round-off precision, 

x -z identifies the reflectivity data type, 

x -Z is xml file containing the merged reflectivity, and 

x --verbose outputs verbose debugging information.

The AMU chose these elements for the w2merger command because they were recommended 

on the WDSS-II forum. Due to the erroneous output as shown in section 4.3, the AMU tried 

other options and values that produced similar results. 

Once both commands were typed in separate terminal windows, the AMU executed the 

w2simulator command. As soon as the text “You can start your algorithms now” displayed in 

the w2simulator window, the AMU executed the w2merger command in the other terminal 

window. 

The w2simulator command stopped and exited because it used .xml files as input, but the 

w2merger command did not exit since its inputs were the index_*.fam directories output by 
48

w2simulator (see Convert ldm2netcdf Output section above). When the w2simulator

command had exited and the w2merger command had stopped, the AMU issued a Ctrl-C 

command in the w2merger window to force the command to exit. 

The w2merger output is a code_index.fam directory that should be converted using 

replaceIndex before displaying. Once converted, follow the directions outlined in the Data 

Display sections above. 

 
References 

Dolan, B., and S. Rutledge, 2007: An integrated display and analysis methodology for 

multivariable radar data. J. Appl. Meteor. Climatol., 46, 1196–1213, doi: 

10.1175/JAM2524.1. 

Huddleston, L., 2012: Dual-Doppler Feasibility Study. NASA Technical Memorandum TM-2012-

216310, Kennedy Space Center, FL, 24 pp. [Available online at science.ksc.nasa.gov/ 

amu/final-reports/dual-doppler-feasibility.pdf.] 

Roeder, W. P., and D. A. Short, 2009: The new weather radar for America’s space program: 

Scan Strategy Design, Preprints, 34th Conf. on Radar Meteorology, Williamsburg, VA, 

Amer. Meteor. Soc., P6.2. [Available online at 

https://ams.confex.com/ams/pdfpapers/154174.pdf.] 

Short, D., 2008: Radar Scan Strategies for the Patrick Air Force Base Weather Surveillance 

Radar, Model-74C, Replacement. NASA Contractor Report CR-2008-214745, Kennedy 

Space Center, FL, 29 pp. [Available from ENSCO, Inc., 1980 N. Atlantic Ave., Suite 830, 

Cocoa Beach, FL, 32931 and online at science.ksc.nasa.gov/amu/final-reports/radarscan-strategies-radtec.pdf.] 

Lakshmanan, V., A. Fritz, T. Smith, K. Hondl, and G. Stumpf, 2007: An automated technique to 

quality control radar reflectivity data. J. Appl. Meteor. Climatol., 46, 288–305, doi: 

10.1175/JAM2460.1. 

Lakshmanan, V., T. Smith, K. Hondl, G. Stumpf, and A. Witt, 2006: A real-time, threedimensional, rapidly updating, heterogeneous radar merger technique for reflectivity, 

velocity, and derived products. Wea. Forecasting, 21, 802–823, doi:10.1175/WAF942.1. 

WDSS-II links used in this task: 

x Home page: http://www.cimms.ou.edu/~lakshman/WDSS2/

x Discussion forum: http://forum.nssl.noaa.gov/viewforum.php?f=1

x Training modules http://www.cimms.ou.edu/~lakshman/WDSS2/w2training.shtml

x Tools: http://www.cimms.ou.edu/~lakshman/WDSS2/algdoc.shtml

x Scientific articles: http://www.cimms.ou.edu/~lakshman/WDSS2/papers.shtml
50

List of Acronyms 

3-D Three Dimensional 

45 SW 45th Space Wing 

45 WS 45th Weather Squadron 

AMU Applied Meteorology Unit 

CCAFS Cape Canaveral Air Force Station 

CentOS Community Enterprise Operating 

System 

CIMMS Cooperative Institute for 

Mesoscale Meteorological 

Studies 

CWA County Warning Area 

GSDO Ground Systems Development 

and Operations 

GUI Graphical User Interface 

IRIS Interactive Radar Information 

System 

KMCO MCO TDWR 

KMLB NWS MLB WSR-88D 

KSC Kennedy Space Center 

lat/lon latitude/longitude 

LSP Launch Services Program 

MCO Orlando International Airport 

NCAR National Center for Atmospheric 

Research 

NCDC National Climatic Data Center 

NWS MLB National Weather Service in 

Melbourne, Florida 

OS Operating System 

OU University of Oklahoma 

POR Period of Record 

QC Quality Control 

SLS Space Launch System 

SPG Supplemental Product Generator 

TDWR Terminal Doppler Weather Radar 

VAFB Vandenberg Air Force Base 

VCP Volume Coverage Pattern 

WDSS-II Warning Decision Support 

System--Integrated Information 

WSR 45 SW Weather Surveillance 

Radar 

WSR-88D Weather Surveillance Radar 1988 

Doppler 

 
NOTICE 

Mention of a copyrighted, trademarked or proprietary product, service, or document does not 

constitute endorsement thereof by the author, ENSCO Inc., the AMU, the National Aeronautics 

and Space Administration, or the United States Government. Any such mention is solely for the 

purpose of fully informing the reader of the resources used to conduct the work reported herein.