SEARCH · Search NASA

Results for “script”

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.

SourceResearch connectionFrom yearThrough year

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

At least 217 records · Page 12

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗

NASA NTRSDate not supplied

CFS Test Framework

cfs↗

DOE OSTI2017

Recent Improvements To CINDER2008 and Activation Analysis Tools

CINDER2008 is a transmutation code that calculates induced radioactivity for either reactor- or accelerator-driven radiation sources. Several Perl scripts have been developed to treat multi-cell problems in combination with either the radiation transport code MCNPX or a special version of MCNPX that writes residual nuclide tallies from model-based physics directly in the MCNPX output file. These scripts simplify the preparation of CINDER input, and can use CINDER output to prepare the source term for a subsequent MCNPX run to calculate dose rates due to activated material. In addition, these scripts support calculations with the transmutation codes SP-FISPACT and ORIHET-3. A number of improvements have been made to CINDER, its data libraries, and the Perl scripts, including (1) substantial corrections to the data libraries, (2) inclusion of recent revisions to USDOE HC-2/HC-3 thresholds and the corresponding thresholds for regulatory bodies in other countries, (3) the ability to run the CINDER accident analysis tool through the script input file, and (4) an easier way to write the script input file when treating a large number of cells. Some features of running CINDER and a number of example problems are discussed.

Micklich, Bradley J.↗

DOE OSTI2017

The laboratory environmental algae pond simulator (LEAPS) photobioreactor: Validation using outdoor pond cultures of Chlorella sorokiniana and Nannochloropsis salina

A bench-scale photobioreactor system, the Laboratory Environmental Algae Pond Simulator (LEAPS), was designed and constructed to simulate outdoor pond cultivation for a wide range of geographical locations and seasons. The LEAPS consists of six well-mixed glass column photobioreactors submerged in a temperature controlled waterbath (-2 °C to >60 °C) and illuminated from above by a programmable multicolor LED lighting system (0 to 2,500 µmol/m 2 -sec). Measured incident light intensities and water temperatures deviated from the respective light and temperature setpoints on average only 2.3% and 0.9%, demonstrating accurate simulation of light and temperature conditions measured in outdoor ponds. In order to determine whether microalgae strains cultured in the LEAPS exhibit the same linear phase biomass productivity as in outdoor ponds, Chlorella sorokiniana and Nannochloropsis salina were cultured in the LEAPS bioreactors using light and temperature scripts measured previously in the respective outdoor pond studies. For Chlorella sorokiniana, the summer season biomass productivity in the LEAPS was 6.6% and 11.3% lower than in the respective outdoor ponds in Rimrock, Arizona, and Delhi, California; however, these differences were not statistically significant. For Nannochloropsis salina, the winter season biomass productivity in the LEAPS was 9.2% higher than in the respective outdoor ponds in Tucson, Arizona, a difference shown to be not statistically significant. Potential reasons for the positive or negative divergence in LEAPS performance, relative to outdoor ponds, are discussed. To demonstrate the utility of the LEAPS in predicting productivity, two other strains – Scenedesmus obliquus and Stichococcus minor – were evaluated using the summer season script for Rimrock, Arizona. For both strains, the productivity was around 11.6 g/m 2 -day at 25 cm culture depth. In conclusion, the LEAPS is an accurate pond simulator and thus offers a reliable, fast, and cost-effective way to screen microalgae strains and operating conditions for high biomass productivity and co-product yields.

59 BASIC BIOLOGICAL SCIENCES↗

DOE OSTI2017

Charliecloud

Charliecloud is a set of scripts to let users run a virtual cluster of virtual machines (VMs) on a desktop or supercomputer. Key functions include: 1. Creating (typically by installing an operating system from vendor media) and updating VM images; 2. Running a single VM; 3. Running multiple VMs in a virtual cluster. The virtual machines can talk to one another over the network and (in some cases) the outside world. This is accomplished by calling external programs such as QEMU and the Virtual Distributed Ethernet (VDE) suite. The goal is to let users have a virtual cluster containing nodes where they have privileged access, while isolating that privilege within the virtual cluster so it cannot affect the physical compute resources. Host configuration enforces security; this is not included in Charliecloud, though security guidelines are included in its documentation and Charliecloud is designed to facilitate such configuration. Charliecloud manages passing information from host computers into and out of the virtual machines, such as parameters of the virtual cluster, input data specified by the user, output data from virtual compute jobs, VM console display, and network connections (e.g., SSH or X11). Parameters for the virtual cluster (number of VMs, RAM and disk per VM, etc.) are specified by the user or gathered from the environment (e.g., SLURM environment variables). Example job scripts are included. These include computation examples (such as a "hello world" MPI job) as well as performance tests. They also include a security test script to verify that the virtual cluster is appropriately sandboxed. Tests include: 1. Pinging hosts inside and outside the virtual cluster to explore connectivity; 2. Port scans (again inside and outside) to see what services are available; 3. Sniffing tests to see what traffic is visible to running VMs; 4. IP address spoofing to test network functionality in this case; 5. File access tests to make sure host access permissions are enforced. This test script is not a comprehensive scanner and does not test for specific vulnerabilities. Importantly, no information about physical hosts or network topology is included in this script (or any of Charliecloud); while part of a sensible test, such information is specified by the user when the test is run. That is, one cannot learn anything about the LANL network or computing infrastructure by examining Charliecloud code.

Priedhorsky, Reid↗

DOE OSTI2021

Optode Images, and Dissolved Oxygen Data from Sand and Sediment Flow-through Column Experiments associated with: "2-D Imaging of Dissolved Oxygen Concentration in Flow-Through Sediment Columns"

This data package is associated with the publication "2-D Imaging of Dissolved Oxygen Concentration in Flow-Through Sediment Columns" submitted to Frontiers in Water (Garayburu-Caruso et al., 2022). This work presents a novel application of planar optode technology to sediment columns that allows the study of well-constrained flow fields without the need to assume completely homogeneous flow. We introduce a flow-through column with the interior coated in an oxygen sensing film and a series of sampling ports as a unique tool capable of capturing changes in dissolved oxygen (DO) at high frequency (10 s) and spatial (< 1 mm) resolution across the length of a column. In addition, we provide custom scripts that allows image processing steps to be automated and consistently reproduced over a variety of experimental conditions. This dataset is comprised of four folders (1) 01_Riverbed_Sediment_Experiment, (2) 02_Sand_Experiment, (3) 01_Riverbed_Sediment_Raw_Images, and (4) 02_Sand_Experiment_Raw_Images. 01_Riverbed_Sediment_Experiment contains (1) a subfolder with csv files that contain statistical parameters from the linear regressions applied to each optode image, (2) a subfolder with csv files from DO data measured by in-line sensors, (3) a subfolder with csv files containing column and injection specific input parameters for the image processing script, and (4) a subfolder with scripts used to process the images and create associated figures. 02_Sand_Experiment contains (1) a subfolder with csv files containing column and injection-specific input parameters for the image processing script, and (2) a subfolder with scripts used to process the images and create associated figures. 01_Riverbed_Sediment_Raw_Images (spited in 3 parts due to size) contains a subfolder with raw red, and green images from the optode system during the MilliQ Injection, Vanillin Injection or Vanillin + Sampling Injection respectively. 02_Sand_Experiment_Raw_Images contains a subfolder with raw red, and green images from the optode system. Outside of the main folders there is a csv containing file-level metadata and a csv data dictionary defining column headers for all csv files contained in the data package.

54 ENVIRONMENTAL SCIENCES↗

DOE OSTI2016

Summary of Documentation for DYNA3D-ParaDyn's Software Quality Assurance Regression Test Problems

The Software Quality Assurance (SQA) regression test suite for DYNA3D (Zywicz and Lin, 2015) and ParaDyn (DeGroot, et al., 2015) currently contains approximately 600 problems divided into 21 suites, and is a required component of ParaDyn’s SQA plan (Ferencz and Oliver, 2013). The regression suite allows developers to ensure that software modifications do not unintentionally alter the code response. The entire regression suite is run prior to permanently incorporating any software modification or addition. When code modifications alter test problem results, the specific cause must be determined and fully understood before the software changes and revised test answers can be incorporated. The regression suite is executed on LLNL platforms using a Python script and an associated data file. The user specifies the DYNA3D or ParaDyn executable, number of processors to use, test problems to run, and other options to the script. The data file details how each problem and its answer extraction scripts are executed. For each problem in the regression suite there exists an input deck, an eight-processor partition file, an answer file, and various extraction scripts. These scripts assemble a temporary answer file in a specific format from the simulation results. The temporary and stored answer files are compared to a specific level of numerical precision, and when differences are detected the test problem is flagged as failed. Presently, numerical results are stored and compared to 16 digits. At this accuracy level different processor types, compilers, number of partitions, etc. impact the results to various degrees. Thus, for consistency purposes the regression suite is run with ParaDyn using 8 processors on machines with a specific processor type (currently the Intel Xeon E5530 processor). For non-parallel regression problems, i.e., the two XFEM problems, DYNA3D is used instead. When environments or platforms change, executables using the current source code and the new resource are created and the regression suite is run. If differences in answers arise, the new answers are retained provided that the differences are inconsequential. This bootstrap approach allows the test suite answers to evolve in a controlled manner with a high level of confidence. Developers also run the entire regression suite with (serial) DYNA3D. While these results normally differ from the stored (parallel) answers, abnormal termination or wildly different values are strong indicators of potential issues.

42 ENGINEERING↗

DOE OSTI2024

Documentation for Python Automation in CYME for DER Hosting Capacity Analysis of Different Feeder Configurations

This file provides the documentation for several Python scripts that were developed by Sandia National Laboratories to enhance the automation and customization capabilities for performing various distribution system planning and analysis tasks in CYME. Specifically, these scripts (.py files detailed in Figure 1) enable the user to evaluate different distribution system configurations and the resulting impacts on hosting capacity results and other metrics. In general, these scripts—and the accompanying documentation—provide the foundation upon which future customized tools can be created. For example, the scripts show how to extract and modify parameters of various circuit components, set up and run analyses using built-in CYME tools (iteratively), and export reports for further evaluations and comparisons. Thus, the capabilities and syntaxes used in the scripts can be adapted and leveraged for countless other objectives.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1982

MC carbide structures in M(lc2)ar-M247

The morphologies and distribution of the MC carbides in Mar-M247 ingot stock and castings were investigated using metallographic, X-ray diffraction and energy-dispersive X-ray analysis techniques. The MC carbides were found to form script structures during solidification. The script structures were composed of three distinct parts. The central cores and elongated arms of the MC carbide script structures had compositions (Ti, Cr, Hf, Ta, W)C and lattice parameters of 4.39 A. The elongated script arms terminated in enlarged, angular "heads". The heads had compositions (Ti, Hf, Ta, W)C and lattice parameters of approximately 4.50 A. The heads had a higher Hf content than the cores and arms. The size of the script structures, as well as the relative amount of head-type to core and arm-type MC carbide, was found to be determined by solidification conditions. No carryover of the MC carbides from the ingot stock to the remelted and cast material was observed.

Wawro, S. W.↗

NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗

NASA NTRS2001

Java Application Shell: A Framework for Piecing Together Java Applications

This session describes the architecture of Java Application Shell (JAS), a Swing-based framework for developing interactive Java applications. Java Application Shell is being developed by Commerce One, Inc. for NASA Goddard Space Flight Center Code 588. The purpose of JAS is to provide a framework for the development of Java applications, providing features that enable the development process to be more efficient, consistent and flexible. Fundamentally, JAS is based upon an architecture where an application is considered a collection of 'plugins'. In turn, a plug-in is a collection of Swing actions defined using XML and packaged in a jar file. Plug-ins may be local to the host platform or remotely-accessible through HTTP. Local and remote plugins are automatically discovered by JAS upon application startup; plugins may also be loaded dynamically without having to re-start the application. Using Extensible Markup Language (XML) to define actions, as opposed to hardcoding them in application logic, allows easier customization of application-specific operations by separating application logic from presentation. Through XML, a developer defines an action that may appear on any number of menus, toolbars, and buttons. Actions maintain and propagate enable/disable states and specify icons, tool-tips, titles, etc. Furthermore, JAS allows actions to be implemented using various scripting languages through the use of IBM's Bean Scripting Framework. Scripted action implementation is seamless to the end-user. In addition to action implementation, scripts may be used for application and unit-level testing. In the case of application-level testing, JAS has hooks to assist a script in simulating end-user input. JAS also provides property and user preference management, JavaHelp, Undo/Redo, Multi-Document Interface, Single-Document Interface, printing, and logging. Finally, Jini technology has also been included into the framework by means of a Jini services browser and the ability to associate services with actions. Several Java technologies have been incorporated into JAS, including Swing, Internal Frames, Java Beans, XML, JavaScript, JavaHelp, and Jini. Additional information is contained in the original extended abstract.

Miller, Philip↗

DOE OSTI2016

Development and Verification of MATLAB Functions for Pressure Drop Estimation in Crossflow Tube Bundles

The experimental data on drag coefficients in crossflow tube bundles is severely limited. It is largely contained in nomograms for a small range of tube bundle pitch ratios for both in-line and staggered bundles. These monograms and the corresponding correlations/curve fits are not readily accessible. This lack of experimental data presents a limitation when designing crossflow heat exchangers for nuclear reactors. Specifically, Molten Salt Reactors (MSRs) that utilize cross-flow configurations with turbulent molten salts flowing in the shell side are of interest. Current methods of calculating the drag coefficients are outdated and time consuming when conducting design studies (i.e. picking points off a graph). A computer script could easily run the necessary rapid calculations of the pressure drop for a large possible range of Reynolds numbers, pitch ratios and tube bundle configurations. In an effort to facilitate increased access and accuracy to crossflow pressure drop calculations, a set of MATLAB scripts have been created. These are specifically for the pressure drop and drag coefficients for flow over rows of in-line and staggered tube bundles. For verification of the scripts, the nomograms produced by Zukauskas, of which the scripts are built off, served as a comparison to the plot generated by the MATLAB scripts. (authors)

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

DOE OSTI2023

GeoThermalCloud for EGS – An Open-source, User-friendly, Scalable AI Workflow for Modeling Enhanced Geothermal Systems

Enhanced Geothermal Systems (EGS) offer a vast potential to expand the use of geothermal energy. Heat is extracted from this engineered system by injecting relatively cold water into subsurface fractures, which are in contact with hot dry rock, and brought back to surface through production wells. Creating EGS requires improving the natural permeability of hot crystalline rocks. In this short conference paper, we present a reproducible workflow for modeling EGS. Our workflow called the GeoThermalCloud (GTC) for EGS, leverages recent advances in machine learning, deep learning, and high-performance computing. This GTC framework is currently being made open-source, user-friendly, and reproducible through python scripts as well as Google Colab/Jupyter Notebooks. This GTC for EGS modeling scripts are made available at https://github.com/SmartTensors/GeoThermalCloud.jl/tree/master/EGS and will constantly be updated to cater for geothermal community. Current GTC framework provides scripts to train deep learning (DL) models for techno-economics and data worth analysis. The Geothermal Design Tool (https://github.com/GeoDesignTool/GeoDT.git), a fast and simplified multi-physics solver, is used to develop a database for training DL models. This short paper provides details on the scripts to curate, process, and train DL models. The scripts can easily be modified to train on databases generated by other popular open-source simulators such as PFLOTRAN, STOMP, TOUGH, and GEOSX or commercial software such as ResFrac and COMSOL.

15 GEOTHERMAL ENERGY↗

DOE OSTI2021

Dependence of dark matter - electron scattering on the galactic dark matter velocity distribution

The rate of dark matter-electron scattering depends on the underlying velocity distribution of the dark matter halo. Importantly, dark matter-electron scattering is particularly sensitive to the high-velocity tail, which differs significantly amongst the various dark matter halo models. In this work, we summarize the leading halo models and discuss the various parameters which enter them. We recommend updated values for these parameters based on recent studies and measurements. Furthermore, we quantify the dependence of the dark matter-electron scattering rate on the choice of halo model and parameters, and demonstrate how these choices propagate to the predicted cross-section limits. The rate is most sensitive to changes in the circular velocity v 0 ; in silicon targets, we find that the changes in the rate predictions can range from Script $\mathcal{O}$(0.01%) to Script $\mathcal{O}$(100%) for contact interactions and Script $\mathcal{O}$(10%) to Script $\mathcal{O}$(100%) for long-range interactions.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

DOE OSTI2016

SU-F-J-94: Development of a Plug-in Based Image Analysis Tool for Integration Into Treatment Planning

Purpose: To extend the functionality of a commercial treatment planning system (TPS) to support (i) direct use of quantitative image-based metrics within treatment plan optimization and (ii) evaluation of dose-functional volume relationships to assist in functional image adaptive radiotherapy. Methods: A script was written that interfaces with a commercial TPS via an Application Programming Interface (API). The script executes a program that performs dose-functional volume analyses. Written in C#, the script reads the dose grid and correlates it with image data on a voxel-by-voxel basis through API extensions that can access registration transforms. A user interface was designed through WinForms to input parameters and display results. To test the performance of this program, image- and dose-based metrics computed from perfusion SPECT images aligned to the treatment planning CT were generated, validated, and compared. Results: The integration of image analysis information was successfully implemented as a plug-in to a commercial TPS. Perfusion SPECT images were used to validate the calculation and display of image-based metrics as well as dose-intensity metrics and histograms for defined structures on the treatment planning CT. Various biological dose correction models, custom image-based metrics, dose-intensity computations, and dose-intensity histograms were applied to analyze the image-dose profile. Conclusion: It is possible to add image analysis features to commercial TPSs through custom scripting applications. A tool was developed to enable the evaluation of image-intensity-based metrics in the context of functional targeting and avoidance. In addition to providing dose-intensity metrics and histograms that can be easily extracted from a plan database and correlated with outcomes, the system can also be extended to a plug-in optimization system, which can directly use the computed metrics for optimization of post-treatment tumor or normal tissue response models. Supported by NIH - P01 - CA059827.

60 APPLIED LIFE SCIENCES↗

DOE OSTI2017

ACME Priority Metrics (A-PRIME)

A-PRIME, is a collection of scripts designed to provide Accelerated Climate Model for Energy (ACME) model developers and analysts with a variety of analysis of the model needed to determine if the model is producing the desired results, depending on the goals of the simulation. The software is csh scripts based at the top level to enable scientist to provide the input parameters. Within the scripts, the csh scripts calls code to perform the postprocessing of the raw data analysis and create plots for visual assessment.

Evans, KatherineJ.↗

DOE OSTI2024

Interpolation Models and Error Bounds for Verifiable Scientific Machine Learning

This repository contains python scripts and numerical data accompanying the paper: "Leveraging Interpolation Models and Error Bounds for Verifiable Scientific Machine Learning," Tyler Chang, Andrew Gillette, Romit Maulik, 2024. The following subdirectories are included: - "interpolants" contains our interpolation scripts used for all studies - "experiments" contains scripts demonstrating our experiments with synthetic data - "airfoil" contains scripts demonstrating our experiments with the publicly available UIUC airfoil dataset. Further instructions are provided in READMEs within the sub-directories.

Gillette, Andrew↗

DOE OSTI2025

JGI-Trichoderma v1.0

There is a series of Python and bash scripts to parse genomics datasets used to evaluate the coevolution of gene families and the feature importance of gene families using an SVM classifier. - Cover analysis: takes a list of single-copy genes in a set of genomes, aligns and builds the gene trees to determine if two gene families have a signature of covariation with one another. It parses the files to run phykit cover script described here: https://jlsteenwyk.com/PhyKIT/usage/index.html - SVM-classifier: This Python script is an SVM-based genomic classifier designed for biological data analysis. It combines machine learning with feature selection to identify important genomic markers and classify biological samples. Core Functionality: The script uses Support Vector Machines from scikit-learn to classify genomic data, incorporating SelectKBest for automated feature selection and leave-one-out cross-validation for performance assessment. It operates in multiple modes: feature ranking, optimal combination discovery, and sample prediction. Primary Applications: Genomic sample classification and biomarker discovery Feature importance analysis in high-dimensional biological datasets Prediction of sample categories based on genomic profiles Research applications requiring robust classification of biological data Key Advantages: High-dimensional handling: SVMs excel with genomic data's typical high feature-to-sample ratios Integrated feature selection: Reduces noise and computational overhead while identifying key markers Probability estimation: Provides confidence scores essential for biological interpretation Validation robustness: Leave-one-out cross-validation ensures reliable performance metrics Operational flexibility: Multiple analysis modes support different research phases from exploration to prediction

Stecca Steindorff, Andrei [Lawrence Berkeley Natio↗