(1) Overview
Introduction
Atmospheric radars and lidars are designed to measure a variety of targets, including aerosols, cloud and precipitation particles, atmospheric molecules, and biological targets such as birds and insects. These instruments may be ground-based, mobile, shipborne, airborne, and spaceborne, scanning or vertical pointing. The observations help the weather and climate community address open questions about high-impact events such as severe weather, precipitation, pollution, and aviation safety.
As radar and lidar technologies evolve, the complexity and capabilities of the instruments increase, as does the size of the associated datasets. The research and scientific communities require tools that can effectively manage large amounts of specialized data and implement scientific algorithms that are reproducible. Hardware manufacturers and research institutions often use different raw data formats, which are often converted into a common data format to make software applications available for use and to facilitate data sharing. Raw radar and lidar data are often noisy, contain artifacts, have uncertain pointing angles, uncertain radial velocities due to aliasing, or are subject to interference. These issues must be addressed to facilitate the meaningful extraction of scientific information from the raw data. Good quality control and the filtering of artifacts are essential. The algorithmic processing of raw fields and the derivation of advanced products enhance the scientific impact. The resulting products can be used to answer many different research questions and may be assimilated into numerical weather models to improve forecasts. Display tools are crucial for visualizing data in real-time collection, validating quality control procedures, or for subsequent scientific analysis. The tools must be designed to span the full data life cycle from data collection to usable products, as illustrated in Figure 1. The Lidar Radar Open Software Environment (LROSE) ecosystem was developed with these needs in mind.
Figure 1
A schematic detailing the potential processing steps from radar and lidar data collection to final products or data visualization.
LROSE origins and development history
LROSE development has a long history, from the initial standalone applications and libraries to the cohesive package available today. Precursors to LROSE originated in storm tracking in support of a weather modification experiment in South Africa in the 1980s. The Thunderstorm Identification Tracking Analysis and Nowcasting (TITAN) application was developed to track storms during the experiment [1]. In the 1990s, development of TITAN moved to the then Research Applications Program (RAP), which is now the Research Applications Laboratory (RAL), at NSF NCAR in Boulder, Colorado. Subsequent funding was provided by the Federal Aviation Administration (FAA), the state government of Mexico, and the government of Taiwan. The TITAN system was expanded to support aviation forecasting and weather modification experiments. During this period, TITAN was converted from a FORTRAN code base to C++. Eventually, software development expanded beyond storm tracking to encompass other tasks within the radar and lidar data processing workflows.
Radar and lidar data are often in proprietary formats developed by commercial vendors or research institutions. Radx, a collection of open-source libraries and applications, was developed to read, write, and convert this polar-coordinate data. A standard data format (CfRadial [2]) was developed, to conform to the Climate and Forecast (CF)-compliant NetCDF format for radar and lidar data. CfRadial [2] was adopted by the World Meteorological Organization (WMO) as the standard format for data exchange (WMO refers to this as FM301). From 2012 to 2016, development was supported by base funding from NCAR’s Earth Observing Laboratory (EOL). In 2016 and 2021, EOL and Colorado State University received two rounds of funding from NSF to merge existing Radx applications and libraries and develop new applications into a cohesive software package under LROSE. Project goals were guided by feedback from a community workshop hosted by NSF in Boulder in 2012; top priorities from that workshop included an NCAR-centralized repository for applications, standardized packages and toolkits, and community training [3]. Over the course of the two funding periods, functionality and processing have been added, bugs have been addressed, and user training has been offered. Current development is focused on replacing legacy Graphical User Interface (GUI) applications and improving accessibility through hosting on cloud-based platforms via a Science Gateway.
For processing speed and efficiency, LROSE applications are mostly written in C++, which is statically typed and compiled. Like LROSE, other Open Radar Science projects including Py-ART [4], wradlib [5], BALTRAD [6], and Pyrad [7] process weather radar data, but use different implementation languages (e.g., Python, Java, and occasionally C). These projects provide tools for reading, manipulating, and visualizing data, but they also have different use cases and approaches.
LROSE users span a wide range of communities within weather and climate, from operational instrument providers in local and national government agencies to private sector instrument developers and the research community. LROSE tools form the software base for a number of NCAR instruments, and have enabled many NCAR and other atmospheric field campaigns internationally. The use of LROSE tools has been cited in studies on tropical cyclone inner-core dynamics and microphysical processes, dual-Doppler wind retrievals within severe convective storms in Spain, an hourly gridded rainfall product over O‘ahu, and improving quantitative precipitation estimates over Taiwan [8, 9, 10, 11, 12, 13, 14].
The LROSE code base is large, with complex interdependencies and libraries. Clean build and installation support is therefore essential. This manuscript describes the underlying architecture of the LROSE code base, including common data structures, metadata, and the organization of the applications. Commonly-used applications are described and sample output products are discussed. Finally, software testing, installation information, and operating system requirements are described.
Implementation and architecture
The majority of LROSE applications are written in C++, an object-oriented language. These are compiled into binary executables and packaged for installation on Mac OS X and Linux platforms. On Windows machines, LROSE can be installed using the Linux subsystem.
LROSE is organized into individual applications supported by specialized libraries. The applications generally run via the command line or are called from shell scripts. A handful of the applications have GUIs. For applications that process data in polar coordinates, the underlying code is generally based on the RadxVol class, which provides access to a common data structure. RadxVol mimics the structure of radar and lidar observations, a hierarchy of sweeps, rays, and data fields (Figure 2). A single point observation is referred to as a ‘gate.’ The raw fields are the so-called radar or lidar moments (e.g., reflectivity, velocity). A ray is a collection of gates that lie along a single radar beam in a particular direction. A sweep is the collection of rays collected as the instrument completes a rotation or scan (e.g., a full 360º rotation, a vertical slice, or a stationary pointing scan through time). The RadxSweep, RadxRay, and RadxField classes provide access to the underlying chunks of memory that contain the data arrays (Figure 2). Various functions can rearrange the pointers to enable speedy reading, updating, deleting, and writing of the data.
Figure 2
The RadxVol data structure, displaying one volume (top), sweep (middle), and ray (bottom). RadxVol is typically stored as a 1-D array. The RadxSweep, RadxRay, and RadxField pointers provide access to the individual sweeps, rays, and fields.
The RadxSweep, RadxRay, and RadxField classes manage their own specific metadata. In general, the metadata mimics that of the CfRadial format, including georeference data, correction factors, instrument parameters, and calibration information [2]. Other metadata includes start and end indices, sweep numbers, and radar operational variables such as pulse repetition frequency, scan rates, and fixed scanning angles.
Most LROSE applications follow a similar high-level code structure, with a main C++ file that serves as the entry point. Principal steps are to (a) initialize the application and set up signal handling procedures, (b) parse command line arguments, (c) read the application parameters from a configuration file, (d) read the input data files, (e) perform the specific task, (f) write results to output files, and (g) clean up (memory) and exit. LROSE applications can run in an archive mode where input files are predetermined, or in a real-time mode where new input files are read in as they arrive. The applications are long-lived and are designed to process many input files as a single instance, or remain running continuously in real-time mode. Some applications which originated outside of the initial NCAR development did not originally follow the standard design. For example, when the SAMURAI wind-retrieval application was integrated into the LROSE ecosystem, the main entry function was modified to conform with LROSE conventions, and the Radx libraries were integrated to read and write data.
Visualization applications in LROSE make use of raw X11 or Qt for creating GUIs. One display (Jazz) is a Java application using Swing. The displays can handle both archive and real-time operations. Some of the displays are migrating to Python. Moving GUIs to Python simplifies code development, makes the code accessible to a broader audience, and may promote community contributions and interoperability among open source projects.
Each LROSE application is configured using a detailed parameter file. This is a particular strength of the system, because these are self-documenting. As an application is developed, the parameters are specified and documented in a template file, using the Table-Driven Runtime Parameters (TDRP) system. A code-generation step (tdrp_gen) converts this filled-out template into a C++ class that is used to both read and write the parameter files. Since the documentation is built in during code development, this ensures that the information is kept up to date as modifications are made to the application. A subset of parameters for each application can be set on the command line, which allows for standard usage without a parameter file or as a way to override specific parameters set in the accompanying configuration file (i.e., the command line takes precedence over the configuration files).
Those LROSE applications that handle radar and lidar data in polar coordinates read and write CfRadial files. However, in order to integrate with analyses from non-radar data sets (e.g., models, satellite sensors), the polar data is interpolated onto grids in Cartesian coordinates. For these three-dimensional Cartesian grids, LROSE applications read and write using the community CF-standard NetCDF format or the internal NCAR-developed MDV format.
LROSE can be installed on servers and personal machines using a number of methods. Some users choose to build and install the applications from source. For Linux, the simplest method is to install from RedHat and Debian package files, using standard Linux package managers. For Mac OS X, the best method is to build and install using Homebrew. Substantial effort has been put into simplifying and improving the installation process. Full releases are prepared every 3–6 months. Work is underway to offer LROSE through conda-forge, which would expand support to Windows OS and streamline packaging for other operating systems. All of the existing software packages and source code are available for download from the LROSE GitHub repository.
The main code development is managed using GitHub, which supports version tracking, updated releases, and issue submission. The majority of the code is in the NCAR/LROSE-core repository, while the build and installation environment is managed in the NCAR LROSE-bootstrap repository. Software developers and users can enter issues, modify code, and submit pull requests via the LROSE-core repository. A separate GitHub repository is used for generating Digital Object Identifiers (DOIs), with the release information copied from the main code repository.
LROSE toolsets
For scientific users, higher-level applications are the building blocks of most LROSE processing workflows. Key LROSE applications are listed in Table 1 and the most commonly-used applications are described below. The applications can be classified into groups or toolsets: (a) Convert, (b) Grid, (c) Echo, (d) Quality Control (QC), (e) Wind, and (f) Display. There is also a more specialized group (g) that handles signal processing.
Table 1
List of principal LROSE applications and descriptions. Superscripts indicate the group(s) into which applications are classified: aConvert, bGrid, cEcho, dQC, eWind, and fDisplay.
| APPLICATION NAME(S) | CATEGORY |
|---|---|
| RadxPrint, RadxConverta, RadxBufra | Data inspection and format conversion |
| Radx2Gridb | Cartesian transformation |
| RadxKdpc, RadxPidc,d, RadxHcac | Particle and hydrometeor
identification based on fuzzy logic approaches |
| RadxRatec,d, RadxBeamBlockc, RadxQpec, PrecipAccumc, QpeVerifyc | Quantitative precipitation estimation |
| RefractComputec, CalcMoisturec, RefractCalib | Moisture field estimation |
| Eccoc | Convective-stratiform partitioning |
| TITANc, OpticalFlow, ctrec, StormInitLocation, ScaleSep, Tracks2Ascii, Tstorms2Xml | Storm analysis, nowcasting |
| RadxQcd, RadxFilterd, RadxDealiasd, RadxClutterd | Quality Control |
| RadxEvade, Vortrace | Single-Doppler retrievals |
| FRACTLe, SAMURAIe | Multi-Doppler retrievals |
| HawkEyef, CIDDf, Rviewf, TimeHistf, Jazzf, Emeraldf | Displays |
| RadxMergeFields, RadxMergeVols | CfRadial file manipulation |
| RadxDiffFields, RadxDiffVol, RadxStats | CfRadial file comparisons and statistics |
| Grib2toMdv, NetCDF2Mdv, NcGeneric2Mdv, Wrf2Mdv | Ancillary data format conversion |
| Mdv2SoundingSpdb, BomSounding2Spdb, CsuSounding2Spdb, SpdbQuery | Sounding extraction and conversion |
| RadarConst, RadarCal, SunCal, TsCalAuto, RadxClutMon, RadxSunMon | Calibration |
(a) The Convert applications deal with format conversion, of which the most popular tool is RadxConvert. LROSE supports read-access for over 25 raw formats and write-access for a small number of standard formats. Most frequently, RadxConvert converts raw instrument data into the CfRadial format [2], which is the standard data format adopted by the WMO and the cleanest approach for all LROSE applications using polar coordinates. For Cartesian data sets, LROSE provides an extensive list of applications that read and convert data sets into the CF-convention NetCDF format.
(b) The popular LROSE application Radx2Grid efficiently regrids polar data to Cartesian coordinates. Radx2Grid supports both bilinear interpolation and spatial filtering methods for regridding radar data.
(c) The Echo applications broadly analyze the radar fields (moments) and polarimetric variables to provide information on precipitation processes and storm characteristics. On the scale of individual gates, applications determine dominant precipitation particle type (e.g., RadxPid, RadxHca), estimate precipitation (e.g., RadxRate, RadxQpe, RateAccum), and calculate moisture from refractivity (e.g., RefractCompute, CalcMoisture). On larger spatial scales, LROSE applications partition echoes in convective and stratiform precipitation (Ecco [15]) and identify and track storms (TITAN [1]).
(d) A number of LROSE tools are available for quality control, including the aforementioned RadxPid and RadxRate, which can censor gates where the NCAR fuzzy logic particle identification algorithm [16] indicates that the echo is likely not meteorological. Other QC tools exist for censoring and filtering data, removing residual ground clutter, and performing radar calibration (e.g., RadxQc, RadxFilter, RadxClutter). Finally, specialized display applications HawkEdit and solo3 [17] allow for manual user editing, along with script-based editing. These data editing applications require expert judgment for removing bad signal and non-meteorological data, though efforts have been made to develop standardized, reproducible workflows using rules-based thresholds for removing bad data [17].
(e) LROSE has sophisticated tools in its Wind toolset, which can perform single- and multi-Doppler wind analyses and retrievals. The single-Doppler applications estimate large-scale wind patterns and tropical cyclone characteristics (RadxEvad, VORTRAC). The multi-Doppler tools provide estimates of the three-dimensional wind field (FRACTL, SAMURAI [9, 22]). SAMURAI, in particular, has undergone a number of improvements, including code optimization and the addition of the capability for retrieval over terrain [9, 18]. Work is underway to integrate thermodynamic retrievals into the main SAMURAI code base [19].
(f) Finally, radar and lidar data can be displayed using several LROSE tools. HawkEye is an interactive GUI that displays radar or lidar data in the native instrument coordinates, supporting straightforward toggling between different fields, elevation angles, and files (Figure 3). This is particularly useful as an engineering data quality and monitoring tool. The legacy Cartesian Interactive Data Display (CIDD) display and the forthcoming Lucid display that are still under development integrate disparate polar and Cartesian data sets onto a single display for real-time field project and scientific analysis purposes. CIDD and LUCID are useful for comparing radar data with coincident satellite data or model output. The JAZZ display has similar capabilities to CIDD, but is a Java-based application. All of these display tools handle both real-time and archive data modes.
Figure 3
Screenshot of HawkEye application displaying raw radar data in polar coordinates.
(g) The above toolsets provide the functionality most commonly used by researchers and operational users. In addition, LROSE has a large number of sophisticated applications for low-level signal processing procedures that operate on the low-level I/Q time series data generated by radar digital receivers. The functionality includes clutter detection and filtering, range and velocity unfolding, calibration, solar tracking, and the computation of moments from the time series.
Software quality control
Parts of LROSE software are legacy code from the 1980s. While the code has been tested since inception, the development was prior to the mainstream use of automated testing procedures. Some of the new software has automated unit tests as well as functional and system testing procedures. LROSE has a broad community that quickly notifies the team of issues.
To support the use of LROSE applications, documentation is hosted on the LROSE GitHub repository, the LROSE Wiki, and within the application parameter files. The installation procedures for various operating systems are directly hosted on GitHub along with the software. Links to the installation guides are also provided on the main Wiki page. To test that the software was installed correctly, we recommend users run an application using the -h flag to print the command line options (e.g., RadxPrint -h) to the terminal. Another simple test is to run RadxPrint on a raw radar file (e.g., from NEXRAD) to 1) test whether the installation process worked and 2) confirm that LROSE can read a data file.
Documentation for the LROSE applications falls into two categories: 1) describing how to run each application and 2) describing the scientific parameters that affect the analysis. The LROSE Wiki hosts a short ‘Quick Start’ tutorial that provides a link to a sample file and walks users through the usage of a few basic applications. Command line options for each application can be found using the help flag (–h). The LROSE parameter files for each application are quite detailed: they describe each parameter, including the required units or methods. When a specific algorithm has been implemented from a publication, the citation is included. Finally, the LROSE Wiki has a dedicated page for the most commonly used applications; these pages describe what each application does, any relevant scientific background, prerequisites, and key parameters to consider in the parameter file.
(2) Availability
Operating system
LROSE has been tested on:
Linux: Alma 8/9/10, Rocky 8/9, Fedora 40/41/42, Debian 11/12, Ubuntu 20/22/24, RedHat 8/9, Oracle 9, and Suse 15.
AlmaLinux 10 and RockyLinux 10 are missing full support for armadillo, so vortrac will not build on these OSs. Suse is lacking support for armadillo and eigen3, so FRACTL, VORTRAC, and SAMURAI are not available.
Mac: Intel and M1/M2 machines (Sonoma, Sequoia).
Windows: 11.
Programming language
C++17, Fortran 95
Additional system requirements
Systems with 16 GB memory, 2–4 TB disk space, and modern fast processors are recommended.
Dependencies
When installing from Linux packages or Homebrew, the package managers will handle dependencies.
For source compilation, the following items are required: gcc, gxx, gfortran, Python version 3, CMake 3.15, X11, Qt5/Qt6, fftw, eigen, flex, netcdf, hdf5, szip, pkg-config, geographiclib, armadillo, libomp, and libzip. The CMake build scripts will check for installed libraries for compatibility.
List of contributors
Michael Dixon, Brenda Javornik, Ting-Yu Cha, John Dennis, Isabel Suhr, Jian Sun, Cena Brown, Chris Burghart, Nancy Rehak, Adam Karboski, Gary Cunning, David Albo, Ulrike Romatschke, Gary Granger, and Wen-Chau Lee, National Center for Atmospheric Research, Boulder, CO
Michael Bell, Bruno Melli, Nick Katsampes, Jeff Smith1, Alexander DesRosiers2, Jennifer DeHart, Isaac Schluesche, Colorado State University, Fort Collins, CO
Mark Curtis, Commonwealth of Australia, Bureau of Meteorology
Brant Smith, University of Colorado, Boulder
Shivakrishna Vasireddy3, University of California, Irvine, Irvine, CA
John Wong, The Weather Company
Ammar Siddiqi4, Texas A&M University, College Station, TX
Current affiliations: 1OptTek Systems, Boulder, CO, 2U.S. Naval Research Laboratory, Monterey, CA, 3Amazon Web Services, 4SAP Labs, LLC.
Software location
Archive
Name: Figshare
Persistent identifier: https://doi.org/10.6084/m9.figshare.30251821
Licence: MIT
Publisher: Michael Dixon and Brenda Javornik
Version published: Laguna
Date published: 06/10/25 (Laguna)
Code repository
Name: GitHub
Identifier: https://github.com/NCAR/lrose-core
Licence: BSD
Date published: 11/08/25
Language
English
(3) Reuse Potential
LROSE is widely used by the international weather radar scientific research community. It is used to prototype solutions that are implemented on the US NEXRAD weather radar network. It is in operational use in a number of countries, including South Africa, Australia, Brazil, the UAE, the Philippines, Egypt, and Taiwan. It is widely used by the international weather modification community.
The LROSE development team collaborates with other developers in the Open Radar Science community, including but not limited to Py-ART, PyDDA, wradlib, Pyrad, and BALTRAD, in both application development and community workshops [4, 5, 6, 7, 20, 21]. Earlier versions of Py-ART made use of the Radx library for format conversions, which is still used to convert unsupported data formats into CfRadial prior to reading.
The original idea of the LROSE-core was that the community would contribute to the software. However, given that C++ poses challenges, this has not generally occurred. The user community has provided many bug reports and requests for upgrades, but the work has largely been carried out at CSU and NCAR. Recent work on Python-based additions to LROSE is more promising for community contributions.
User support is available through several mechanisms. The aforementioned LROSE Wiki hosts or links to installation guides, application documentation, practical radar meteorology documentation describing key algorithms with graphical examples, recordings from past workshops, and the citation for each release. The LROSE Wiki also links to the LROSE forum, where users can post issues or questions, which can be answered by other LROSE users or the LROSE development team. Users can also contact the LROSE development team with bugs or issues through a help email, Listserv. Issues and potential solutions identified in the code can be submitted to the LROSE GitHub repository. Detailed instructions on how to submit issues on GitHub are included in the core repository and the LROSE Wiki. Finally, to engage with users directly and educate the community on LROSE functionality, the LROSE team hosts periodic workshops and tutorials. These tutorials are hosted on a JupyterHub server deployed on NSF Jetstream2 resources provided through the ACCESS program, referred to as the LROSE Science Gateway. These interactive sessions help users understand the applications and provide an opportunity to address specific questions.
Supplemental Links
LROSE Wiki: https://github.com/NCAR/lrose-docs/wiki
LROSE Users Listserv: https://lists.colostate.edu/cgi-bin/mailman/listinfo/lrose-users
LROSE Quickstart Tutorial: https://github.com/NCAR/lrose-docs/wiki/Lrose_quickstart
LROSE Science Gateway tutorials: https://github.com/nsf-lrose/lrose-hub
LROSE User Forum: http://forum.lrose.net/
LROSE bootstrap repository: https://github.com/NCAR/lrose-bootstrap
Acknowledgements
The authors would like to thank the LROSE user community for their feedback and constructive criticisms that have improved the software. The authors would also like to thank Anna del Moral Mendez and Brad Klotz for their time spent testing software and providing guidance. Finally, the authors would like to thank the two reviewers whose constructive comments helped improve the manuscript.