Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “executable files”

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 505 records · Page 28
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Legato: Personal Computer Software for Analyzing Pressure-Sensitive Paint Data

'Legato' is personal computer software for analyzing radiometric pressure-sensitive paint (PSP) data. The software is written in the C programming language and executes under Windows 95/98/NT operating systems. It includes all operations normally required to convert pressure-paint image intensities to normalized pressure distributions mapped to physical coordinates of the test article. The program can analyze data from both single- and bi-luminophore paints and provides for both in situ and a priori paint calibration. In addition, there are functions for determining paint calibration coefficients from calibration-chamber data. The software is designed as a self-contained, interactive research tool that requires as input only the bare minimum of information needed to accomplish each function, e.g., images, model geometry, and paint calibration coefficients (for a priori calibration) or pressure-tap data (for in situ calibration). The program includes functions that can be used to generate needed model geometry files for simple model geometries (e.g., airfoils, trapezoidal wings, rotor blades) based on the model planform and airfoil section. All data files except images are in ASCII format and thus are easily created, read, and edited. The program does not use database files. This simplifies setup but makes the program inappropriate for analyzing massive amounts of data from production wind tunnels. Program output consists of Cartesian plots, false-colored real and virtual images, pressure distributions mapped to the surface of the model, assorted ASCII data files, and a text file of tabulated results. Graphical output is displayed on the computer screen and can be saved as publication-quality (PostScript) files.

Schairer, Edward T.↗
DOE OSTI2024

INSPIRED: Inelastic neutron scattering prediction for instantaneous results and experimental design

Inelastic neutron scattering (INS) has unique advantages in probing how atoms vibrate and how the vibrations propagate and interact. Such dynamic information is crucial in understanding various material properties, from heat capacity, thermal conductivity, phase transitions, and chemical reactions to more exotic quantum behavior. The analysis and interpretation of the INS spectra often start from a model structure of the sample, followed by a series of calculations to obtain the simulated spectra to compare with experiments. The conventional way to perform such calculations usually requires significant time, computing resources, and specialized expertise. Here, we present a new program named INSPIRED (Inelastic Neutron Scattering Prediction for Instantaneous Results and Experimental Design), which enables users to perform rapid INS simulations in several different ways on their personal computers in just a few clicks, with the crystal structure as the only input file. Specifically, the users can choose a pre-trained symmetry-aware neural network (coupled with an autoencoder) to predict the phonon density of states (DOS), 1D S(E) and 2D S(|Q|,E) spectra for any given structure. One can also choose an existing density functional theory (DFT) calculation from a database (containing over 12,000 crystals), and quickly obtain the simulated INS spectra for single crystals and powders. It is also possible to use pre-trained universal machine learning force fields to relax a given crystal structure, calculate the phonon dispersion and DOS, and, subsequently, the INS spectra. All these functions are implemented with a PyQt graphic user interface. Finally, we expect these new tools will benefit broad user communities and significantly improve the efficiency of experiment design, execution, and data analysis for INS.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2024

Verification of RESRAD-OFFSITE Code (V.4)

This report documents the verification of RESRAD-OFFSITE Version 4.0 and describes, where necessary, the verification of the following: • The data comprising the standard dose and risk coefficient libraries in the RESRAD database files Master_dcf_ICRP07.mdb and Master_dcf_2k.mdb. • The extraction and transfer of the data from the selected database file to the computational code by the RESRAD-OFFSITE 4.0 interface, ResOWin.exe. • The different processes that are modeled by the main computational code in RESRAD OFFSITE 4.0, ResOMain.exe. • The data displayed in the graphical and text reports. Many verifications were performed as part of the quality assurance quality control program associated with the development and release of RESRAD-OFFSITE 4.0, namely: • developer testing, • internal independent testing, and • release testing. Some were also performed in response to questions from users regarding the performance of the code. The main text of the report focuses on summarizing a subset of those tests, both independent and developer tests that verified the computations performed by the code. The verifications included in this report served as the basis for the development of the release tests of the computational executables and provided the quantitative results to be compared with the code output. The input and output interfaces and the data transfers between the various executables of the code were tested while performing the verification testing. They were tested intentionally during release testing. This report also provides some basic information to help in understanding the activities that were verified. The report: • outlines the components of RESRAD-OFFSITE 4.0 and the interconnections between these components, • outlines the processes modeled by the computational code, • provides summary figures and tables to offer confirmation of the verification of the computational components of the code, • reproduces the verifiers’ reports, if available, in individual appendices, • refers to the previous verification report (Yu et al. 2011) for more details about some of the verifications, and • reproduces the test cases and the testers’ reports from the release testing in individual appendices, when possible.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2022

Transitioning from File-Based HPC Workflows to Streaming Data Pipelines with openPMD and ADIOS2

This paper aims to create a transition path from file-based IO to streaming-based workflows for scientific applications in an HPC environment. By using the openPMP-api, traditional workflows limited by filesystem bottlenecks can be overcome and flexibly extended for in situ analysis. The openPMD-api is a library for the description of scientific data according to the Open Standard for Particle-Mesh Data (openPMD). Its approach towards recent challenges posed by hardware heterogeneity lies in the decoupling of data description in domain sciences, such as plasma physics simulations, from concrete implementations in hardware and IO. The streaming backend is provided by the ADIOS2 framework, developed at Oak Ridge National Laboratory. This paper surveys two openPMD-based loosely-coupled setups to demonstrate flexible applicability and to evaluate performance. In loose coupling, as opposed to tight coupling, two (or more) applications are executed separately, e.g. in individual MPI contexts, yet cooperate by exchanging data. This way, a streaming-based workflow allows for standalone codes instead of tightly-coupled plugins, using a unified streaming-aware API and leveraging high-speed communication infrastructure available in modern compute clusters for massive data exchange. We determine new challenges in resource allocation and in the need of strategies for a flexible data distribution, demonstrating their influence on efficiency and scaling on the Summit compute system. The presented setups show the potential for a more flexible use of compute resources brought by streaming IO as well as the ability to increase throughput by avoiding filesystem bottlenecks.

Poeschel, Franz↗
DOE OSTI2020

A Historic Context and Mitigation Documentation for a Portion of the U12n Tunnel Ventilation and Containment Systems, Area 12, Nevada National Security Site, Nye County, Nevada

The National Nuclear Security Administration Nevada Field Office (NNSA/NFO) has proposed repurposing the U12n Vent Hole #2 (SHPO Resource S2488) and the U12n.10 Vent Hole (S2489) for water sampling in the U12n Tunnel. The vent holes are part of the historic ventilation system for the tunnel and are contributing elements to the U12n Tunnel Historic District (D84). In consultation with the SHPO, NNSA/NFO determined the undertaking will have an adverse effect on the vent holes. The NNSA/NFO and the SHPO negotiated a memorandum of (MOA) with stipulations to mitigate adverse effects. This submission is to comply with the stipulations in the executed Memorandum of Agreement Between the National Nuclear Security Administration Nevada Field Office, Environmental Management Nevada Program Office, and the Nevada State Historic Preservation Officer Regarding Repurposing of Portions of the Ventilation System of the U12n Tunnel Complex Located in Area 12 at the Nevada National Security Site. In accordance with the MOA, the manuscript provides a historic context that describes the development and functioning of the historic U12n Tunnel ventilation system for underground nuclear tests (Stipulation III.C). High resolution digital color images of the vent hole containment doors, nearby elements, and overviews were obtained and keyed to a map and a photo index (Stipulation III.A) (Appendix A). Lastly, Architectural Resource Assessment (ARA) forms were completed for each of the vent holes and Historic District D84 (Stipulation III.B) (Appendix B). The documentation including the historic context report, photographs, image files, and resource forms produced to fulfill the terms of the MOA will be archived with the Nuclear Testing Archive in Las Vegas (Stipulation III.D).

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2025

Queued Up: 2025 Edition – Characteristics of Power Plants Seeking Transmission Interconnection As of the End of 2024 [Slides]

Electric transmission system operators (ISOs, RTOs, or utilities) require proposed power plants seeking to connect to the transmission grid to undergo a series of impact studies before they can be built. This process establishes what new transmission equipment or upgrades may be needed before a project can connect to the system and assigns the costs of that equipment. The lists of projects in this process are known as “interconnection queues”. In collaboration with interconnection.fyi, Berkeley Lab compiled, aggregated, and cleaned interconnection queue data from >50 transmission grid operators (7 ISO/RTOs and 49 non-ISO balancing areas), which collectively represent ~97% of currently installed U.S. electric generating capacity. The dataset includes requests submitted to queues through the end of 2024, and only includes requests seeking to connect to the transmission grid (not distribution-connected or behind-the-meter projects). The files below include both a PDF report and an Excel data file. The PDF report analyzes interconnection data and metrics through the end of 2024. The Excel data file includes (a) the full project-level interconnection queue dataset through 2024, (b) a codebook (data dictionary) describing each data field, and (c) 35 additional tabs featuring tables summarizing a range of interconnection metrics. Key highlights from the Queued Up: 2025 Edition (featuring data through 2024) include: • As of the end of 2024, there were ~10,300 projects actively seeking grid interconnection in the U.S., representing 1,400 GW of generation and approximately 890 GW of storage. • Historic withdrawal rates alongside relatively fewer new requests resulted in a 12% decrease in total active queue volume compared to the prior year. • Active natural gas capacity (136 GW, +72% year-over-year) increased in 2024, while solar (956 GW, -12%), storage (890 GW, -13%), and wind (271 GW, -26%) capacity decreased. • 408 GW of capacity already has a draft or executed interconnection agreement (IA) but has not yet reached commercial operations. • The time projects spend in queues before reaching COD is increasing. For the regions with available data, the median duration from IR to COD has doubled from <2 years for projects built in 2000-2007 to over 4 years for those built in 2018-2024. • Ultimately, most of this proposed capacity will not be built. Only 13% of capacity that submitted interconnection requests from 2000-2019 had reached commercial operations by the end of 2024; 77% of that capacity had been withdrawn and 10% was still active. • FERC Order 2023 and various other reforms are being implemented. These are important measures to reduce interconnection bottlenecks and enhance grid system reliability, but it is too early to measure and assess their full impact. • New additions for the 2025 edition include: (a) additional detail on data processing and gaps; (b) updates on interconnection reforms; (c) new analysis on interconnection agreements, and more.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS2005

Generating Mosaics of Astronomical Images

"Montage" is the name of a service of the National Virtual Observatory (NVO), and of software being developed to implement the service via the World Wide Web. Montage generates science-grade custom mosaics of astronomical images on demand from input files that comply with the Flexible Image Transport System (FITS) standard and contain image data registered on projections that comply with the World Coordinate System (WCS) standards. "Science-grade" in this context signifies that terrestrial and instrumental features are removed from images in a way that can be described quantitatively. "Custom" refers to user-specified parameters of projection, coordinates, size, rotation, and spatial sampling. The greatest value of Montage is expected to lie in its ability to analyze images at multiple wavelengths, delivering them on a common projection, coordinate system, and spatial sampling, and thereby enabling further analysis as though they were part of a single, multi-wavelength image. Montage will be deployed as a computation-intensive service through existing astronomy portals and other Web sites. It will be integrated into the emerging NVO architecture and will be executed on the TeraGrid. The Montage software will also be portable and publicly available.

Bergou, Attila↗
NASA NTRS1993

An expert system shell for inferring vegetation characteristics: Interface for the addition of techniques (Task H)

All the NASA VEGetation Workbench (VEG) goals except the Learning System provide the scientist with several different techniques. When VEG is run, rules assist the scientist in selecting the best of the available techniques to apply to the sample of cover type data being studied. The techniques are stored in the VEG knowledge base. The design and implementation of an interface that allows the scientist to add new techniques to VEG without assistance from the developer were completed. A new interface that enables the scientist to add techniques to VEG without assistance from the developer was designed and implemented. This interface does not require the scientist to have a thorough knowledge of Knowledge Engineering Environment (KEE) by Intellicorp or a detailed knowledge of the structure of VEG. The interface prompts the scientist to enter the required information about the new technique. It prompts the scientist to enter the required Common Lisp functions for executing the technique and the left hand side of the rule that causes the technique to be selected. A template for each function and rule and detailed instructions about the arguments of the functions, the values they should return, and the format of the rule are displayed. Checks are made to ensure that the required data were entered, the functions compiled correctly, and the rule parsed correctly before the new technique is stored. The additional techniques are stored separately from the VEG knowledge base. When the VEG knowledge base is loaded, the additional techniques are not normally loaded. The interface allows the scientist the option of adding all the previously defined new techniques before running VEG. When the techniques are added, the required units to store the additional techniques are created automatically in the correct places in the VEG knowledge base. The methods file containing the functions required by the additional techniques is loaded. New rule units are created to store the new rules. The interface that allow the scientist to select which techniques to use is updated automatically to include the new techniques. Task H was completed. The interface that allows the scientist to add techniques to VEG was implemented and comprehensively tested. The Common Lisp code for the Add Techniques system is listed in Appendix A.

Harrison, P. Ann↗
DOE OSTI2023

Workflows Community Summit 2022: A Roadmap Revolution

Scientific workflows have become integral tools in broad scientific computing use cases. Science discovery is increasingly dependent on workflows to orchestrate large and complex scientific experiments that range from the execution of a cloud-based data preprocessing pipeline to multi-facility instrument-to-edge-to-HPC computational workflows. Given the changing landscape of scientific computing (often referred to as a computing continuum) and the evolving needs of emerging scientific applications, it is paramount that the development of novel scientific workflows and system functionalities seek to increase the efficiency, resilience, and pervasiveness of existing systems and applications. Specifically, the proliferation of machine learning/artificial intelligence (ML/AI) workflows, need for processing large-scale datasets produced by instruments at the edge, intensification of near real-time data processing, support for long-term experiment campaigns, and emergence of quantum computing as an adjunct to HPC, have significantly changed the functional and operational requirements of workflow systems. Workflow systems now need to, for example, support data streams from the edge-to-cloud-to-HPC, enable the management of many small-sized files, allow data reduction while ensuring high accuracy, orchestrate distributed services (workflows, instruments, data movement, provenance, publication, etc.) across computing and user facilities, among others. Further, to accelerate science, it is also necessary that these systems implement specifications/standards and APIs for seamless (horizontal and vertical) integration between systems and applications, as well as enable the publication of workflows and their associated products according to the FAIR principles.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2012

Does Commercial Space Really Need MOA?

The Mission Operations Assurance (MOA) discipline actively participates as a project member to achieve their common objective of full mission success while also providing an independent risk assessment to the Project Manager. The cornerstone element of MOA is the independent assessment of the risks the project faces in executing its mission. Especially as the project approaches critical mission events, it becomes imperative to clearly identify and assess the risks the project faces. This has been the paradigm for robotic space exploration missions, but does the same apply to commercial space operations? This is the question which is the driver for this year's MOA track at the 18th Annual Improving Space Operations workshop in April at the Jet Propulsion Laboratory, and the question we examine in this paper. Corollaries to this driving question are why shouldn't MOA apply and are there factors beyond mission success with acceptable risk which apply to commercial space operations that are not present in government scientific missions? To address these questions, areas we focus on include risk (both mission and profit) management for commercial space operations and the practical extension of robotic mission MOA to commercial space operations. Another key area to look at is command file errors which are a major concern for deep space robotic missions, but can we worry about them less with manned missions or unmanned supply mission? Further, with the growing concern about space debris, we delve into the role of MOA relative to End-of-Mission activities. This paper examines these topics and in particular the perspectives presented at the workshop to begin charting the appropriate course for MOA in the emerging sector of Commercial Space Operations.

commercial space↗
NASA NTRS2017

Automation of POST Cases via External Optimizer and "Artificial p2" Calculation

During early conceptual design of complex systems, speed and accuracy are often at odds with one another. While many characteristics of the design are fluctuating rapidly during this phase there is nonetheless a need to acquire accurate data from which to down-select designs as these decisions will have a large impact upon program life-cycle cost. Therefore enabling the conceptual designer to produce accurate data in a timely manner is tantamount to program viability. For conceptual design of launch vehicles, trajectory analysis and optimization is a large hurdle. Tools such as the industry standard Program to Optimize Simulated Trajectories (POST) have traditionally required an expert in the loop for setting up inputs, running the program, and analyzing the output. The solution space for trajectory analysis is in general non-linear and multi-modal requiring an experienced analyst to weed out sub-optimal designs in pursuit of the global optimum. While an experienced analyst presented with a vehicle similar to one which they have already worked on can likely produce optimal performance figures in a timely manner, as soon as the "experienced" or "similar" adjectives are invalid the process can become lengthy. In addition, an experienced analyst working on a similar vehicle may go into the analysis with preconceived ideas about what the vehicle's trajectory should look like which can result in sub-optimal performance being recorded. Thus, in any case but the ideal either time or accuracy can be sacrificed. In the authors' previous work a tool called multiPOST was created which captures the heuristics of a human analyst over the process of executing trajectory analysis with POST. However without the instincts of a human in the loop, this method relied upon Monte Carlo simulation to find successful trajectories. Overall the method has mixed results, and in the context of optimizing multiple vehicles it is inefficient in comparison to the method presented POST's internal optimizer functions like any other gradient-based optimizer. It has a specified variable to optimize whose value is represented as optval, a set of dependent constraints to meet with associated forms and tolerances whose value is represented as p2, and a set of independent variables known as the u-vector to modify in pursuit of optimality. Each of these quantities are calculated or manipulated at a certain phase within the trajectory. The optimizer is further constrained by the requirement that the input u-vector must result in a trajectory which proceeds through each of the prescribed events in the input file. For example, if the input u-vector causes the vehicle to crash before it can achieve the orbital parameters required for a parking orbit, then the run will fail without engaging the optimizer, and a p2 value of exactly zero is returned. This poses a problem, as this "non-connecting" region of the u-vector space is far larger than the "connecting" region which returns a non-zero value of p2 and can be worked on by the internal optimizer. Finding this connecting region and more specifically the global optimum within this region has traditionally required the use of an expert analyst.

Dees, Patrick D.↗
NASA NTRS2004

HEC Applications on Columbia Project

NASA's Columbia system consists of a cluster of twenty 512 processor SGI Altix systems. Each of these systems is 3 TFLOP/s in peak performance - approximately the same as the entire compute capability at NAS just one year ago. Each 512p system is a single system image machine with one Linunx O5, one high performance file system, and one globally shared memory. The NAS Terascale Applications Group (TAG) is chartered to assist in scaling NASA's mission critical codes to at least 512p in order to significantly improve emergency response during flight operations, as well as provide significant improvements in the codes. and rate of scientific discovery across the scientifc disciplines within NASA's Missions. Recent accomplishments are 4x improvements to codes in the ocean modeling community, 10x performance improvements in a number of computational fluid dynamics codes used in aero-vehicle design, and 5x improvements in a number of space science codes dealing in extreme physics. The TAG group will continue its scaling work to 2048p and beyond (10240 cpus) as the Columbia system becomes fully operational and the upgrades to the SGI NUMAlink memory fabric are in place. The NUMlink uprades dramatically improve system scalability for a single application. These upgrades will allow a number of codes to execute faster at higher fidelity than ever before on any other system, thus increasing the rate of scientific discovery even further

Taft, Jim↗
NASA NTRS2018

GMI-IPS: Processing & Visualization Software Used in ATom DC-8 Aircraft Studies

NASA's Atmospheric Tomography Mission (ATom) deployed in each of the four seasons during 2016-2018, the DC-8 aircraft in order to establish global-scale datasets intended to improve the representation of chemically reactive gases in global atmospheric chemistry models (ACMs). The Global Modeling Initiative (GMI) executed simulations for each ATom flight using the GMI Chemistry Transport Model (GMI-CTM) to provide species concentrations of chemical gases along the DC-8 flight transects. To solve the problem of translating the GMI-CTM simulation data to the unique spatial resolutions of each ATom flight, the GMI ICARTT Processing Software (GMI-IPS) was developed.The GMI-IPS is written in Python and provides data processing, flight extraction, and visualization support for aircraft research projects using ICARTT format, which is a standard format for airborne instrument data. Additionally, the GMI-IPS interpolates global gridded model data from Hierarchical Data Format (HDF) to ICARTT compatible flight transects. Software classes for instruments and collections provided by the ATom DC-8 aircraft such as MER10, MMS, etc. are derived from a common base class. Other functionality provided by the GMI-IPS are: deriving missing flight entries along a transect, reading ICARTT entries from file, and providing Python data structures for storing flight and model information, and more.The GMI-IPS is GIT source controlled, has approximately 30,000 lines of code, and supports parallelization across data collections. It delivered GMI-CTM data for more than forty distinct DC-8 aircraft flights that took place under ATom. The output ICARTT files adhere to format standard V1.1, and pass the scan utility provided by NASA LaRC Airborne Science Data for Atmospheric Composition. This presentation will include a software and methods overview, and results from ATom, including assessments using the GMI-CTM showing how well observations from ATom flight transects represent a broader region.

Damon, M. R.↗
NASA NTRS2004

Surface Modeling and Grid Generation for Iced Airfoils (SmaggIce)

Many of the troubles associated with problem solving are alleviated when there is a model that can be used to represent the problem. Through the Advanced Graphics and Visualization (G-VIS) Laboratory and other facilities located within the Research Analysis Center, the Computer Services Division (CSD) is able to develop and maintain programs and software that allow for the modeling of various situations. For example, the Icing Research Branch is devoted to investigating the effect of ice that forms on the wings and other airfoils of airplanes while in flight. While running tests that physically generate ice and wind on airfoils within the laboratories and wind tunnels on site are done, it would be beneficial if most of the preliminary work could be done outside of the lab. Therefore, individuals from within CSD have collaborated with Icing Research in order to create SmaggIce. This software allows users to create ice patterns on clean airfoils or open files containing a variety of icing situations, manipulate and measure these forms, generate, divide, and merge grids around these elements for more explicit analysis, and specify and rediscretize subcurves. With the projected completion date of Summer 2005, the majority of the focus of the Smagglce team is user-functionality and error handling. My primary responsibility is to test the Graphical User Interface (GUI) in SmaggIce in order to ensure the usability and verify the expected results of the events (buttons, menus, etc.) within the program. However, there is no standardized, systematic way in which to test all the possible combinations or permutations of events, not to mention unsolicited events such as errors. Moreover, scripting tests, if not done properly and with a view towards inevitable revision, can result in more apparent errors within the software and in effect become useless whenever the developers of the program make a slight change in the way a specific process is executed. My task therefore requires a brief yet intense study into GUI coverage criteria and creating algorithms for GUI implementation. Nevertheless, there are still heavily graphical features of SmaggIceSmaggIce that must be either corrected or redesigned before its release. A particular feature of SmaggIce is the ability to smooth out curves created by control points that form an arbitrary shape into something more acquiescent to gridding (while maintaining the integrity of the data). This is done by a mathematical model known as Non-Uniform Rational B-Spline (NURBS) curves. Existing NURBS code is written in FORTRAN-77 with static arrays for holding information. My new assignment is to allow for dynamic memory allocation within the code and to make it possible for the developers to call out functions from the NURBS code using C.

Hammond, Brandy M.↗
DOE OSTI2020

Custom NEON AOP reflectance mosaics and maps of shade masks, canopy water content

This mosaic of visible to shortwave infrared (VSWIR) data was derived from the assignable asset NEON AOP radiance data that was collected by LBNL’s Watershed Function SFA during the summer of 2018 (DOI: 10.15485/1617204). This atmospheric correction was completed to take into account site-specific terrain variability in the 334 km2 survey area centered around Crested Butte, CO. The atmospheric correction was completed using ACORN atmospheric correction software executed on 200 x 200 pixel kernels rather than line by line in order to capture local flight altitude conditions. Manual cloud delineation removed any small shaded areas that occurred within the data collection areas. Mosaics were developed based on preference for days that were in close timing proximity to the coincident ground campaign and with mosaicing criteria that minimized the angle between the sun and the sensor to retrieve the most consistent reflectance (min_phase_refl_tiled). Finally, we generated shade masks based on the geometry between the sun angle at time of flight, the ground surface, and the sensor. Here we provide the orthomosaiced estimated reflectance data (min_phase_refl_tiled.tif), canopy water content (wtrl), estimated atmospheric water vapor (wtrv), the observational data (obs) for this particular mosaic, the estimated visibility (vis), shade masks derived from the digital surface elevation model (shade) and the digital terrain model (shade_tch) added to the canopy height model (DOI: 10.15485/1617203), and a wavelength metadata file. Each image file is provided as a GeoTiff with internal tiling and LZW compression. These data can also be found on Google Earth Engine for extraction, download, and analysis of smaller extents (Google Earth Engine data is linked in external link table).

2018 NEON and 2025 CHESS Campaigns↗
NASA NTRS1992

The VLBA correlator: Real-time in the distributed era

The correlator is the signal processing engine of the Very Long Baseline Array (VLBA). Radio signals are recorded on special wideband (128 Mb/s) digital recorders at the 10 telescopes, with sampling times controlled by hydrogen maser clocks. The magnetic tapes are shipped to the Array Operations Center in Socorro, New Mexico, where they are played back simultaneously into the correlator. Real-time software and firmware controls the playback drives to achieve synchronization, compute models of the wavefront delay, control the numerous modules of the correlator, and record FITS files of the fringe visibilities at the back-end of the correlator. In addition to the more than 3000 custom VLSI chips which handle the massive data flow of the signal processing, the correlator contains a total of more than 100 programmable computers, 8-, 16- and 32-bit CPUs. Code is downloaded into front-end CPU's dependent on operating mode. Low-level code is assembly language, high-level code is C running under a RT OS. We use VxWorks on Motorola MVME147 CPU's. Code development is on a complex of SPARC workstations connected to the RT CPU's by Ethernet. The overall management of the correlation process is dependent on a database management system. We use Ingres running on a Sparcstation-2. We transfer logging information from the database of the VLBA Monitor and Control System to our database using Ingres/NET. Job scripts are computed and are transferred to the real-time computers using NFS, and correlation job execution logs and status flow back by the route. Operator status and control displays use windows on workstations, interfaced to the real-time processes by network protocols. The extensive network protocol support provided by VxWorks is invaluable. The VLBA Correlator's dependence on network protocols is an example of the radical transformation of the real-time world over the past five years. Real-time is becoming more like conventional computing. Paradoxically, 'conventional' computing is also adopting practices from the real-time world: semaphores, shared memory, light-weight threads, and concurrency. This appears to be a convergence of thinking.

Wells, D. C.↗
NASA NTRS2024

Discrete Event Simulation-Based Timeline Validation Using R2U2

The Gateway Vehicle Systems Manager (VSM), the top-level software control system in a distributed, hierarchical Autonomous System Management Architecture is, like most modern spacecraft software control systems, heavily data-driven. For example, schedules (timelines) will be developed on the ground and, due to the high degree of autonomy, contain complex procedures involving conditional branching, variable timing, and resource contention resolution. In order to verify that an uploaded timeline will function correctly, it is necessary to explore the feasible set of possible executions. While it is possible to test a timeline using a mission simulation, the complexity of the system and duration of a timeline limits the number of trials and therefore the test coverage. To address this problem, the VSM team is using a discrete event system model that can rapidly generate from a timeline sets of event sequences using Monte Carlo techniques. To achieve rapid and trustworthy checking of the event sequences, we use an offline version of the runtime model checking tool R2U2. This presentation describes the approach the VSM team is using to implement the discrete event simulation and evaluate event sequences using R2U2. The presentation will discuss: 1. Description of the timelines by VSM in the context of VSM operations 2. Expansion of a timeline into a sequence of atomic events 3. Adjustment, in the Monte Carlo environment, of an event sequence to account for uncertainty, external events, and failures 4. Definition of R2U2 input and mission-time linear temporal logic files 5. Generation and use of R2U2 verdict sequences 6. Lessons learned and future work

Verification↗
DOE OSTI2023

Hydroscanner: Instrumentation for Water Ingress Imaging in Photovoltaic Module Packaging Materials

A new iteration of the Hydroscanner prototype was designed and built during the execution of the contract. Compared to the previous designs, the communication port was changed from ethernet to USB C, since it provides a more seamless integration as a peripheral unit. An additional advantage is that one single port can be used for both communication and power up of the infrared camera. Although the power requirements are higher than the typical amount provided by a laptop computer, the camera can be run as a peripheral from a docking station when connected to a thunderbolt charging port. The software interface was modified to accommodate two imaging modes, an 8-bit and 14-bit image display. The 8-bit images use a custom colorization scheme that divides all pixels in the image into bins of equal width, such that images containing a wide range of brightness display the intermediate pixel intensities in greyscale values that enhance the contrast. The 14-bit images provide the direct readout from the focal plane array of the camera and can be saved as a text file for later processing in other software packages (MATLAB, Python).

47 OTHER INSTRUMENTATION↗