Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “computer bugs”

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 73 records · Page 4

Giallar: push-button verification for the qiskit Quantum compiler

This paper presents Giallar, a fully-automated verification toolkit for quantum compilers. Giallar requires no manual specifications, invariants, or proofs, and can automatically verify that a compiler pass preserves the semantics of quantum circuits. To deal with unbounded loops in quantum compilers, Giallar abstracts three loop templates, whose loop invariants can be automatically inferred. To efficiently check the equivalence of arbitrary input and output circuits that have complicated matrix semantics representation, Giallar introduces a symbolic representation for quantum circuits and a set of rewrite rules for showing the equivalence of symbolic quantum circuits. With Giallar, we implemented and verified 44 (out of 56) compiler passes in 13 versions of the Qiskit compiler, the open-source quantum compiler standard, during which three bugs were detected in and confirmed by Qiskit. Furthermore, our evaluation shows that most of Qiskit compiler passes can be automatically verified in seconds and verification imposes only a modest overhead to compilation performance.

automated verification↗

Status of SPCA-ANL Software Development, Software Quality Assurance, and Application (FY2025)

SPCA-ANL is a simulation tool used to perform deterministic analyses of sodium spray and pool fires. Development of the SPCA-II (Spray Pool Combustion Analysis) code began in the mid- 1980s as part of the Clinch River Breeder Reactor (CRBR) Project. At that time, development of SPCA-II, which was led by Rockwell International, was focused on treatment of large-scale sodium spray, stream, and pool fires that were anticipated to be prototypic of the steam generator building cells in CRBR. Under more recent DOE NE programmatic activities, the SPCA-II code was recovered from existing literature and underwent minor modifications to generate a stable executable. This recovered version of the code was not formally released. As part of the Versatile Test Reactor (VTR) Project in the 2010s, the SPCA-II code underwent key modifications to improve stability, address modeling deficiencies, improve consistency between the code manual and software, and address numerous bugs. At this point, SPCA-II was renamed SPCA-ANL. Given that SPCA-II served as the original basis for SPCA-ANL, both codes share an integrated history. Following termination of the VTR Project, the DOE NE Fast Reactor Program resumed support of the software with the goal of building and maintaining software infrastructure that can enable commercial-grade dedication of SPCA-ANL by an end user. Version 1.0, the first external release of SPCA-ANL, was generated in June 2024. This report summarizes the development and maintenance activities completed for SPCAANL in FY2025. This year’s work was focused on improving quality and usability of the code. The provisional Software Quality Assurance (SQA) program has been established and was used to test the procedures for infrastructure improvements, code development, bug fixes, and code releases, as described in the following sections of this report. A code Version 1.0.1 was released in FY25, as described in Chapter 4.

97 MATHEMATICS AND COMPUTING↗

UAV Resilience Against Stealthy Attacks

Unmanned aerial vehicles (UAVs) depend on software components to automate dangerous or critical missions; these components are then a desirable target for adversaries seeking to sabotage the UAV. Some work has been done to prevent an attacker who has either compromised a ground control station or parts of a UAV’s software from sabotaging the vehicle, but not both. We present an architecture running a UAV software stack with runtime monitoring and seL4-based software isolation that prevents attackers from both exploiting software bugs and utilizing stealthy attacks. Our architecture retrofits legacy UAVs and secures the popular MAVLink protocol, making it widely applicable for UAVs to adopt.

42 - ENGINEERING↗

Verification of the DIF3D Software to Support Fast Reactor Analysis

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. DIF3D is central to this system. The driver for this effort requires the 3D Cartesian, triangular-Z, and hexagonal-Z core geometry options of DIF3D be verified. Previous work identified the DIF3D features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying DIF3D’s ability to correctly translate the user’s model in to DIF3D’s preferred format, verifying that options planned for use have the desired effect, and verifying the correctness of the eigenvalue, fixed-source, forward, and adjoint solvers in DIF3D-FD and DIF3D-VARIANT. This manuscript provides the verification tasks and their results with respect to the features needed for current design activities. Since analytic solutions of the neutron diffusion and transport equations are either limited in scope or not possible, multiple tiers of problems unique to each solver and geometry type were implemented. Each of these tiers tests features independent and complementary arguments for why the separate testing of functionalities is acceptable. Finally, this separate testing was also supplemented with a high-level integral check of each the diffusion and transport capabilities and applicable geometries. To accommodate cases which an analytic solution is not feasible, MCNP6.2 was relied upon to provide a higher-order reference solution. This therefore required that the capabilities within MCNP6.2 which were relied upon for this work are also verified in this work. No MCNP discrepancies were noted in this effort. Note that the MCNP6.2 verification included in this work does not stand as a full verification of MCNP6.2, but merely verifies the features used in verifying DIF3D. The verification effort identified no issues that are debilitating or otherwise impactful to design usage of DIF3D, and thus DIF3D version 11.0, release 3012 is considered verified. As some additional changes have been made to the ARC software since this point all versions between release 3012 and 3266 can be considered verified as version 3253 was used for all updates in this revision. The types of issues that were identified were predominantly in the areas of: unclear documentation, software bugs which were inconsequential to final results, editing options which were ignored in favor of printing more information than requested, bugs in the outputs of intermediate results, or secondary output binary file information which was not present. While not a bug, this verification report also identified that the algorithm used to evaluate the peak fast flux in a nodal transport solution can be quite unreliable due to the methodology used and the location of the peak within the mesh. The authors of the report therefore recommend the usage of the EvaluateFlux software (distributed with ARC) as a more robust alternative noting that DIF3D will properly notify the user when the peaking values it is providing are potentially incorrect.

97 MATHEMATICS AND COMPUTING↗

GADRAS-DRF for Safeguards (FY 2025 Mid-Year/Annual Report)

Task 1 – Extract GADRAS-DRF capabilities for a workflow intuitive to safeguards analysis. This task is almost complete. Significant improvements have been made to the functionality of customizing peak fits for use in the isotopics application, as well as peak-based FSA model analysis. The remaining tasks revolve around bug fixes, testing the application, and adding a density scroll bar to isotopics for real time analysis updates. The density scroll bar values will be reflected in summary tables and the self-shielding form accessed within isotopics.

97 MATHEMATICS AND COMPUTING↗

A Typing Discipline for High-Assurance Control Systems

This poster describes a typing discipline for high-assurance industrial systems based on three novel type systems. The first type system, information flow control (IFC), controls the flow of data through the system. The second system, dependent session types, restricts messages exchanged during the execution of a communication protocol to avoid dangerous states. The third system uses dimensional analysis to avoid subtle bugs that adversaries can exploit to cause the system to enter a dangerous state. This poster describes how a combination of these approaches can prevent sophisticated cyber attacks, such as the infamous Stuxnet incident, from occurring. In addition, we provide experimental evidence to support the claim that these approaches can be applied in control systems that are resource-constrained.

42 - ENGINEERING↗

Verification of the DIF3D Software to Support Fast Reactor Analysis (Rev. 3)

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. DIF3D is central to this system. The driver for this effort requires the 3D Cartesian, triangular-Z, and hexagonal-Z core geometry options of DIF3D be verified. Previous work identified the DIF3D features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying DIF3D’s ability to correctly translate the user’s model in to DIF3D’s preferred format, verifying that options planned for use have the desired effect, and verifying the correctness of the eigenvalue, fixed-source, forward, and adjoint solvers in DIF3D-FD and DIF3D-VARIANT. This manuscript provides the verification tasks and their results with respect to the features needed for current design activities. Since analytic solutions of the neutron diffusion and transport equations are either limited in scope or not possible, multiple tiers of problems unique to each solver and geometry type were implemented. Each of these tiers tests features independent and complementary arguments for why the separate testing of functionalities is acceptable. Finally, this separate testing was also supplemented with a high-level integral check of each the diffusion and transport capabilities and applicable geometries. To accommodate cases which an analytic solution is not feasible, MCNP6.2 was relied upon to provide a higher-order reference solution. This therefore required that the capabilities within MCNP6.2 which were relied upon for this work are also verified in this work. No MCNP discrepancies were noted in this effort. Note that the MCNP6.2 verification included in this work does not stand as a full verification of MCNP6.2, but merely verifies the features used in verifying DIF3D. The verification effort identified no issues that are debilitating or otherwise impactful to design usage of DIF3D, and thus DIF3D version 11.0, release 3012 is considered verified. As some additional changes have been made to the ARC software since this point all versions between release 3012 and 3266 can be considered verified as version 3253 was used for all updates in this revision. The types of issues that were identified were predominantly in the areas of: unclear documentation, software bugs which were inconsequential to final results, editing options which were ignored in favor of printing more information than requested, bugs in the outputs of intermediate results, or secondary output binary file information which was not present. While not a bug, this verification report also identified that the algorithm used to evaluate the peak fast flux in a nodal transport solution can be quite unreliable due to the methodology used and the location of the peak within the mesh. The authors of the report therefore recommend the usage of the EvaluateFlux software (distributed with ARC) as a more robust alternative noting that DIF3D will properly notify the user when the peaking values it is providing are potentially incorrect.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Mini Report: LLMs for Vulnerability Repair in Code

Software vulnerability repair is a notoriously difficult task that is both time consuming and labor intensive. While research into this area has a long history, the recent successes of large language models (LLMs) across many tasks have also spurred efforts to leverage LLM capabilities for automated software vulnerability repair. Currently, there are limitations in the capabilities of LLMs to fix bugs and insufficiently addressed problems in the evaluations of these studies may cause performance to not transfer when they are used in practice. Additionally, most research in the area treats finding and fixing bugs as separate concerns - how to best combine all the subtasks involved in removing vulnerabilities from code remains an open question. In this report, we summarize our findings and opinions on the current state of the art in LLM-assisted code vulnerability repair, highlighting current unresolved problems in the field as well as potential applications and future research.

97 MATHEMATICS AND COMPUTING↗

Towards Low-Overhead Resilience for Data Parallel Deep Learning

Data parallel techniques have been widely adopted both in academia and industry as a tool to enable scalable training of deep learning models. At scale, DL training jobs can fail due to software or hardware bugs, may need to be preempted or terminated due to unexpected events, or may perform suboptimally because they were misconfigured. Under such circumstances, there is a need to recover and/or reconfigure data-parallel DL training jobs on-the-fly, while minimizing the impact on the accuracy of the DNN model and the runtime overhead. In this regard, state-of-art techniques adopted by the HPC community mostly rely on checkpoint-restart, which inevitably leads to loss of progress, thus increasing the runtime overhead. In this paper we explore alternative techniques that exploit the properties of modern deep learning frameworks (overlapping of gradient averaging and weight updates with local gradient computations through pipeline parallelism) to reduce the overhead of resilience/elasticity. To this end we introduce a failure simulation framework and two resilience strategies (immediate mini-batch rollback and lossy forward recovery), which we study compared with checkpoint-restart approaches in a variety of settings in order to understand the trade-offs between the accuracy loss of the DNN model and the runtime overhead.

data-parallel training↗

The Automatic Reactor Control System (ARCS) Upgrade, version 2.0 for TREAT

The Transient REActor Test Facility (TREAT) recently underwent an upgraded to the Automatic Reactor Control System (ARCS). The purpose of the upgrade was to institute a new software architecture that is better suited for the programming environment, patched software bugs and applied two new segments for reactor control. This paper will focus on the new segments for reactor control. The two new control segments added to ARCS are called Generic Power and Generic Rods. The original version of ARCS provided only two power related functions, namely periods and ramps, that had to be spliced together to generate any power shape. The Generic Power segment allows the user to input data points to define the function and then the algorithm does its best to create the desired shape. The original ARCS program utilized two direct rod commands (i.e. open loop control), these were a rod stop and clip. A Generic Rod segment extends the ability of the computer to directly command any rod position. The functionality of these new segments was proven during the TREAT outage in 2024.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗

Energy Exascale Earth System Model v2.0

First release of version 2 of the Energy Exascale Earth System Model. The atmosphere component remains EAM. Major changes since version 1 include: all column-physics parameterizations are computed on a separate grid that has approximately half the number of points of the dynamics grid, a new nonhydrostatic dynamical core (running in hydrostatic mode) with semi-Lagrangian tracer transport, CLUBB updated from v1 to v2, a new convective trigger (dCAPE/ULL) based on the dynamic Convective Available Potential Energy (CAPE) (dCAPE) and the Unrestricted Launch Level (ULL) concepts is used in ZM. minimum cloud droplet number changed, gravity wave drag energy conservation fixed and new tunings used, dust emission size distribution changed to emit more coarse dust particles The land component is still ELM. Major changes since version 1 include: using SNICAR-AD for radiation in snow to match the sea-ice model and fixing bugs in snow compaction and water state calculation. The ocean component remains MPAS-ocean. Major change since version 1 include: Redi isopycnal mixing has been updated, tested, and tuned in combination with the Gent-McWilliams parameterization, a sign error was fixed in the 3rd-order flux routines, the mesh used in low-resolution coupled cases was modified and the time steps adjusted, new regionally refined meshes were created, one focused on North America and another on the Southern Ocean, including ice shelf cavities. The sea-ice component remains MPAS-seaice. Major changes since version 1 include: A new heat- and freshwater-conserving coupling of frazil ice, turning off of SSH filtering, addition of SNICAR-AD and snow grain aging. The land-ice component remains MPAS-Albany-landIce (MALI) and is a static ice sheet. There is more out-of-the-box support for cryosphere configurations including the new regionally refined configuration around Antarctica with ice shelf cavities. The river model is MOSART. The half-degree river mesh was redone so it no longer treats Black and Caspian seas as ocean. The coupler remains cpl7/MCT. Major changes since version 1 include handling of ice shelf melt fluxes (heat / freshwater exchange with the ocean), and data icebergs. All components allow regional refinement of their meshes and two separate example of refinement, one in and around North America and one around Antarctica and the Southern Ocean, are provided.

E3SM Project, DOE↗

NEAMS Technical Area Support in MOOSE

The Multiphysics Object-Oriented Simulation Environment (MOOSE) framework is a foundational capability used by the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program to create over 15 different simulation tools for advanced nuclear reactors. Due to this ubiquity, improvements to the framework in support of modeling and simulation goals are critical to the program. These improvements can take many forms, including optimization, improved user experience, streamlined application programming interfaces (APIs), parallelism, and other new capabilities. The work described in this report was conducted in direct support of the simulation tools and has already been deployed. The capabilities outlined in this report include implementing hash table matrix assembly for efficient sparsity pattern construction for contact in BISON, developing re-step testing infrastructure for ensuring the viability of overlapping domain coupling between SAM and Pronghorn, allowing unique preconditioners for single-input multi-system solves, supporting multi-system in MOOSE’s workhorse executioners, and many more smaller feature enhancements and bug fixes.

97 - MATHEMATICS AND COMPUTING↗

A knowledge based software engineering environment testbed

The Carnegie Group Incorporated and Boeing Computer Services Company are developing a testbed which will provide a framework for integrating conventional software engineering tools with Artifical Intelligence (AI) tools to promote automation and productivity. The emphasis is on the transfer of AI technology to the software development process. Experiments relate to AI issues such as scaling up, inference, and knowledge representation. In its first year, the project has created a model of software development by representing software activities; developed a module representation formalism to specify the behavior and structure of software objects; integrated the model with the formalism to identify shared representation and inheritance mechanisms; demonstrated object programming by writing procedures and applying them to software objects; used data-directed and goal-directed reasoning to, respectively, infer the cause of bugs and evaluate the appropriateness of a configuration; and demonstrated knowledge-based graphics. Future plans include introduction of knowledge-based systems for rapid prototyping or rescheduling; natural language interfaces; blackboard architecture; and distributed processing

Gill, C.↗

DRiFT - Release 1.1.1: Organic Scintillators

DRiFT (a Detector Response Function Toolkit) is LANL-developed software that postprocesses output from the extensively validated radiation transport code, MCNP, and generates realistic nuclear instrumentation response. DRiFT is designed to be flexible, enabling users to specify detector type and many experimental settings, as well as accommodating the addition of their own desired features. Although DRiFT development has included scintillator, gas, and semiconductor features, the focus of this release is on organic scintillator and associated capabilities. Organic scintillators are widely used in the areas of nuclear safeguards and nuclear non-proliferation efforts. DRiFT has several diagnostic and detector physics features relevant to detailed scintillator simulations including: tracking source particle information, scintillation light production, the effects of PMT quantum efficiency and gain, and digitizer settings. Users can select responses from many scintillator and PMT types supported natively by DRiFT, or add their own by following the instructions in this document. We acknowledge that DRiFT is under active development, bug reports and general questions and comments should be directed to Madison Andrews, madison@lanl.gov. This manual is divided into four parts: I) An overview of DRiFT, including how to obtain and install the executable, II) A description of the detector physics related to scintillators available, III) a description of more general DRiFT features the user may find useful, and IV) a description of the test suite and examples made available with the code release.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DRiFT - Release 2.1.0: Organic Scintillators and Gas Detectors

DRiFT (a Detector Response Function Toolkit) is LANL-developed software that post-processes output from the extensively validated radiation transport code, MCNP, and generates realistic nuclear instrumentation response. DRiFT is designed to be flexible, enabling users to specify detector type and many experimental settings, as well as accommodating the addition of their own desired features. The focus of this release is on organic scintillator, gas detector, and associated capabilities, while semiconductor features are still under development. Organic scintillators are widely used in the areas of nuclear safeguards and nuclear non-proliferation efforts. DRiFT has several diagnostic and detector physics features relevant to detailed scintillator simulations including: tracking source particle information, scintillation light production, the effects of PMT quantum efficiency and gain, and digitizer settings. Users can select responses from many scintillator and PMT types supported natively by DRiFT, or add their own by following the instructions in this document. DRiFT also has several diagnostic and detector physics features relevant to neutron gas detector simulations including: gas detector wall effects, inactive areas at the end of detector tubes, and effects of a preamplifier. We acknowledge that DRiFT is under active development, bug reports and general questions and comments should be directed to Madison Andrews, madison@lanl.gov. This manual is divided into four parts: I) An overview of DRiFT, including how to obtain and install the executable, II) A description of the detector physics related to scintillators available, III) a description of more general DRiFT features the user may find useful, and IV) a description of the test suite and examples made available with the code release.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Using Eye-Tracking to Quantify Reverse Engineering Expertise

Software reverse engineering (RE) requires analysts to closely read and make decisions about code. Little is known about what makes an analyst successful, making it difficult to train new analysts or design tools to augment existing ones. The goal of this project was to quantify the eye movement behaviors supporting RE and code comprehension more generally. We applied eye-tracking methods from the language comprehension literature to understand where analysts direct their attention over time when completing tasks (e.g., function identification, bug detection). Across three studies, we manipulated aspects of code hypothesized to impact comprehension (e.g., variable name meaningfulness, code complexity) and presentation methods (e.g., line-by-line, free viewing, gaze-contingent moving window) to understand effects on accuracy and gaze patterns. Results showed clear benefits of meaningful variable names, and effects of expertise on global and line-specific viewing patterns. Findings could inspire empirically-supported tool or analytic adaptations that help to reduce analyst workload.

97 MATHEMATICS AND COMPUTING↗

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↗

HPC-driven computational reproducibility in numerical relativity codes: a use case study with IllinoisGRMHD

Abstract Reproducibility of results is a cornerstone of the scientific method. Scientific computing encounters two challenges when aiming for this goal. Firstly, reproducibility should not depend on details of the runtime environment, such as the compiler version or computing environment, so results are verifiable by third-parties. Secondly, different versions of software code executed in the same runtime environment should produceconsistent numerical results for physical quantities. In this manuscript, we test the feasibility of reproducing scientific results obtained using theIllinoisGRMHDcode that is part of an open-source community software for simulation in relativistic astrophysics, theEinstein Toolkit. We verify that numerical results of simulating a single isolated neutron star withIllinoisGRMHDcan be reproduced, and compare them to results reported by the code authors in 2015. We use two different supercomputers: Expanse at SDSC, and Stampede2 at TACC. By compiling the source code archived along with the paper on both Expanse and Stampede2, we find thatIllinoisGRMHDreproduces results published in its announcement paper up to errors comparable to round-off level changes in initial data parameters. We also verify that a current version ofIllinoisGRMHDreproduces these results once we account for bug fixes which have occurred since the original publication.

Astronomy & Astrophysics↗