Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “NetCDF”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records

A Scientific Data Processing Framework for Time Series NetCDF Data

ARM Data Integrator (ADI) is a framework to streamline the development of scientific algorithms that analyze time-series NetCDF data, and to improve the content and consistency of the output data products produced by these algorithms. ADI achieves these goals by automating the process of retrieving and preparing data for analysis, supporting the definition of output data products through a graphical interface, and providing a modular, flexible software development architecture. The input data, preprocessing, and output data specifications are defined through a graphical interface and stored in a database. ADI also includes a workflow for data integration, a library of software modules to support the workflow, and a source code generator that produces C, IDL and Python templates. Data preparation support includes automated retrieval of data from input files, merging the retrieved data into appropriately sized chunks, and transformation of the data onto a common coordinate system grid. Through the graphical interface, users can view the details of both their data products and those in the ARM catalog. The variable and attribute definitions of the existing data products can be used to build new output data products. In addition, the rules that make up the ARM archive’s data standards are laid on top of the view of the new data product providing the user with a visual cue indicating where their output violates an archive standard. The necessary configurations are stored in a database that is accessed by the ADI libraries. This paper discusses the ADI framework, its supporting components, and how ADI can significantly decrease the time and cost of implementing scientific algorithms while improving the ability of scientists to disseminate their results.

Atmospheric Science↗

Bit Grooming: statistically accurate precision-preserving quantization with compression, evaluated in the netCDF Operators (NCO, v4.4.8+)

Abstract. Geoscientific models and measurements generate false precision (scientifically meaningless data bits) that wastes storage space. False precision can mislead (by implying noise is signal) and be scientifically pointless, especially for measurements. By contrast, lossy compression can be both economical (save space) and heuristic (clarify data limitations) without compromising the scientific integrity of data. Data quantization can thus be appropriate regardless of whether space limitations are a concern. We introduce, implement, and characterize a new lossy compression scheme suitable for IEEE floating-point data. Our new Bit Grooming algorithm alternately shaves (to zero) and sets (to one) the least significant bits of consecutive values to preserve a desired precision. This is a symmetric, two-sided variant of an algorithm sometimes called Bit Shaving that quantizes values solely by zeroing bits. Our variation eliminates the artificial low bias produced by always zeroing bits, and makes Bit Grooming more suitable for arrays and multi-dimensional fields whose mean statistics are important. Bit Grooming relies on standard lossless compression to achieve the actual reduction in storage space, so we tested Bit Grooming by applying the DEFLATE compression algorithm to bit-groomed and full-precision climate data stored in netCDF3, netCDF4, HDF4, and HDF5 formats. Bit Grooming reduces the storage space required by initially uncompressed and compressed climate data by 25–80 and 5–65 %, respectively, for single-precision values (the most common case for climate data) quantized to retain 1–5 decimal digits of precision. The potential reduction is greater for double-precision datasets. When used aggressively (i.e., preserving only 1–2 digits), Bit Grooming produces storage reductions comparable to other quantization techniques such as Linear Packing. Unlike Linear Packing, whose guaranteed precision rapidly degrades within the relatively narrow dynamic range of values that it can compress, Bit Grooming guarantees the specified precision throughout the full floating-point range. Data quantization by Bit Grooming is irreversible (i.e., lossy) yet transparent, meaning that no extra processing is required by data users/readers. Hence Bit Grooming can easily reduce data storage volume without sacrificing scientific precision or imposing extra burdens on users.

58 GEOSCIENCES↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on ~30 m range gates, stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, below range, ran out of signal, cloud-topped). Cloud Base Height (Haar-gradient detection): 15 min estimates of cloud-base height (m) with a cloud-detection quality flag (0–3: none, low, moderate, high). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (2.0.0), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution, with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

Xanthos-Lake Dataset

The Xanthos-Lake v1.0 dataset provides the input data, trained machine-learning models, and simulation outputs needed to characterize lake water balance, snow and ice conditions, and mixing-layer temperature within the Xanthos global hydrological modeling framework. The dataset supports lake representation across a wide range of lake sizes and hydroclimatic conditions by combining xLSIM, a basin-specific machine-learning emulator of lake snow, ice, ice-cover fraction, and mixing-layer temperature, with the Xanthos-Lake water-balance model. The archive contains NetCDF datasets used to train and evaluate xLSIM, trained model weights, processed meteorological and lake-property inputs, and basin- and lake-category-specific simulation outputs. These materials are organized into four primary data groups, described below. Snowice_model_inputs: Contains the NetCDF input data used to train xLSIM. The xLSIM machine-learning framework uses three lake-based datasets. The meteorological forcing dataset provides monthly relative humidity, specific humidity, surface wind speed, maximum and minimum air temperature, downward longwave and shortwave radiation, snowfall, surface air pressure, and total precipitation. Lake surface area is included as an additional static predictor. The target-state dataset provides lake ice thickness, snow depth, snow cover, and lake mixing-layer temperature, while a companion lake-surface dataset provides the lake ice-cover fraction. Before training, ice thickness and snow depth are converted from meters to centimeters, mixing-layer temperature is converted from kelvin to degrees Celsius and constrained to nonnegative values, and ice-cover fraction is converted from a fraction to a percentage. The predictor variables are normalized using statistics calculated across the selected lakes and time steps. Snowice_model_outputs: Contains the NetCDF outputs generated by xLSIM. For each basin, xLSIM produces a file containing observed and predicted lake-state variables for the training, validation, and testing periods. The modeled variables include lake ice thickness, snow depth, snow cover, mixing-layer temperature, and lake ice-cover fraction. For basins without a sufficiently persistent snow-and-ice signal, the emulator predicts only mixing-layer temperature. The outputs also include training and validation loss histories, the selected model configuration, identifiers of the lakes used in training, and SHAP-based feature-importance information at the global, lake, and seasonal-regime levels. The trained machine-learning model weights are provided separately within the dataset archive. Together, these files support model evaluation and subsequent coupling with the Xanthos-Lake water-balance framework. XanthosLAKES: Contains the NetCDF input data used by the Xanthos-Lake framework. Monthly meteorological inputs include relative and specific humidity, downward shortwave and longwave radiation, mean, maximum, and minimum air temperature, wind speed, precipitation, snowfall, and surface air pressure. Static lake-property datasets provide lake identifiers, geographic locations, surface area, volume, mean depth, elevation, drainage area, fetch, outlet-routing information, and associated Xanthos grid-cell attributes. Separate bathymetric datasets provide the coefficients of the area–depth and volume–depth relationships for each aggregated lake unit. GLEV-based records provide observed lake surface area and evaporation data used to initialize lake states, define reference conditions, and calibrate and evaluate the model. Xanthos-Lake Outputs: Contains the basin- and lake-category-specific NetCDF outputs generated by Xanthos-Lake. Monthly variables include lake surface area, storage volume, outlet discharge, evaporation rate, evaporation volume, lake–groundwater exchange, lake inflow, ice thickness, snow depth, snow-cover fraction, ice-cover fraction, and mixing-layer temperature. The files also contain lake-specific calibration and validation statistics, including normalized root-mean-square error, mean absolute error, Nash–Sutcliffe efficiency, Kling–Gupta efficiency, and percent bias. Stored calibrated and derived parameters include the weir discharge coefficient, fractional freeboard, groundwater exchange coefficient, reference water level, corresponding reference surface area and storage volume, weir-width adjustment factor, and the fraction of routed inflow entering the lake. Basin identifiers, lake category, simulation period, calibration and validation periods, and parameter-schema information are retained as NetCDF metadata.

Abeshu, Guta [Pacific Northwest National Laborator↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on 30 m range gates (and 3 m range gates), stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, ran out of signal, below range, cloud-topped). Cloud Base Height (Haar-gradient detection): 10 min estimates of cloud-base height (m). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (3.0.0), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution (and 3 m for the year of 2025), with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min (10 min for Cloud Heights) summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on 30 m range gates (and 3 m range gates), stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, ran out of signal, below range, cloud-topped). Cloud Base Height (Haar-gradient detection): 10 min estimates of cloud-base height (m). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (3.0.1), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution (and 3 m for the year of 2025), with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min (10 min for Cloud Heights) summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

Downscaled precipitation and mean air temperature datasets; East-Taylor subbasin; 2008-2019; daily temporal resolution; 400 m spatial resolution

This dataset provides gridded meteorological forcing data (specifically, daily precipitation and daily mean air temperature). The dataset has been generated by downscaling the Parameter-elevation Regressions on Independent Slopes Model (PRISM) dataset from a spatial resolution of 800 m to 400 m. The time period is 2008-2019, and the mapped area is East Taylor subbasin in Upper Colorado. The data are in the form of NetCDF files, arranged by year. Compared to the PRISM dataset, the dates of the downscaled dataset are shifted backwards by one (e.g., downscaled data for May 25 corresponds to PRISM data for May 26). This temporal shifting makes the meteorological forcing correspond more closely to the prescribed date. The NetCDF format is a standard raster format that can be read using any Geographic Information System (GIS) software; plenty of modules exist in popular scripting languages (such as Python, R and Matlab) that can also be used to read NetCDF files.East_Taylor_Tavg_PRISM400 corresponds to mean air temperature.East_Taylor_Precip_PRISM400.zip corresponds to precipitation.The proprietary PRISM data (800 m resolution) were purchased with funding from the Watershed Function Scientific Focus Area supported by U.S. Department of Energy, Office of Science, Office of Biological and Environmental Research under award no. DE-AC02-05CH11231.Dataset update on March 9, 2022:Uploaded new data files that are identical to the earlier files but are now in the NetCDF format, arranged by year. Earlier, the files were in the GeoTiff format, arranged by date.

54 ENVIRONMENTAL SCIENCES↗

A data model of the Climate and Forecast metadata conventions (CF-1.6) with a software implementation (cf-python v2.1)

Abstract. The CF (Climate and Forecast) metadata conventions are designed to promote the creation, processing, and sharing of climate and forecasting data using Network Common Data Form (netCDF) files and libraries. The CF conventions provide a description of the physical meaning of data and of their spatial and temporal properties, but they depend on the netCDF file encoding which can currently only be fully understood and interpreted by someone familiar with the rules and relationships specified in the conventions documentation. To aid in development of CF-compliant software and to capture with a minimal set of elements all of the information contained in the CF conventions, we propose a formal data model for CF which is independent of netCDF and describes all possible CF-compliant data. Because such data will often be analysed and visualised using software based on other data models, we compare our CF data model with the ISO 19123 coverage model, the Open Geospatial Consortium CF netCDF standard, and the Unidata Common Data Model. To demonstrate that this CF data model can in fact be implemented, we present cf-python, a Python software library that conforms to the model and can manipulate any CF-compliant dataset.

54 ENVIRONMENTAL SCIENCES↗

BSEC flux towers: CSAT3B and TRH

The data were collected as part of the BSEC project, during the period from June 2025 to May 2026. Directory "broadway" contains data collected on a multi-level flux tower (US-BWf) in the Broadway East neighborhood (1808 North Patterson Park Ave., Baltimore City, MD 21213; LAT: 39o18'40.31'' N; LONG: 76o35'12.43'' W). At each of the four measurement heights (8.5 m, 11.1 m, 13.4 m, 15.9 m), a Campbell Scientific CSAT3B sonic anemometer was operated at 50 Hz to measure virtual temperature (tc) and three velocity components (u: 270 degrees; v: 180 degrees; w: vertical), and a RM Young temperature sensor (model 41382VC) was operated at 1 Hz inside a compact aspirated radiation shield (model 43502) to measure absolute temperature (T) and relative humidity (RH). Inside directory "broadway", directory "netcdf" contains data collected each day in 5-minute chunks that have been converted to NetCDF format (before quality checking), while "4hr" contains data arranged into 4-hour chunks (also in NetCDF format) that have been through basic quality checking steps (treating data points with nonzero diagnostic codes as missing data; fixing six or fewer consecutive missing data points using linear interpolation). Users are recommended to start with data in directory "4hr", while data in directory "netcdf" can be used for reference purposes.

Baltimore↗

CROCUS Sodar Measurements of Lower Atmospheric Wind Profiles at Argonne Testbed for Multiscale Observational Science (ATMOS) Site

The Scintec MFAS Sodar (Multiple-Frequency Acoustic Sounder) is an autonomous, ground-based acoustic remote sensing system designed to measure vertical profiles of horizontal wind speed, wind direction, and vertical velocity in the lower atmosphere. The instrument transmits sequences of acoustic pulses and detects the Doppler-shifted sound waves backscattered by small-scale temperature and velocity fluctuations caused by atmospheric turbulence. From these Doppler shifts, the system derives three-dimensional wind vectors by combining radial velocities from multiple beam orientations.The MFAS Sodar operates with a first usable range gate beginning at approximately 30 m above ground level and a configurable vertical resolution of 10 m. Under favorable acoustic conditions, the system provides wind profiles extending up to 600 m above ground level. Measurements are processed into 15-minute averaged profiles containing wind speed, direction, vertical velocity, and diagnostic quantities such as signal-to-noise ratio and echo strength.This dataset was collected at the Argonne Testbed for Multiscale Observational Science (ATMOS) facility in Lemont, Illinois, as part of DOE's CROCUS Urban Integrated Field Laboratory (UIFL) initiative. The purpose of these observations is to characterize the vertical wind structure and boundary-layer evolution across the urban–suburban gradient of the greater Chicago region. In particular, these data are intended to improve understanding of how local meteorology, such as lake-breeze penetration, nocturnal jets, and daytime mixing, varies between the densely built urban core and the suburban periphery. The MFAS observations provide critical context for evaluating high-resolution model simulations and for integrating with complementary lidar, radar, and in-situ meteorological measurements within the broader CROCUS UIFL network.All data are archived in NetCDF (Network Common Data Form) format and include wind and diagnostic parameters. The files can be accessed and analyzed using standard software that supports NetCDF, such as Python (e.g., xarray, netCDF4), MATLAB, R (e.g., ncdf4, raster), or Panoply (NASA’s NetCDF visualization application).

54 ENVIRONMENTAL SCIENCES↗

Influence of Lake Ice Biases in Reanalysis Data on Downscaled Climate Simulations over the Great Lakes Region

This data package contains observation-based and model-simulated datasets (all provided in NetCDF format) for evaluating how wintertime lake-ice representation affects regional weather and climate over the Laurentian Great Lakes (freshwater lake ecosystem) during the high–ice-cover winter of 2009. The observational component includes: (1) Stage IV gridded precipitation at 4 km, hourly resolution for January–February 2009 over the Great Lakes region (radar–gauge multisensor precipitation analyses); (2) Great Lakes Surface Environmental Analysis (GLSEA) satellite-derived lake-ice coverage at 1.3 km, daily resolution for the 2009 winter months, providing ice coverage over Lakes Superior, Michigan, Huron, Erie, and Ontario; and (3) in situ measurements at the Standard Rock site on Lake Superior from the Great Lakes Evaporation Network (GLEN) at hourly resolution, including near-surface atmospheric variables and sensible and latent heat fluxes (air–lake exchange) at a fixed point location. The modeling component provides corresponding fields from two simulations, both archived at 4 km, hourly resolution: a standalone Weather Research Forecasting model (WRF) run driven by the European Centre for Medium-Range Weather Forecasts (ECMWF) Reanalysis 5 (ERA5), and a two-way coupled model using WRF and the Finite Volume Community Ocean Model (WRF-FVCOM, a 3-D hydrodynamic lake model). These outputs include variables relevant to air–lake interaction and lake-effect processes (e.g., near-surface temperature, humidity, wind, precipitation, and surface turbulent fluxes), enabling direct comparison with the observational datasets. Users can analyze and visualize these NetCDF files with common tools such as Python (e.g., xarray, netCDF4, numpy, pandas), NCO/CDO, Panoply, or ncview; NetCDF variables can also be converted to other formats (e.g., CSV, GeoTIFF) using these utilities.

EARTH SCIENCE > ATMOSPHERE > ATMOSPHERIC TEMPERATU↗

Combined Mesonet and Tracker

Title: Combined Mesonet and Trackers (UNL Mobile Mesonets) Authors University of Nebraska PI: Adam Houston, UNL Professor (ahouston2@unl.edu) Mailing Address: 126 Bessey Hall P.O. Box 880340 Lincoln, NE 68588-0340 CoMeT Overview The University of Nebraska-Lincoln operates three Combined Mesonet and Tracker (CoMeTs). CoMeTs are Ford Explorers (model years 2015, 2017, and 2019) with forward-mounted suites of meteorological sensors and dual moonroofs, combining the capability of a mobile mesonet to collect near-surface observations with the capability of an unmanned aircraft systems (UAS) tracker vehicle, which enables an observer in the second row of seats to see the aircraft and maintain compliance with Federal Aviation Administration policies on UAS operation. The CoMeTs collect observations of slow temperature and humidity at ~2 m above ground level (AGL) using a Vaisala HMP155A, fast temperature at ~2 m AGL using a Campbell Scientific 109SS-L thermistor, pressure at ~2.5 m AGL using a Vaisala PTB210, wind speed and direction at ~3.25 m AGL using an R.M. Young 05103 propeller anemometer, and vehicle heading using a KVH Industries C-100 fluxgate compass (Barbieri et al. 2019). The HMP155A and 109SS-L thermistor are shielded and aspirated within a U-tube (Waugh and Frederickson 2010; Houston et al. 2016). This list of sensors is also included in the CoMeT data file metadata. Manufacturer specifications for these instruments are given in Table 1 of Hanft and Houston (2018). The reported measured quantities are summarized below.CoMeT-3 was funded through an equipment allocation included in the NSF TORUS award (AGS-1824649). Instrument Description The specific sensors included on each CoMeT are summarized in the table at the end of this section. In general each CoMeT collects observations of slow temperature and humidity at ~2 m above ground level (AGL) using a Vaisala HMP155, fast temperature at ~2 m AGL using a Campbell Scientific 109SS-L thermistor, pressure at ~2.5 m AGL using a Vaisala PTB210 barometer with a Gill pressure port, wind speed and direction at ~3.25 m AGL using an R.M. Young 05103 propeller anemometer, position using a Garmin 19x HVS receiver, and vehicle heading using a KVH Industries C-100 fluxgate compass. The HMP155 and 109SS are shielded and aspirated within a U-tube (Waugh and Frederickson 2010; Houston et al. 2016). Fast temperature and corrected RH measurements (using sensors housed within the U-tube) have a time constant of 10-12 s based on data collected across a temperature and RH shock during the CLOUD-MAP 2017 calibration/validation tests on June 26, 2017. Vehicle speed was < 10 kts for this test. CoMeT-1 CoMeT-2 CoMeT-3 Slow Temperature Slow RH Vaisala HMP155A-L20-PT Part #: 22280-7 Vaisala HMP155E Part #: E1AA11A0B1A1A0A Vaisala HMP155E Part #: E1AA11A0B1A1A0A Fast temperature Campbell Scientific 109SS-L20-PT Part #: 21448-3 Campbell Scientific 109SS-L12-PW Part #: 21448-109 Campbell Scientific 109SS-L12-PW Part #: 21448-150 Pressure Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Wind RM Young 05103-L20-PT Part #: 18435-310 RM Young 05103-L20-PW Part #: 18435-244 RM Young 05103-L20-PW Part #: 18435-244 GPS Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Compass KVH C-100 Part #: 01-0177-15 KVH C-100 Part #: 01-0177-15 KVH C-100 Part #: 01-0177-15 Logger Campbell Scientific CR6-NA-XT-SW Part #: 28385-9 Campbell Scientific CR6-WIFI-XT-SW Part #: 28385-6 Campbell Scientific CR6-WIFI-XT-SW Part #: 28385-6 Data Collection and Real-Time Processing The reported measured quantities are summarized in the table below. Quantity Units Source Epoch time Seconds GPS Latitude and longitude Degrees GPS Altitude m GPS Pressure hPa PTB210 Temperature (fast) deg C 109SS-L Temperature (slow) deg C HMP155 RH (slow) % HMP155 Vehicle speed m/s GPS Vehicle heading deg C-100 and GPS In addition to the measured variables, several derived variables are calculated. Corrected/fast relative humidity (%) Relative humidity is adjusted to the fast temperature following Richardson et al. (1998) and Houston et al. (2016). Water vapor mixing ratio (g/kg) Dew point temperature (&deg;C) Potential temperature (Kelvin) Virtual potential temperature (Kelvin) Equivalent potential temperature (Kelvin) Regular intercomparisons between all three CoMeTs were performed during TORUS 2019. Comparisons were also conducted between CoMeT-1 and CoMeT-2 during LAPSE-RATE (2018) on 14 July. In these intercomparisons, the vehicles were parked adjacent to each other aligned perpendicular to (and facing into) the wind. To minimize engine heating effects, intercomparisons were only conducted when the wind speed was >10 kts. Data Format Original data files for each deployment are saved as text files and then converted to NetCDF. NetCDF versions have units that are CF compliant and may not match the original units in the txt files. The naming convention for the NetCDF files is as follows: UNL.CoMeT3.{deployment date YYYYMMDD}.{start time of observation collection in UTC HHMM}.L2.{post-processing codes}.cdf example: UNL.CoMeT3.20190627.1931.L2.g1.f1.cdf Post-processing codes are included to track modifications to the raw data. These codes are closely connected to error flags associated with each record. Each letter corresponds to a particular instrument: g: GPS p: Barometer tf: Fast temperature ts: Slow temperature rh: Relative humidity f: Compass w: Wind monitor a: All instruments Each number corresponds to a particular post-processing action described more below. Measured and derived variables are included in the following table. Variable Heading Standard Name Units time Time seconds since 00:00:00, 01-01-1970 Alt Altitude meters lat Latitude degrees north lon Longitude degrees east fast_temp Air Temperature kelvin slow_temp Air Temperature kelvin pressure Air Pressure pascals logger_RH Relative Humidity percent calc_corr_RH Relative Humidity percent wind_speed Wind Speed meters per second wind_dir Wind From Direction degrees vehicle_dir Vehicle Direction degrees dewpoint Dew Point Temperature kelvin mixing_ratio Humidity Mixing Ratio g/g theta Air Potential Temperature kelvin theta_v Virtual Potential Temperature kelvin theta_e Equivalent Potential Temperature Kelvin error_flag The error_flag variable is a string that matches the post-processing codes listed above. All instruments will have an associated code, but will have a &ldquo;0&rdquo; if the datum is unchanged from the initial processed value. Error Codes The following table summarizes the error codes for data collected before 2020: Error Code Relevant CoMeT Description g1 1,2,3 Exact correction. GPS position and time reprocessed from raw data g2 1 As far as we can tell this is an exact correction to an error in the GPS time. During the correct time periods the time suddenly went backwards ~250s and stayed at this offset for 750s when it corrected itself. The offset was applied to the &ldquo;time warp&rdquo; period. p1 2 Approximate correction. Hole in the pressure tube connecting the pressure port to the barometer. Resulted in erroneously low air pressure measurements when the vehicle was in motion. Derived variables recalculated (dew point temperature [e depends on qv and p], water vapor mixing ratio, potential temperature, virtual potential temperature, equivalent potential temperature) a1 3 Exact correction. Missing data reprocessed from raw data a2 1 Bug fix to bias correction for ts1, ts2, and rh1: water vapor mixing ratio was off by a factor of 10 and virtual potential temperature was wrong because of this. f1 3 No correction, missing data. Fluxgate compass inoperable. Wind speed and direction calculated using GPS-derived vehicle heading instead. rh1 1 Approximate correction. Constant bias of +1.7% removed from relative humidity. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) ts1 1 Approximate correction. Constant bias of +0.6 K removed from slow temperature. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) ts2 1 Approximate correction. Constant bias of +1.0 K removed. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) References Bolton, D., 1980: The Computation of Equivalent Potential Temperature. Mon. Wea. Rev., 108, 1046&ndash;1053, https://doi.org/10.1175/1520-0493(1980)108<1046:TCOEPT>2.0.CO;2. Hanft, W., and A. L. Houston, 2018: An Observational and Modeling Study of Mesoscale Air Masses with High Theta-E. Mon. Wea. Rev., 146, 2503&ndash;2524, https://doi.org/10.1175/MWR-D-17-0389.1.Wexler Houston, A. L., R. J. Laurence III, T. W. Nichols, S. Waugh, B. Argrow, and C. L. Ziegler, 2016: Intercomparison of unmanned aircraft-borne and mobile mesonet atmospheric sensors. Journal of Atmospheric and Oceanic Technology. 33, 1569-1582, doi: 10.1175/JTECH-D-15-0178.1. Lowe, P. R., 1977: An Approximating Polynomial for the Computation of Saturation Vapor Pressure. J. Applied Meteorology, 16, 100&ndash;103. Richardson, S. J., S. E. Frederickson, F. V. Brock, and J. A. Brotzge, 1998: Combination temperature and relative humidity probes: Avoiding large air temperature errors and associated relative humidity errors. Preprints, 10th Symp. On Meteorological Observations and Instrumentation, Phoenix, AZ, Amer. Meteor. Soc., 278&ndash;283. Waugh, S., and S. E. Frederickson, 2010: An improved aspirated temperature system for mobile meteorological observations, especially in severe weather. 25th Conf. on Severe Local Storms, Denver, CO, Amer. Meteor. Soc., P5.2. [Available online at https://ams.confex.com/ams/25SLS/techprogram/paper_176205.htm.]

54 ENVIRONMENTAL SCIENCES↗

NetCDFFile v.1.0

SAND2024-02969O The NetCDFFile provides a generic interface to NetCDF and/or PnetCDF library calls, allowing the user to write generic code to read and write from NetCDF files. The NetCDFFile library requires a C++20 compliant compiler as well as NetCDF and PnetCDF libraries installed on the machine. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Preston, Leiph↗

Utah FORGE: Interferometric Synthetic Aperture Radar Data from 2023 and 2024

The dataset comprises Interferometric Synthetic Aperture Radar (InSAR) data from the TerraSAR-X and TanDEM-X satellite missions, covering the Utah FORGE site. This data includes interferometric pairs created using GMT-SAR processing software, chosen for their short orbital separations between May 1, 2023, and June 30, 2024. Included are various data and metadata, including Digital Elevation Models, unit vectors, and correlation coefficients. The dataset is packaged in several compressed tar files and formatted in NetCDF. To utilize this dataset, users will need software capable of handling NetCDF files and tools for decompressing tar files.

15 GEOTHERMAL ENERGY↗

Wave Measurements taken NW of Culebra Is., PR, 2023

Wave and sea surface temperature measurements collected by a Sofar Spotter buoy in 2023. The buoy was deployed on July 27, 2023 at 11:30 UTC northwest of Culebra Island, Puerto Rico, (18.3878 N, 65.3899 W) and recovered on Nov 5, 2023 at 12:45 UTC. Data are saved here in netCDF format, organized by month, and include directional wave statistics, GPS, and SST measurements at 30-minute intervals. Figures produced from these data are provided here as well. They include timeseries of wave height/period/direction and SST, GPS location, wave roses, and directional spectra. Additionally, raw CSV files from the Spotter's memory card can also be found below. NetCDF files can be read in python using the netCDF4 or Xarray packages, or through MATLAB using the "ncread()" command.

16 TIDAL AND WAVE POWER↗

I/O Bottleneck Detection and Tuning: Connecting the Dots using Interactive Log Analysis

Using parallel file systems efficiently is a tricky problem due to inter-dependencies among multiple layers of I/O software, including high-level I/O libraries (HDF5, netCDF, etc.), MPI-IO, POSIX, and file systems (GPFS, Lustre, etc.). Profiling tools such as Darshan collect traces to help understand the I/O performance behavior. However, there are significant gaps in analyzing the collected traces and then applying tuning options offered by various layers of I/O software. Seeking to connect the dots between I/O bottleneck detection and tuning, we propose DXT Explorer, an interactive log analysis tool. In this paper, we present a case study using our interactive log analysis tool to identify and apply various I/O optimizations. We report an evaluation of performance improvement achieved for four I/O kernels extracted from science applications.

Bez, Jean Luca↗

Stride Search v. 1.0

Stride Search provides a flexible tool for detecting storms or other extreme climate events in high-resolution climate data sets saved on uniform latitude-longitude grids in standard NetCDF format. Users provide the software a quantitative description of a meteorological event they are interested in; the software searches a data set for locations in space and time that meet the user’s description. In its first stage, Stride Search performs a spatial search of the data set at each timestep by dividing a search domain into circular sectors of constant geodesic radius. Data from a netCDF file is read into memory for each circular search sector. If the data meet or exceed a set of storm identification criteria (defined by the user), a storm is recorded to a linked list. Finally, the linked list is examined and duplicate detections of the same storm are removed and the results are written to an output file. The first stage’s output file is read by a second program that builds storm. Additional identification criteria may be applied at this stage to further classify storms. Storm tracks are the software’s ultimate output and routines are provided for formatting that output for various external software libraries for plotting and tabulating data.

Bosler, Peter↗