Search NASA⌕ Search

SEARCH · Search NASA

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 253 records · Page 14

A Framework for the Analysis of Compiler Optimizations

Compilers transform program source code to machine executable code. During this transformation, they perform a number of compiler optimizations to improve the performance of the generated executable code. Importantly, applying those optimizations depends on the source code structure, such as the parallel programming model used to parallelize an algorithm. Often, implementations of the same algorithm with different programming models have vastly different performance because the compiler optimized them differently. We create FAROS, a framework to structure and automate the analysis of compiler optimizations on programs. FAROS automates the building process, execution profiling, and analysis of compiler optimization of programs, through a configuration interface. It outputs compiler optimization reports to show which optimizations applied to which line of source code, leveraging compilation remarks output by the compiler. Also, FAROS supports benchmarking performance of different program versions by collecting execution time results. In this first release of FAROS, we provide a configuration file to analyze compiler optimization differences for sequential vs OpenMP compilation, including 38 programs consisting of HPC proxy/mini/large applications, and NAS and Rodina kernels for analysis.

Georgakoudis, Giorgis↗

FY24 Progress Report: SRNL Analysis of ICCWR LCM and WAMS data for Corrosion and Cracking

Algorithms for Machine Learning (ML) and data analysis for the 3013 Surveillance Program have been developed in an ongoing collaborative effort by the Savannah River National Laboratory (SRNL) and the University of South Carolina (USC). The objective of the algorithms is to automate the identification of corrosion and crack formation in the Inner Container Closure Weld Region (ICCWR) of the canister system used to store Pu-bearing material. Data for corrosion and cracking is collected from large binary files generated by a Laser Confocal Microscope (LCM), the Wide Area 3D Measurement System (WAMS), or,in a recent proposal, by a Scanning Electron Microscope (SEM). The ML software uses the physical attributes in the data files (e.g., one or more of: height, color, and 16-bit grayscale values as functions of position in a plane projection) to detect signs of surface corrosion and cracking after being trained on similar data, with the features to be detected. Although the initial scope included screening for broader indicators of corrosion, e.g., pitting, identification of potential cracks was prioritized for the past several years at the request of program leadership. Labeled training data is essential to developing the ML algorithm, and enhancements to data labeling capability have been developed to address this essential precursor to application of ML routines. Efficient labeling is particularly important in view of the large volume of data required to train ML algorithms and the relative rarity of cracks in the ICCWR data set. The updated program will read binary data from either LCM, WAMS or SEM files, interrogate data attributes, facilitate user labeling of data for training ML algorithms, execute ML algorithms, output parameters from trained ML algorithms, report ML model accuracy with respect to labeled data, and generate graphical representations for various analyses. In FY24, hourglass neural networks (HNNs) that were initiated in FY22 were further developed and tested using available LCM data, and their performance was tested against that of the alternative U-Net Neural Network algorithm structure. HNNs along with previously developed Convolutional Neural Networks (CNNs) and Deep Neural Networks (DNNs) comprise a suite of ML tools for identification of cracks in the ICCWR

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Small Interactive Image Processing System (SMIPS) system description

The Small Interactive Image Processing System (SMIPS) operates under control of the IBM-OS/MVT operating system and uses an IBM-2250 model 1 display unit as interactive graphic device. The input language in the form of character strings or attentions from keys and light pen is interpreted and causes processing of built-in image processing functions as well as execution of a variable number of application programs kept on a private disk file. A description of design considerations is given and characteristics, structure and logic flow of SMIPS are summarized. Data management and graphic programming techniques used for the interactive manipulation and display of digital pictures are also discussed.

Moik, J. G.↗

The Trick Simulation Toolkit: A NASA/Opensource Framework for Running Time Based Physics Models

The Trick Simulation Toolkit is a simulation development environment used to create high fidelity training and engineering simulations at the NASA Johnson Space Center and many other NASA facilities. Its purpose is to generate a simulation executable from a collection of user-supplied models and a simulation definition file. For each Trick-based simulation, Trick automatically provides job scheduling, numerical integration, the ability to write and restore human readable checkpoints, data recording, interactive variable manipulation, a run-time interpreter, and many other commonly needed capabilities. This allows simulation developers to concentrate on their domain expertise and the algorithms and equations of their models. Also included in Trick are tools for plotting recorded data and various other supporting utilities and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX computer operating systems. This paper describes Trick's design and use at NASA Johnson Space Center.

Penn, John M.↗

Ground Segment Operations Concept for the Orion Artemis-2 Optical Communications System

The ACCESS Project (formerly Space Network) will implement an optical communications ground segment to support the Orion Artemis II Optical Communications (O2O) demonstration as part of the next manned human spaceflight mission to the moon, Artemis II. O2O implements laser communication (lasercomm) technology for operational use on the Orion series of spacecraft, as a development test objective (DTO), in order to demonstrate the feasibility and operational utility of lasercomm for human spaceflight missions. O2O consists of three segments: Space Segment, Ground Segment, and Operations Segment. The Space Segment consists of the Space Terminal Element and the Orion spacecraft. The Space Terminal Element effort is managed by the GSFC Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) project in collaboration with MIT Lincoln Laboratory. The Ground Segment consists of an optical ground terminal (GT) at the White Sands Complex (WSC), which is being developed in collaboration with MIT Lincoln Laboratory, the Ground Segment Operations and Analysis (GSOA) element and Ground Data Element (GDE), and a second optical GT in the Optical Communications Telescope Laboratory (OCTL) at the JPL Table Mountain Facility. The Operations Segment consists of the Artemis II Mission Control Center (MCC), the Lasercomm Space Terminal Console (LSTC), and the Lasercomm Link Planning & Analysis Center (LPAC), all located at the Johnson Space Center (JSC). O2O utilizes pulse-position modulation (PPM) direct-to-earth services resulting in an 80 Mbps downlink data rate from lunar orbit. The O2O concept of operations is to provide optical services for a minimum of 1 hour per day for each day of the Artemis II mission. O2O will utilize a 10-20 Mbps uplink data rate and 40-260 Mbps downlink data rate, depending on the Artemis II mission phase. The ACCESS project will also provide a centralized mission data interface for user data distribution and storage to the MCC and perform planning and scheduling of services in coordination with the Operations Segment for the O2O Ground Segment. The O2O Ground Segment will support the following O2O mission phases: Pre-Mission Planning; Daily Operations Planning; Event Execution; and Post-Pass Reporting. O2O will be used to exchange data files between Orion and the MCC and to distribute real-time video through the optical downlink service to the MCC; which would not be possible without the high-bandwidth link that O2O will provide to Orion. In this paper, I will discuss the O2O Ground Segment development approach and how it will support these critical O2O functions: plan and schedule the contact; acquire and track the optical link; flow information bidirectionally; distribute information; and control and accommodate the system.

optical communications↗

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗

Model Data for the Mesh Convergence Study Demonstrating Benefits of Mixed-polyhedral Mesh in Integrated Hydrology Simulations

This archived model data is related to a study introducing a unique method that employs a stream-aligned mixed-polyhedral mesh to effectively and accurately represent river valleys, stream corridors, and narrow engineered channels in integrated hydrology simulations. The study finds that utilizing stream-aligned mixed-polyhedral meshes in integrated hydrology simulations achieves accuracy on par with a finely refined TIN-based mesh while markedly diminishing computational costs. This archive contains scripts and data files needed to generate the ATS model input, including mesh and ATS input files, for all mesh scenarios using the Watershed Workflow package. Additionally, this archive also provides key outputs from the model simulations that are used in the analysis and post-processing scripts to reproduce figures in the manuscript. The Watershed Workflow package is implemented in Python3. The Jupyter notebooks can be executed through multiple open-source tools, for example, Anaconda Jupyter Lab, VS Studio Code, etc. Other data files include CSV and HDF5 files, which can be read through Python scripts. The input files for the ATS model, open-source integrated hydrology, and transport model are in XML format and can be edited in any commonly used text editors.

54 ENVIRONMENTAL SCIENCES↗

Demonstration of the On-the-Fly Shielding Analysis Method: Spent Fuel and Waste Disposition

This report documents work performed supporting the US Department of Energy (DOE) Office of Nuclear Energy (NE) Spent Fuel and Waste Disposition (SFWD) Integrated Waste Management activities under work breakdown structure element 1.08.02.04.01, “Data and Tools Development, Validation, and Maintenance.” In particular, this report fulfills milestone M3SF-21OR020401016, “Implement on-the-fly dose analysis methodology in UNF-ST&DARDS” within work package SF-21OR02040101, “Commercial SNF Characterization - ORNL.” The Used Nuclear Fuel - Storage, Transportation & Disposal Analysis Resource and Data System (UNFST& DARDS) enables automated dose rate calculations for spent nuclear fuel (SNF) transportation packages and storage casks using a Monte Carlo radiation transport code. The explicit method uses a detailed model of the SNF system and its contents. Therefore, a dose rate calculation is required for each as-loaded transportation package or storage cask because the SNF assemblies within a canister typically have unique irradiation characteristics. An alternate method, referred to as the “on-the-fly” shielding analysis method, has been proposed that requires only a set of Monte Carlo dose rate calculations for each transportation packaging/storage cask design. The results of the Monte Carlo dose rate calculations are independent of the SNF assembly irradiation and decay characteristics. The dose rate values may then be combined with the radiation source strength of the SNF assemblies associated with a particular transportation packaging/storage cask design to determine actual dose rates. This report presents on-the-fly dose rate calculations for a representative SNF storage cask and verification of the on-the-fly dose rate calculation results by comparison with reference dose rate calculations using the explicit Monte Carlo dose rate calculation. The on-the-fly shielding analysis method was implemented in UNF-ST&DARDS. A Python program was developed to process the MAVRIC dose rate results obtained by source particle type, energy group, and fuel geometry region. A Python processor created binary files, which were saved as a special UNF-ST&DARDS library for on-the- fly shielding analyses. UNF-ST&DARDS uses the precalculated on-the-fly binary libraries generated by the Python data processor and directly executes the Python code for on-the-fly dose analysis. This Python code unzips the pre-generated binary files mentioned above, reads the data, and combines them with user-specified sources for dose and uncertainty calculations. The Python programs were verified using Excel calculations and by comparison with the values obtained with the MAVRIC post-processing utilities applied to the 3dmap files. This method can currently be used to determine dose rates for as-loaded HI-STORM FW storage casks. The UNF-ST&DARDS analysis wizard for on-the-fly shielding analysis is described in this report.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Field and Model Data Associated with the Manuscript “Drivers of Streamflow Intermittency in Humid Regions: 2. Evaluating Controls on Flow Persistence in an Urbanized Catchment”

This package contains field data, modeling files, and scripts supporting the investigation of the drivers of streamflow intermittency in an urbanized catchment. It includes the field data collected from electrical resistivity tomography (ERT) surveys, distributed temperature sensing (DTS), continuous self-potential (SP) monitoring, groundwater and stilling well. In addition, it contains the data and results of the coupled water- and electrical-flow model developed using the COMSOL Multiphysics and Advanced Terrestrial Simulator (ATS), as well as software files and Jupyter notebooks used to process the data and generate figures in the manuscript submitted for peer review. The data archive is organized in the following directories: 1) Climate Includes hourly precipitation and daily evapotranspiration time series (2024 – 2025) provided as CSV files, alongside a text file detailing dataset units. 2) Coupled_model Field_Application subfolder contains the ATS XML input scripts, data files, output data for the SP site. It also contains the Jupyter notebook (Plot_final_calib.ipynb) to visualize the results of the modeled SP, stream-groundwater exchange and moisture content. The flow model simulation is executed using the ATS XML scripts and the included Python script (generate_data_set.py) to convert ATS output to COMSOL-ready input. COMSOL Multiphysics template (.m can only be used with COMSOL with MATLAB) is executed using the ATS output data to simulate the potential field. 3) Discharge Includes the electrical conductivity (EC) time series (provided as CSV files) from salt slug injections. It also includes the Jupyter notebook (Discharge_process.ipynyb) used to estimate discharge. All discharge measurements collated into rating_curve_processed.csv 4) DTS Contains collated DTS data including raw Stokes and anti-Stokes measurement (provided as .h5 file). It also includes DTS processing.ipynb, a Jupyter notebook for calibrating the DTS data using dts_calibration Python package. cooler_calibration.csv is the DTS calibration CSV used in the calibration sequence. 5) ERT Contains raw resistivity data (provided as CSV files), spatial location of each of the electrodes (provided as CSV files), and files used for the resistivity inversion. 6) Slug_test Includes the slug test data at all the groundwater wells provided as CSV files, as well as the Jupyter notebook (Slug_test.ipynb) for calculating hydraulic conductivity. 7) SP Contains the SP data collected in field at the SP sites (provided as CSV files). 8) Well_data Contains two subfolders: 1) Raw, which provides unprocessed pressure, electrical conductivity and temperature timeseries downloaded from the loggers in all the groundwater and stilling wells, and 2) Processed, which contains sorted, QA/QC timeseries data for each well. The data archive also contains data_process.ipynb, a Jupyter notebook used for field data analysis and generating figures (plotting well, SP, climate, and discharge data, as well as calculating head gradient at sites with nested groundwater wells). Note: Code files (.ipynb, .py, .xml) can be opened in any standard code editor, .exo file can be viewed using Paraview, .h5 files can be opened using HDFView software and h5py Python package, and .resipy file can be opened with the open-source ResIPy software.

ATS↗

SpaceCube Demonstration Platform

A document discusses how the HST SM4 SpaceCube flight spare was modified to create an experiment called the Space- Cube Demonstration Platform (SC DP) for use on the MISSE7 Space Station payload (in collaboration with NRL). It is designed to serve as an on-orbit platform for demonstrating advanced fault tolerance technologies. A simple C&DH (command and data handling) system was developed for the Virtex4 FPGAs (field programmable gate arrays). Both Virtex4s on each SpaceCube run the same program, and both receive incoming telemetry. The rad-hard service FPGA performs simple error checking to verify that the incoming telemetry is valid. The SpaceCube framework was modified to allow for new program files to be sent from the ground, to be stored on the SpaceCube, and to be executed through ground commands. Each SpaceCube Virtex4 FPGA has resources set aside for experiments that are functionally isolated from the C&DH system. The experiments communicate to the C&DH system through a set of dual port memories, and this area is where the fault-tolerance experiments are executed. With the use of Xilinx commercial Virtex4 FX60 FPGAs, the fault tolerant framework allows the system to recover from radiation upsets that occur in the rad-soft parts (Virtex4 FPGA logic, embedded PPCs in Virtex4 FPGAs, SDRAM and Flash), the C&DH system that runs simultaneously on both Virtex4 FPGAs that uses a robust telemetry packet structure, checksums, and the rad-hard service FPGA to validate incoming telemetry. The ability to be reconfigured from the ground while in orbit is a novel benefit, as well as is the onboard compression capabilities that allow compressed files from the ground to be uploaded to the SpaceCube.

Espinosa, Daniel↗

Model Data Archive for Manuscript Titled "Evaluation of a Coupled Surface–Subsurface Hydrologic Model Using Dense Water‑Level Sensors in a Mixed Urban–Rural Watershed"

This archive provides scripts, input files, and datasets used for the implementation and evaluation of a fully coupled surface–subsurface hydrologic model in the Neches River Basin, southeast Texas. The study uses the Advanced Terrestrial Simulator (ATS) to simulate coupled surface–subsurface hydrologic processes over a mixed urban–rural watershed and evaluates model performance using a dense network of 136 in situ water-level sensors, nine U.S. Geological Survey (USGS) stream gauges, and SSEBop-derived evapotranspiration estimates during the period October 2014–June 2024. The workflow is implemented primarily in Python 3 using the Watershed Workflow package. The Jupyter notebooks can be executed using open-source software such as Anaconda JupyterLab or Visual Studio Code. Other data files include TXT, CSV, XML, SHP, TIF, NetCDF, HDF5, and ExodusII files, which can be processed using the provided Python scripts. ATS input files are provided in XML format and can be edited using any commonly used text editor. This archive contains: *Scripts and input files used to generate the ATS model setup, including watershed discretization, mesh generation, parameter mapping, and model configuration. *Jupyter notebooks used for preprocessing observational data, evaluating streamflow, water levels, and evapotranspiration, computing performance metrics, and generating the figures presented in the manuscript. *ATS simulation outputs and processed observational datasets, including OneRain and DD6 water-level sensors, USGS streamflow observations, GIS data, and supporting spatial datasets used throughout the study.

Dense water-level sensor network↗

New Features of the NEQAIR Radiation Code

The longest-lived code for predicting shock layer radiation, NEQAIR, is now in its 5th decade of service. Substantial changes to the code have been made over the previous decade, the most recent report of which was at the 5th Workshop on Radiation in High Temperature Gases in 2014, for the version referred to as NEQAIR14. This paper will review some of the improvements made to the NEQAIR code since then, which is now at v15.2. Some of these features are discussed briefly below. NEQAIR15 and subsequent versions have enabled parallel evaluation of multiple lines of sight. This is accomplished by utilizing the HDF5 file format and placing multiple lines into a single file, LOS.h5, which is used for both input and output. This approach enables straightforward parallel execution both over the number of lines of sight and the number of points per line. For large problems, runtime reduces linearly with the number of nodes deployed since each line is processed independently by a subset of MPI ranks. Three applications of the multi-line solver are discussed. The first has to do with performing loosely coupled radiation-flowfield solutions. In this case the computed absorption and emission coefficients are used to evaluate the total energy absorbed or emitted at each point, allowing evaluation of the volumetric source term in the flowfield. The second computation is for obtaining heat flux from nonuniform flows, which require integration over spherical co-ordinates. These are of particular interest for evaluating radiation on the vehicle backshell. This 3D option improves the angular integration scheme and allows adaptive line selection that together reduce the number of lines required by about an order of magnitude. The final application is for remote observation, which is essentially the 3D integration problem over a small solid angle. For all three of these computations, data can be stored in the HDF5 file which allows a NEQAIR run to be restarted when it times out, or to add atmospheric absorption or instrument scan functions. An additional level of parallelism is enabled in NEQAIR15.2 using GPU routines. The GPU parallelism has realized up to 8x speed-up when running on a single core but diminishes as CPU parallelism is increased. For running multi-line simulations, it may be easier to reserve a large number of CPU nodes than to obtain the number of GPU nodes required for similar performance. A GUI, known as NEQTPY, allows for reading and creating input files, running NEQAIR, and displaying results. A significant feature of NEQTPY is the ability to perform spectral fits to data. The fits can operate on a single line spectrum (radiance vs. wavelength) or a 3D input file with multiple columns of data. Other new features include improved constants, additional species, more detailed non-Boltzmann modelling, advanced user controls, the ability to read and calculate spectra from HITRAN datafiles, photodissociation and photoionization cross-sections. A “fast” automatic grid option may reduce the size and time of spectral calculations while still maintaining good accuracy for total heat flux.

Brett A Cruden↗

From 2D to 4D: a containerized workflow and browser to explore dynamic chromatin architecture

Background Characterizing the physical organization of the genome is essential for understanding long-range gene regulation, chromatin compartmentalization, and epigenetic accessibility. Hi-C experiments generate two-dimensional (2D) genome-wide contact maps of chromatin interactions by capturing the spatial proximity between genomic loci, which reveal interaction frequencies but lack the spatial resolution needed to interpret the three-dimensional (3D) genome structure(s). Emerging evidence suggests that epigenetic regulation is closely linked to 3D genome architecture, and that structural changes over time (4D) drive key biological processes in development, disease, and environmental response. Thus, integrating 3D structure with functional data is critical for a more complete understanding of genome regulation. Previous work, most notably the 4DHiC chromosome modeling framework, has shown that physical multi-dimensional modeling approaches rooted in polymer physics and molecular dynamics can resolve these structures at biologically meaningful resolutions by integrating temporal Hi-C data with physical constraints to uncover dynamic chromosome reorganization. Thus, molecular dynamics simulations, constrained by Hi-C contact matrices, can resolve fine-scale structural changes and reveal functionally significant transitions in chromatin conformation. Results Herein, we present the 4D Genome Browser Workflow (4DGBWorkflow) and the 4D Genome Browser (4DGB). The algorithm is based on the 4DHiC method, and the containerized tool is an end-to-end workflow that can transform, filter, and view 4D epigenomics and chromatin datasets, allowing non-specialists to apply three-dimensional modeling principles to diverse datasets and experimental conditions. The software executes on a laptop running macOS, Linux or Windows. From input Hi-C files (.hic), the 4DGBWorkflow produces 3D reconstructions of chromosomes, integrates the reconstruction with track data (e.g., epigenetic marks, transcriptome profiles), and provides comparative visualization of the results in a single workflow. Conclusions The 4DGBWorkflow and 4D Genome Browser are open-source tools for comparative analysis and visualization of 4D chromosome datasets, including chromatin architecture and epigenomic signals. Automatic integration of Hi-C data with molecular dynamics democratizes the construction of time resolved 3D genome structures, simplifying complex simulations and data integration schemes.

3D Genome Browser↗

Integrated verification and testing system (IVTS) for HAL/S programs

The IVTS is a large software system designed to support user-controlled verification analysis and testing activities for programs written in the HAL/S language. The system is composed of a user interface and user command language, analysis tools and an organized data base of host system files. The analysis tools are of four major types: (1) static analysis, (2) symbolic execution, (3) dynamic analysis (testing), and (4) documentation enhancement. The IVTS requires a split HAL/S compiler, divided at the natural separation point between the parser/lexical analyzer phase and the target machine code generator phase. The IVTS uses the internal program form (HALMAT) between these two phases as primary input for the analysis tools. The dynamic analysis component requires some way to 'execute' the object HAL/S program. The execution medium may be an interpretive simulation or an actual host or target machine.

Senn, E. H.↗

Khoros software specification format and interoperability

Khoros defines formats for User Interface Specification (UIS) and Program Specification (PS) files. From such files, its code generator, Ghostwriter, creates source files and documentation. The great advantage of the system is that the code fragments that make up part of the PS file are purely generic. All Khoros-related code is created by the code generator; this includes all user interface code. As a matter of fact, both specification files are very generic in nature. Thus, one could imagine using it as the basis for other software systems. A case is made that writing a code generator that would create IRAF-compatible code from the Khoros UIS and PS files is fairly trivial. Another aspect of the Khoros system conventions concerns the way execution commands are generated by the user interface and the actual syntax of those commands. The protocols are such that interoperability at the level of executable modules is readily possible.

Rots, A. H.↗

Applying Standard Interfaces to a Process-Control Language

A method of applying open-operating-system standard interfaces to the NASA User Interface Language (UIL) has been devised. UIL is a computing language that can be used in monitoring and controlling automated processes: for example, the Timeliner computer program, written in UIL, is a general-purpose software system for monitoring and controlling sequences of automated tasks in a target system. In providing the major elements of connectivity between UIL and the target system, the present method offers advantages over the prior method. Most notably, unlike in the prior method, the software description of the target system can be made independent of the applicable compiler software and need not be linked to the applicable executable compiler image. Also unlike in the prior method, it is not necessary to recompile the source code and relink the source code to a new executable compiler image. Abstraction of the description of the target system to a data file can be defined easily, with intuitive syntax, and knowledge of the source-code language is not needed for the definition.

Berthold, Richard T.↗

Facilitating the Portability of User Applications in Grid Environments

Grid computing promises the ability to connect geographically and organizationally distributed resources to increase effective computational power, resource utilization, and resource accessibility. For grid computing to be successful, however, users must be able to easily execute the same application on different resources. Different resources, however, may be administered by different organizations with different software installed, different file system structures, and different default environment settings. Even within the same organization, the set of software installed on a given resource is in constant flux with additions, upgrades, and removals. Users cannot be expected to understand all of the idiosyncrasies of each resource they may wish to execute jobs on, thus must be provided with automated assistance. This paper describes a new OGSI-compliant grid service (the Portability Manager) that has been implemented as part of NASA's Information Power Grid (IPG) project to automatically estab!ish the execution environment for user applications.

Kolano, Paul Z.↗

Model data for a watershed-scale study in the Portage River Basin (OH) examining the effects of subsurface drainage on the hydrologic response of an agricultural watershed.

This study builds on Rathore et al. (2024, WRR) and investigates the role of artificial tile-drainage on various aspects of watershed hydrological response, with a particular focus on peakflow. The model-data for the original modeling-focused paper (Rathore et al., 2024, WRR) is archived at Rathore et al. (2024, ESS-DIVE). Hence, this model-data archive provides scripts that are specific to this study that includes model updates, processing and analysis scripts. For details and models files of original model, readers are referred to Rathore et al. (2024, ESS-DIVE). The key difference between the model configuration in this study and Rathore et al. (2024, WRR) is that the tile drains are applied to the entire domain, to study the impact of tile-drains on different aspects of hydrological response. Additional scenario considering intensified precipitation after a dry period was also simulated. The Watershed Workflow package is implemented in Python3. The Jupyter notebooks can be executed through multiple open-source tools, for example, Anaconda Jupyter Lab, VS Studio Code, etc. Other data files include CSV and HDF5 files, which can be read through Python scripts.

54 ENVIRONMENTAL SCIENCES↗