Search NASA⌕ Search

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.

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

At least 271 records · Page 15
All sourcesNASA NTRSDOE OSTI
DOE OSTI2016

SU-F-T-94: Plan2pdf - a Software Tool for Automatic Plan Report for Philips Pinnacle TPS

Purpose: To implement an automatic electronic PDF plan reporting tool for Philips Pinnacle treatment planning system (TPS) Methods: An electronic treatment plan reporting software is developed by us to enable fully automatic PDF report from Pinnacle TPS to external EMR programs such as MOSAIQ. The tool is named “plan2pdf”. plan2pdf is implemented using Pinnacle scripts, Java and UNIX shell scripts, without any external program needed. plan2pdf supports full auto-mode and manual mode reporting. In full auto-mode, with a single mouse click, plan2pdf will generate a detailed Pinnacle plan report in PDF format, which includes customizable cover page, Pinnacle plan summary, orthogonal views through each plan POI and maximum dose point, DRR for each beam, serial transverse views captured throughout the dose grid at a user specified interval, DVH and scorecard windows. The final PDF report is also automatically bookmarked for each section above for convenient plan review. The final PDF report can either be saved on a user specified folder on Pinnacle, or it can be automatically exported to an EMR import folder via a user configured FTP service. In manual capture mode, plan2pdf allows users to capture any Pinnacle plan by full screen, individual window or rectangular ROI drawn on screen. Furthermore, to avoid possible patients’ plan mix-up during auto-mode reporting, a user conflict check feature is included in plan2pdf: it prompts user to wait if another patient is being exported by plan2pdf by another user. Results: plan2pdf is tested extensively and successfully at our institution consists of 5 centers, 15 dosimetrists and 10 physicists, running Pinnacle version 9.10 on Enterprise servers. Conclusion: plan2pdf provides a highly efficient, user friendly and clinical proven platform for all Philips Pinnacle users, to generate a detailed plan report in PDF format for external EMR systems.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2016

SU-F-T-167: Measurement of Proton Beam Spot Size Using a 2D Ion Chamber Array for Daily QA

Purpose: To develop an algorithm which can calculate the Full Width Half Maximum (FWHM) of a Proton Pencil Beam from a 2D dimensional ion chamber array (IBA Matrixx) with limited spatial resolution ( 7.6 mm inter chamber distance). The algorithm would allow beam FWHM measurements to be taken during daily QA without an appreciable time increase. Methods: Combinations of 147 MeV single spot beams were delivered onto an IBA Matrixx and concurrently on EBT3 films for a standard. Data were collected around the Bragg Peak region and evaluated by a custom MATLAB script based on our algorithm using a least squared analysis. A set of artificial data, modified with random noise, was also processed to test for robustness. Results: The Matlab script processed Matixx data shows acceptable agreement (within 5%) with film measurements with no single measurement differing by more than 1.8 mm. In cases where the spots show some degree of asymmetry, the algorithm is able to resolve the differences. The algorithm was able to process artificial data with noise up to 15% of the maximum value. Time assays of each measurement took less than 3 minutes to perform, indicating that such measurements may be efficiently added to daily QA treatment. Conclusion: The developed algorithm can be implemented in daily QA program for Proton Pencil Beam scanning beams (PBS) with Matrixx to extract spot size and position information. The developed algorithm may be extended to small field sizes in photon clinic.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2016

SU-F-T-531: Determination of Site-Specific Dynamic-Jaw Versus Static-Jaw RapidArc Delivery

Purpose: Dynamic-jaw tracking maximizes the area blocked by both jaw and MLC in RapidArc. We developed a method to quantify jaw tracking. Methods: An Eclipse Scripting API (ESAPI) was used to export beam parameters for each arc’s control points. The specific beam parameters extracted were: gantry angle, control point number, meterset, x-jaw positions, y-jaw positions, MLC bank-number, MLC leaf-number, and MLC leaf-position. Each arc contained 178 control points with 120 MLC positions. MATLAB routines were written to process these parameters in order to calculate both the beam aperture (unblocked) size for each control point. An average aperture size was weighted by meterset. Jaw factor was defined as the ratio between dynamic-jaw to static-jaw aperture size. Jaw factor was determined for forty retrospectively replanned patients treated with static-jaw delivery sites including lung, brain, prostate, H&N, rectum, and bladder. Results: Most patients had multiple arcs and reduced-field boosts, resulting in 151 fields. Of these, the lowest (0.4722) and highest (0.9622) jaw factor was observed in prostate and rectal cases, respectively. The median jaw factor was 0.7917 meaning there is the potential unincreased blocking by 20%. Clinically, the dynamic-jaw tracking represents an area surrounding the target which would receive MLC-only leakage transmission of 1.68% versus 0.1% with jaws. Jaw-tracking was more pronounced at areas farther from the target. In prostate patients, the rectum and bladder had 5.5% and 6.3% lower mean dose, respectively; the structures closer to the prostate such as the rectum and bladder both had 1.4% lower mean dose. Conclusion: A custom ESAPI script was coupled with a MATLAB routine in order to extract beam parameters from static-jaw plans and their replanned dynamic-jaw deliveries. The effects were quantified using jaw factor which is the ratio between the meterset weighted aperture size for dynamic-jaw fields versus static-jaw fields.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2016

SU-G-TeP4-08: Automating the Verification of Patient Treatment Parameters

Purpose: To automate the daily verification of each patient’s treatment by utilizing the trajectory log files (TLs) written by the Varian TrueBeam linear accelerator while reducing the number of false positives including jaw and gantry positioning errors, that are displayed in the Treatment History tab of Varian’s Chart QA module. Methods: Small deviations in treatment parameters are difficult to detect in weekly chart checks, but may be significant in reducing delivery errors, and would be critical if detected daily. Software was developed in house to read TLs. Multiple functions were implemented within the software that allow it to operate via a GUI to analyze TLs, or as a script to run on a regular basis. In order to determine tolerance levels for the scripted analysis, 15,241 TLs from seven TrueBeams were analyzed. The maximum error of each axis for each TL was written to a CSV file and statistically analyzed to determine the tolerance for each axis accessible in the TLs to flag for manual review. The software/scripts developed were tested by varying the tolerance values to ensure veracity. After tolerances were determined, multiple weeks of manual chart checks were performed simultaneously with the automated analysis to ensure validity. Results: The tolerance values for the major axis were determined to be, 0.025 degrees for the collimator, 1.0 degree for the gantry, 0.002cm for the y-jaws, 0.01cm for the x-jaws, and 0.5MU for the MU. The automated verification of treatment parameters has been in clinical use for 4 months. During that time, no errors in machine delivery of the patient treatments were found. Conclusion: The process detailed here is a viable and effective alternative to manually checking treatment parameters during weekly chart checks.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2016

Sci-Fri PM: Radiation Therapy, Planning, Imaging, and Special Techniques - 08: Retrospective Dose Accumulation Workflow in Head and Neck Cancer Patients Using RayStation 4.5.2

Purpose: We have developed a semi-automated dose accumulation workflow for Head and Neck Cancer (HNC) patients to evaluate volumetric and dosimetric changes that take place during radiotherapy. This work will be used to assess how dosimetric changes affect both toxicity and disease control, hence inform the feasibility and design of a prospective HNC adaptive trial. Methods: RayStation 4.5.2 features deformable image registration (DIR), where structures already defined on the planning CT image set can be deformably mapped onto cone-beam computed tomography (CBCT) images, accounting for daily treatment set-up shifts and changes in patient anatomy. The daily delivered dose can be calculated on each CBCT and mapped back to the planning CT to allow dose accumulation. The process is partially automated using Python scripts developed in collaboration with RaySearch. Results: To date we have performed dose accumulation on 18 HNC patients treated at our institution during 2013–2015 under REB approval. Our semi-automated process establishes clinical feasibility. Generally, dose accumulation for the entire treatment course of one case takes 60–120 minutes: importing all CBCTs requires 20–30 minutes as each patient has 30 to 40 treated fractions; image registration and dose accumulation require 60–90 minutes. This is in contrast to the process without automated scripts where dose accumulation alone would take 3–5 hours. Conclusions: We have developed a reliable workflow for retrospective dose tracking in HNC using RayStation. The process has been validated for HNC patients treated on both Elekta and Varian linacs with CBCTs acquired on XVI and OBI platforms respectively.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2019

Parsl: Pervasive Parallel Programming in Python

High-level programming languages such as Python are increasingly used to provide intuitive interfaces to libraries written in lower-level languages and for assembling applications from various components. This migration towards orchestration rather than implementation, coupled with the growing need for parallel computing (e.g., due to big data and the end of Moore's law), necessitates rethinking how parallelism is expressed in programs. Here, we present Parsl, a parallel scripting library that augments Python with simple, scalable, and flexible constructs for encoding parallelism. These constructs allow Parsl to construct a dynamic dependency graph of components that it can then execute efficiently on one or many processors. Parsl is designed for scalability, with an extensible set of executors tailored to different use cases, such as low-latency, high-throughput, or extreme-scale execution. We show, via experiments on the Blue Waters supercomputer, that Parsl executors can allow Python scripts to execute components with as little as 5 ms of overhead, scale to more than 250000 workers across more than 8000 nodes, and process upward of 1200 tasks per second. Other Parsl features simplify the construction and execution of composite programs by supporting elastic provisioning and scaling of infrastructure, fault-tolerant execution, and integrated wide-area data management. We show that these capabilities satisfy the needs of many-task, interactive, online, and machine learning applications in fields such as biology, cosmology, and materials science.

parallel programming↗
DOE OSTI2016

dfnWorks, Version 1.0

DFNWorks is a suite of software for generating and solving flow and transport physics on a Discrete Fracture Network (DFN). The suite is composed of three components: DFNGen: Stochastic fracture generation, mesh generation, model setup; DFNFlow: Flow solution using PFLOTRAN or FEHM control volume formulation solver; DFNTrans: Particle tracking transport; DFNGen Algorithm Description: This is a workflow that uses Mathematica software, Python scripts written by the authors and the LaGriT software to generate; DFNFlow; The solution of flow in porous media is accomplished by coupling DFNGen output with the existing software packages FEHM and PFLOTRAN. The DFNWorks workflow involves modules and scripts that translate DFNGen output to formats compatible with FEHM and PFLOTRAN input. FEHM LA-CC-2012-083 PFLOTRAN LA-CC-09-047 LaGriT LA-CC-07-38 DFNTrans Stand alone particle tracking algorithm that takes FEHM/PFLOTRAN flow solution as output and computes velocity field and advects particles.

Makedonska, Nataliia↗
DOE OSTI2017

dfnWorks, Version 2.0

DFNWorks is a suite of software for generating and solving flow and transport physics on a Discrete Fracture Network (DFN). The suite is composed of three components: DFNGen: Stochastic fracture generation, mesh generation, model setup; DFNFlow: Flow solution using PFLOTRAN or FEHM control volume formulation solver; DFNTrans: Particle tracking transport; DFNGen Algorithm Description: This is a workflow that uses C++ software version for fracture generation, Python scripts written by the authors and the LaGriT software to generate computational mesh. DFNFlow The solution of flow in porous media is accomplished by coupling DFNGen output with the existing software packages FEHM and PFLOTRAN. The DFNWorks workflow involves modules and scripts that translate DFNGen output to formats compatible with FEHM and PFLOTRAN input. FEHM LA-CC-2012-083 PFLOTRAN LA-CC-09-047 LaGriT LA-CC-07-38 DFNTrans Stand-alone particle tracking algorithm that takes FEHM/PFLOTRAN flow solution as output and computes velocity field and advects particles.

Makedonska, Nataliia↗
DOE OSTI2017

Transactive Energy Simulation Platform

Transactive Energy Simulation Platform (TESP) combines existing domain simulators in the electric power grid, buildings, and communication systems, with new transactive agents, growth models and evaluation scripts. The existing domain simulators include GridLAB-D for the distribution grid and single-family residential buildings, MATPOWER for transmission and bulk generation, EnergyPlus for large buildings and ns-3 for communication systems. More are planned for subsequent versions of TESP. The new elements are: TEAgents - simulate market participants and transactive systems for market clearing. Some of this functionality was extracted from GridLAB-D and implemented in Python for customization by PNNL and others. Growth Model - a means for simulating system changes over a multiyear period, including both normal load growth and specific investment decisions. Customizable in Python code. Evaluation Script - a means of evaluating different transactive systems through customizable post-processing in Python code. TESP will run on Linux, Windows and Mac OS X.

McDermott, Tom↗
DOE OSTI2017

Soil Carbon Data: long tail recovery

The software is intended to be part of an open source effort regarding soils data. The software provides customized data ingestion scripts for soil carbon related data sets and scripts for output databases that conform to common templates.

Source record↗
DOE OSTI2017

Synthetic Transaction Test Generator for Websites

Python script for querying a list of web sites and their details from Splunk and dynamically creating tests for monitoring uptime. The data generated from this script is then sent back to Splunk for creating reports and alerts.

Brown, Justin↗
DOE OSTI2018

GHOST (Grid Hardware Open Source Testbed) [SWR-18-32]

The software was developed for the purpose of Microgrid Controller Procurement where multiple Microgrid Controller vendors were competing to prove the best performance. Each microgrid controller was connected to Real-Time Simulator (Opal-RT) where the Real-Time model of microgrid was simulated. Microgrid controllers were able to control most of the assets in the model. To be able to fairly compare controller's performance each controller was evaluated using exactly the same model, with the same initial conditions and exactly the same test sequence. The microgrid evaluation test sequence lasted 100 minutes and consist of various grid disturbances to which a microgrid controller must respond. The microgrid and power system will experience multiple types of disturbances while performing dispatch functions. Many functions are tested in grid-connected and islanded modes such as unexpended failures of generators, energy storage trip events, and large load fluctuations. The test sequence focuses on fault scenarios that cause the highest short-circuit fault current contribution; force a swing bus or generator capable of being a swing bus offline; cause the most reconfigurations; and cause conflicting objectives for the microgrid controller. During the test sequence execution multiple datapoints are being recorded and stored. During data postprocessing key performance parameters are extracted allowing quantitative comparison of performance on multiple aspects including: resiliency, fuel utilization, grid interconnection, ancillary services and power quality and eventually after summing all key performance parameters by comparing the overall result. To be able to perform such testing multiple tools had to be developed included in this repository including: - Real time model of microgrid (Urban-Banshee, Remote-smaller model) - Test sequence configuration tools - Test execution real-time scripts - Post processing scripts - Human Machine Interface software

Koralewicz, Przemyslaw↗
DOE OSTI2018

High Performance Computing Cluster Engineering Academy

Collection of tools and code for evaluation testing of HPC orchestration solutions by HPCCEA summer students. These scripts and configuration files were written by HPCCEA summer students as part of their summer internship where they explore alternative solutions to our current HPC cluster management software. These scripts/configuration files range from using configuration management tools (Puppet, Chef, Ansible, Fabric, etc.) to scripting languages (Phython, BASH, Perl, etc.). Each year, new students will be added to the project and expand on previous years work.

Bennett, ThomasG↗
DOE OSTI2020

STAR

Structured Threat Automated Response (STAR) is a script that creates a python run-time for automated response action included in the Structure Threat Information Expression (STIX) Course of Action object. This script can parse a valid STIX json file and execute the included Course of Action.

McClurg, BryceL↗
DOE OSTI2018

MCR Container Tools

MathWorks' MATLAB is widely used in academia and industry for prototyping, data analysis, data processing, etc. Many users compile their programs using the MATLAB Compiler to run on workstations/computing clusters via the free MATLAB Compiler Runtime (MCR). The MCR facilitates the execution of code calling Application Programming Interfaces (API) functions from both base MATLAB and MATLAB toolboxes. In a Linux environment, a sizable number of third-party runtime dependencies (i.e. shared libraries) are necessary. Unfortunately, to the MTLAB community's knowledge, these dependencies are not documented, leaving system administrators and/or end-users to find/install the necessary libraries either as runtime errors resulting from them missing or by inspecting the header information of Executable and Linkable Format (ELF) libraries of the MCR to determine which ones are missing from the system. To address various shortcomings, Docker Images based on Community Enterprise Operating System (CentOS) 7, a derivative of Redhat Enterprise Linux (RHEL) 7, containing recent (2015-2017) MCR releases and their dependencies were created. These images, along with a provided sample Docker Compose YAML Script, can be used to create a simulated computing cluster where MATLAB Compiler created binaries can be executed using a sample Slurm Workload Manager script.

Haas, NicholasQ↗
DOE OSTI2020

Lithium-Ion Battery Vent Gas Tools

The spreadsheets and Python scripts are used to determine vent gas hazard metrics (i.e. flammability limits, flame speed, etc.). These scripts and spreadsheets use open source literature to determine these hazard metrics. SAND2020-12540 O Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy's National Nuclear Security Administration under contract DE-NA0003525.

Baird, Austin↗
DOE OSTI2019

Bead-Tracking Toolbox for MATLAB

A collection of MATLAB scripts forming a toolbox for video (frame by frame) detection and tracking of beads imaged with fluorescence microscope for estimating bead flow and location tracks. Scripts accept tiff image stacks of video frames and provide bead locations and tracked positions over frames in stack. Various utility functions are also provided to assist in data I/O. A custom solution for specific data source - specifically, the software works well for noisy/out of focus florescence microscopy images.

Rose, DerekC.↗
DOE OSTI2022

AutoBEM-DynamicArchetypes

Automatic Building Energy Modeling (AutoBEM, https://bit.ly/AutoBEM) has been used to create an OpenStudio and EnergyPlus building energy model of 122.9 million U.S. buildings (https://bit.ly/ModelAmerica). Simulating and analyzing a model of every building for large areas (e.g. cities) is often not feasible. This dynamic archetyping capability uses a representative building and calculates a floor-space multiplier that allows millions of buildings to be represented by less than 100 buildings. This script (WRF_Archetypes_Parallel.py) calculates these building archetypes for each of the grid cells from a Weather Research and Forecasting (WRF) model in a parallel fashion. The script works by looping through each of the grid cells in the shapefile in parallel, spatially joining the building metadata table to each grid cell, aggregating relevant archetypes and calculating necessary statistics related to area and number of buildings in each cell. The output is a table (.csv) in which each row is an archetype building with properties about that building as well as statistics that relate that building to the total cell (such as an area multiplier). The following inputs are required: WRF zone shapefile (.shp) (wrf-grids-origin_Vegas_Select_100.geojson) The projection of the shapefile ("EPSG:XXXX") Input table containing building metadata for area corresponding to shapefile (.csv) (https://zenodo.org/record/4552901#.YZQEotDMJPY - ClarkCounty2.csv) The number of cores that will be parallelized (integer) The output file name for the archetype table (.csv) Sample command line inputs: python3 ~/WRF_Archetypes_Parallel.py -i ~/wrf-grids-origin_Vegas_Select_100.geojson -c ~/ClarkCounty2.csv -o ~/OutputArchetypes.csv -j 72 -e EPSG:4326 Using Geopandas Version 0.9.0

Bass, Brett (0000000240988434)↗