Search NASA⌕ Search

SEARCH · Search NASA

Results for “Python 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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗
DOE OSTI2025

sourcePy

Pollutant source identification techniques (of which there are many variations) are either locked behind researchers writing their own code for each use case or GUI platforms that are easy to use but inflexible and opaque. The Python package sourcePy brings together many of the pollutant source identification algorithms, giving the user full control out of the box. It aims to create a platform for source identification experiments where the full analysis from beginning to end can be done in Python, with a level of specificity in design that isn't available in the GUI options. sourcePy provides users with a few key features: -A Python interface with HYSPLIT, which can be used to generate trajectories and concentration plumes -Several Python classes which standardize the preparation and processing of data related to source identification experiments -Example scripts and notebooks that allow even new python users to get started with their own experiments quickly -Visualization methods

Arseneau, Isaac [Oak Ridge National Laboratory (OR↗
DOE OSTI2024

The Data Mine model for accessible partnerships in data science

Abstract The Data Mine at Purdue University is a pioneering experiential learning community for undergraduate and graduate students of any background to learn data science. The first data‐intensive experience embedded in a large learning community, The Data Mine had nearly 1300 students in academic year (AY) 2022–2023 and nearly 1700 students for AY 2023–2024. The Data Mine embodies data‐infused education, research, and collaboration. Students learn Python, R, SQL, and shell‐scripting, while working on weekly projects within a high‐performance computing (HPC) cluster. In the Corporate Partners cohort, students work on teams of 5–15 students, led by a paid student team leader. Each cohort follows an Agile approach, working on data‐intensive projects provided by industry partners and mentored by company employees. Students develop professional and data skills throughout the academic year, from August through April. Many students return in subsequent years to the program, increasing their tenure with a Corporate Partner. Student teams are inherently interdisciplinary; students from 133 different majors are involved in the program, ranging from new incoming students through PhD level students. These interdisciplinary teams of students bring new perspectives to challenging problems in which data science is a key part of the solution. The interdisciplinary teams foster an environment of synthesis with ideas and solutions. Students come together with different life experiences, different levels of technical skill, but also varying ways they navigate paths to solutions because of the variety of majors represented, resulting in a more creative and robust solution than a traditional data science program. This article is categorized under: Applications of Computational Statistics > Education in Computational Statistics

Betz, Margaret A.↗
DOE OSTI2025

FORECASTOR – II. Simulating galaxy surveys with the Cosmological Advanced Survey Telescope for Optical and UV Research

The Cosmological Advanced Survey Telescope for Optical and UV Research (CASTOR) is a planned flagship space telescope, covering the blue-optical and UV part of the spectrum. Here, we introduce the CASTOR image simulator, a python GalSim package-based script capable of generating mock CASTOR images from an input catalogue. We generate example images from the CASTOR Wide, Deep, and Ultra-Deep surveys using simulated lightcones from the Santa Cruz semi-analytic model. We make predictions for the performance of these surveys by comparing galaxies that are extracted from each image using Source Extractor to the input catalogue. We find that the Wide, Deep, and Ultra-Deep surveys will be 75 per cent complete for point sources down to $\sim 27$, 29, and 30 mag, respectively, in the UV, u, and g filters, with the UV-split and u-split filters reaching a shallower depth. With a large area of $\sim 2200$ deg$^2$, the Wide survey will detect hundreds of millions of galaxies out to $z\sim 4$, mostly with $M_\ast \gtrsim 10^{9}\,{\rm M}_{\odot }$. The Ultra-Deep survey will probe to $z\sim 5$, detecting galaxies with $M_\ast \gtrsim 10^{7}{\rm M}_{\odot }$. These galaxy samples will enable precision measurements of the distribution of star formation in the cosmic web, connecting the growth of stellar mass to the assembly of dark matter haloes over two thirds of the history of the Universe, and other core goals of CASTOR’s legacy surveys. These image simulations and the tools developed to generate them will be a vital planning tool to estimate CASTOR’s performance and iterate the telescope and survey designs prior to launch.

79 ASTRONOMY AND ASTROPHYSICS↗
DOE OSTI2023

Constraining Bedrock Groundwater Residence Times in a Mountain System with Environmental Tracer Observations and Bayesian Uncertainty Quantification: Modeling and Data Package

Groundwater residence times provide fundamental descriptions of hydrologic dynamics and mixing processes in mountainous watersheds. Yet, few observational datasets that can constrain groundwater residence times over broad timescales are available in high elevation mountain systems. Here we present field observations from May 2021 of dissolved noble gases (He, Ne, Ar, Kr, and Xe), Chloroflourcarbons (CFCs), Sulfurhexaflouride (SF6), and tritium (3H) sampled from the Pumphouse Lower Montane study site (wells PLM1, PLM6, and PLM7) within the East River Watershed, Colorado. The presented noble gas (PLM_noblegas_2021.csv) and environmental tracer (PLM_tracers_2021.csv) observation datasets, along with the associated modeling scripts, aide in quantifying groundwater residence times and recharge conditions in a high elevation mountain system. Furthermore, the modeling scripts quantify groundwater residence time and noble gas recharge condition uncertainties using a novel Markov-chain Monte Carlo approach. All data modeling scripts are written in the Python code.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2026

Advancing Concentrating Solar Thermal Modeling Using System Advisor Model (SAM)

Concentrating solar thermal (CST) technologies play a critical role in enabling dispatchable power and high-temperature industrial heat applications. Accurate and flexible modeling tools are essential for evaluating system performance, guiding technology research and development, and informing investment decisions. The National Laboratory of the Rockies's System Advisor Model (SAM) is a widely used techno-economic simulation platform for CST systems, providing detailed performance and financial modeling capabilities for multiple CST system configurations. SAM integrates physics-based performance models with financial analysis to simulate the behavior of complex energy systems under realistic operating conditions. For CST technologies (including tower, parabolic trough, and linear Fresnel), SAM enables hourly simulations using site-specific weather data that ensure feasible operating conditions and convergence of mass and energy between core system components (i.e., solar field, receiver, thermal energy storage, and power cycle). These capabilities allow researchers and developers to evaluate annual energy production, capacity factors, levelized cost of energy (LCOE), and system dispatch strategies. A key advantage of SAM lies in its flexibility for parametric analysis and large-scale computational studies. Users can vary system design parameters such as heliostat field layout, receiver dimensions, thermal energy storage capacity, power block sizing, and installation cost assumptions to investigate their impact on system performance and financial metrics. When combined with automated scripting through LK, SDKTool, or Python interfaces, SAM enables high-throughput simulation workflows that support sensitivity analysis, technology benchmarking, and optimization studies. These approaches are particularly valuable for next-generation CST concepts, where design spaces are large and system interactions are complex. Another important capability of SAM is its support for dispatch optimization and thermal energy storage modeling, which are central to the value proposition of CST technologies. The ability to simulate integrated storage and flexible power generation allows researchers to explore strategies that maximize grid value, improve capacity utilization, and enhance integration with variable resources such as photovoltaic and wind generation. This poster will present an overview of SAM's thermal system modeling capabilities including concentrating solar. Additionally, we will highlight new feature developments including: 1) implementing Google's OR-Tools optimization platform for faster and more robust dispatch optimization, 2) developing a new power load following controller for modeling behind-the-meter applications, 3) enabling direct modeling of CSP-PV hybrid systems with the inclusion of battery storage, and 4) developing a multi-receiver falling particle Gen3 system model.

14 SOLAR ENERGY↗
NASA NTRS2007

Solving Equations of Multibody Dynamics

Darts++ is a computer program for solving the equations of motion of a multibody system or of a multibody model of a dynamic system. It is intended especially for use in dynamical simulations performed in designing and analyzing, and developing software for the control of, complex mechanical systems. Darts++ is based on the Spatial-Operator- Algebra formulation for multibody dynamics. This software reads a description of a multibody system from a model data file, then constructs and implements an efficient algorithm that solves the dynamical equations of the system. The efficiency and, hence, the computational speed is sufficient to make Darts++ suitable for use in realtime closed-loop simulations. Darts++ features an object-oriented software architecture that enables reconfiguration of system topology at run time; in contrast, in related prior software, system topology is fixed during initialization. Darts++ provides an interface to scripting languages, including Tcl and Python, that enable the user to configure and interact with simulation objects at run time.

Jain, Abhinandan↗
NASA NTRS2020

Dynamic IT Security Database and Analytics for Launch Control Systems Software

During the Summer 2020 session, I worked with intern Destani S. Van Arsdalen of EGS Software. Together, we co-created a tool to aid the dynamic investigation, updated over time,of the security compliance of LCS COTS and open source software. We originally planned touse spreadsheet software for management and analysis, but through this exploratoryproject, chose to use Python and JSON after receiving feedback on our project’s current anddesired capabilities at that time.At first, the project was solely designed to help on-board new COTS software, based on aquestionnaire that could be filled out for each software package. This, combined with usingthe spreadsheet application’s web-query capabilities to fetch information from the NVD,allowed presentation and analytics cells to automatically populate as elements of themanually-filled questionnaire changed. While this system was promising, we decided tochange technologies for a few reasons. In the spreadsheet, single cells could not hold complexdata like arrays and objects. The automatic population of cells and dynamic updates made itdifficult to manage and add new features. And finally, it had limited extensibility sinceadding new software required significant understanding of how both the spreadsheet wasconstructed, and the more obscure, proprietary scripting languages packaged with it.The pivot to a standard computer science database language of JSON, aided by thescripting capabilities of Python, greatly helped to improve the project’s functionality. First,and most importantly, the script’s import and analysis of database data is easilyreproducible. Additional data analysis can be modularly added without requiringmodification of the script and is capable of routine scheduling. The revised process can besplit into three parts. First, the conversion of LCS asset and software documentation into theJSON hierarchical database format. Second, the merging of this database with the NVD,forming a new data structure, using CPEs of the CVE object as a linking element betweenthem. And third, the automatically performed analytics and analysis of the combined data,in a modular and extensible format, to produce better informed business decisions. The outputted graphs, for example, are automatically generated by the Python script inconnection with the combined database. This allows updated graphs and any analytics to be re-rendered automatically following updates to the LCS’s initial asset documentation. Afinal report can then be programmatically and easily constructed from these sources to allow fully reproducible metrics for heavily evidenced risk management decisions.

it↗
DOE OSTI2021

Jas4pp — A data-analysis framework for physics and detector studies

This paper describes the Jas4pp framework for exploring physics cases and for detector-performance studies of future particle collision experiments. Jas4pp is a multi-platform Java program for numeric calculations, scientific visualization in 2D and 3D, storing data in various file formats and displaying collision events and detector geometries. It also includes complex data-analysis algorithms for function minimization, regression analysis, event reconstruction (such as jet reconstruction), limit settings and other libraries widely used in particle physics. The framework can be used with several scripting languages, such as Python/Jython, Groovy and JShell. Several benchmark tests discussed in the paper illustrate significant improvements in the performance of the Groovy and JShell scripting languages compared to the standard Python implementation in C. Furthermore, the improvements for numeric computations in Java are attributed to recent enhancements in the Java Virtual Machine.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Python Codebase and Jupyter Notebooks - Applications of Machine Learning Techniques to Geothermal Play Fairway Analysis in the Great Basin Region, Nevada

Git archive containing Python modules and resources used to generate machine-learning models used in the "Applications of Machine Learning Techniques to Geothermal Play Fairway Analysis in the Great Basin Region, Nevada" project. This software is licensed as free to use, modify, and distribute with attribution. Full license details are included within the archive. See "documentation.zip" for setup instructions and file trees annotated with module descriptions.

Brown, Stephen↗
NASA NTRS2002

Using scripting languages in optical interferometry

We discuss client-side CORBA scripts implemented in Tcl, Perl, and Python. These are all technologies that are either currently being used on testbeds at JPL or being evaluated for future use. Finally, a Python example demonstrating implementation of a simple CORBA server is presented.

CORBA↗
DOE OSTI2026

Data, model inputs, and analysis scripts associated with a manuscript on stream intermittency controls across spatial scales in Pacific Northwest watersheds

NOTE: The manuscript associated with this data package is currently in review. The data may be revised based on reviewer feedback. Upon manuscript acceptance, this data package will be updated with the final dataset and additional metadata. This data package is associated with the manuscript "Hydroclimatic Memory and Watershed Template Shape Stream Intermittency: Multi-scale Attribution Using Process-based Simulation and Explainable ML" by Niroula et al. (2026), submitted to Water Resources Research (WRR). The study investigates the dominant controls on stream intermittency across local, reach, and watershed scales using a coupled process-based simulation and explainable machine-learning framework. Long-term daily simulations from the Advanced Terrestrial Simulator (ATS) were used to generate wetness states and ponded-depth responses over river-corridor cells. These ATS outputs were then aggregated across scales and used to train XGBoost (eXtreme Gradient Boosting) models. SHAP (SHapley Additive exPlanations) was applied to quantify the relative importance of hydroclimatic forcings, watershed template attributes, and antecedent-memory effects in shaping intermittency behavior. The analysis is carried out for three contrasting Pacific Northwest watersheds: Oak Creek (OCW), American River Watershed (ARW), and H.J. Andrews (HJA). Across these testbeds, the package contains ATS-ready watershed inputs, ATS run configuration and selected output files, model-evaluation data products, intermittency-analysis datasets, machine-learning target-feature tables, SHAP outputs, and notebooks used to organize, analyze, and visualize results. At a high level, the package documents a workflow in which ATS provides the physically based simulation backbone and explainable machine learning is used as a post-processing attribution tool. The contents are intended to support interpretation of the manuscript figures and results, provide context for how intermittency metrics were generated at multiple scales, and preserve the key artifacts needed to understand and reuse the analysis workflow. The package contains a high-level directory summary file (`summary.txt`) and four main content folders (1) `evaluation_plots` contains evaluation figures and supporting evaluation datasets; (2) `intermittency_plots` contains intermittency-focused analysis notebook and prepared datasets; (3) `ml-training-and-shap_values_plots` contains ML training inputs, SHAP outputs, and figure-generation notebooks; and (4) `watershed_mesh_and_ats_input` contains ATS model setup materials, forcing inputs, geometry, and selected run files. More specifically, the `evaluation_plots` folder contains the notebook used for ATS evaluation plotting and site-specific evaluation datasets. These include evapotranspiration and water-balance products for three watersheds, as well as an Oak Creek field-measurement discharge file. The `intermittency_plots` folder contains the notebook used for intermittency analysis and the prepared datasets used to analyze intermittent and non-intermittent wetness behavior across the study watersheds. The `ml-training-and-shap_values_plots` folder contains notebooks and outputs for the machine-learning and explainability workflow. This includes the main XGBoost and SHAP notebook(s), a beeswarm plotting notebook, target-feature tables for machine-learning training, SHAP summary tables, and per-sample SHAP value archives. The `watershed_mesh_and_ats_input` folder contains ATS-related watershed inputs and supporting materials. This includes mesh and shape products, ATS-readable LAI and meteorological forcing inputs, selected ATS spinup and transient-run files, and a watershed workflow example notebook. Subdirectories are organized by watershed where applicable.All files are .cpg (codepage files), .csv (comma-separated values), .dbf (database files), .exo (Exodus mesh format), .h5 (HDF5 format), .ipynb (Jupyter notebooks), .pkl (Python pickle), .prj (projection files), .sh (shell scripts), .shp (shapefile geometry), .shx (shapefile index), .txt (text files), or .xml (markup data).

Advanced Terrestrial Simulator↗
DOE OSTI2021

HyPerPy (Hydrogen Extraction and Parabolic Trough Plant Performance Models using Python) [SWR-21-53]

The HyPerPy package consists of three scripts: 1) Model for Hydrogen Tracking in Parabolic Trough Power Plants, 2) Model for Receiver Performance, and 3) Model for Hydrogen Extraction Process. The power plant model (1) tracks hydrogen generation and transport within the circulating heat transfer fluid (HTF) of the power plant. This script is a transient, initial value simulation, in which the hydrogen concentration in the circulating HTF is 0 moles per cubic meter everywhere at time 0 seconds. Hydrogen concentration is calculated at discrete locations within the circulating HTF with 4-second time resolution. During each time step, the change in hydrogen concentration due to hydrogen generation and permeation is calculated for each location according to the local HTF temperature, vessel or piping properties, hydrogen concentration and partial pressure. This model predicts hourly hydrogen concentrations for typical operating days in the spring, summer, fall, and winter seasons. Data is used to create hourly mappings of hydrogen concentrations for a typical operating year. The receiver model (2) uses a 1-hour time step to estimate getter loading and annulus pressure. For each time step, the model uses HTF and ambient temperature data to estimate absorber tube, bellows, and getter temperatures for the time step. In addition, the model uses hourly HTF hydrogen concentrations that are generated by the power plant model (1), and annulus hydrogen pressure from the previous time step. With these data, the model calculates the moles of hydrogen permeating across the absorber tube and bellows during the time step. The net change in moles hydrogen is added or subtracted from the getter loading for the previous time step, and the hydrogen pressure is re-calculated based on getter loading and temperature. The model uses this algorithm to simulate hydrogen permeation and loading 24 hours per day, 365 days per year using seasonal temperature data. The model repeats these calculations for 25 years to create a mapping of receiver getter loading and annulus hydrogen pressure for four seasons of each year. The model for hydrogen extraction (3) estimates hydrogen extraction rates for a specific separation module configuration. The rate depends primarily on membrane area, vacuum pump performance, headspace gas flowrate to the membrane, and headspace gas hydrogen partial pressure. This model has two versions. The steady-state version predicts hydrogen extraction rates when the module is operating in separation mode. The dynamic version predicts hydrogen transfer through the membrane when the module is operating in sensor mode. The steady-state version is used with the plant model (1) to predict hydrogen partial pressures in the power plant when the extraction process is operating.

Glatzmaier, Gregory↗
NASA NTRS2008

Using Pipelined XNOR Logic to Reduce SEU Risks in State Machines

Single-event upsets (SEUs) pose great threats to avionic systems state machine control logic, which are frequently used to control sequence of events and to qualify protocols. The risks of SEUs manifest in two ways: (a) the state machine s state information is changed, causing the state machine to unexpectedly transition to another state; (b) due to the asynchronous nature of SEU, the state machine's state registers become metastable, consequently causing any combinational logic associated with the metastable registers to malfunction temporarily. Effect (a) can be mitigated with methods such as triplemodular redundancy (TMR). However, effect (b) cannot be eliminated and can degrade the effectiveness of any mitigation method of effect (a). Although there is no way to completely eliminate the risk of SEU-induced errors, the risk can be made very small by use of a combination of very fast state-machine logic and error-detection logic. Therefore, one goal of two main elements of the present method is to design the fastest state-machine logic circuitry by basing it on the fastest generic state-machine design, which is that of a one-hot state machine. The other of the two main design elements is to design fast error-detection logic circuitry and to optimize it for implementation in a field-programmable gate array (FPGA) architecture: In the resulting design, the one-hot state machine is fitted with a multiple-input XNOR gate for detection of illegal states. The XNOR gate is implemented with lookup tables and with pipelines for high speed. In this method, the task of designing all the logic must be performed manually because no currently available logic synthesis software tool can produce optimal solutions of design problems of this type. However, some assistance is provided by a script, written for this purpose in the Python language (an object-oriented interpretive computer language) to automatically generate hardware description language (HDL) code from state-transition rules.

Le, Martin↗
DOE OSTI2025

A Python Tool for Reconstructing MCNP6 Particle Histories from an HDF5 PTRAC File [Slides]

A Python tool for converting the MCNP6 HDF5 PTRAC file to a list of Python trees is presented. The particle trees store MCNP6 simulated events for each history using parent-child relationships, which ensures that branching processes are accurately reproduced. A variety of post-processing scripts are presented and used in conjunction with the Python particle trees to make special tallies that are currently not available in the MCNP6 software and visualize the particle tracks.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Flexible Integration of Diverse HVAC Technologies in EnergyPlus via Python-Enabled Workflows

Analysis of advanced controls and novel system types is often not directly feasible in building energy simulation tools. Various techniques extend building energy simulation tool capabilities to allow the use of user-defined scripts and programs, but these approaches have limitations. The EnergyPlus Python plugin offers users new flexibility to use EnergyPlus to call an external Python module at specific points in the simulation, as well as to use Python to call EnergyPlus functionality through an application programming interface (API). This paper presents four case studies leveraging the EnergyPlus Python plugin to facilitate analysis of advanced controls and system types. The use of the Python plugin offers greater modularity and flexibility relative to previous approaches, is less error prone, and is simpler for users to adopt. The Python plugin allows EnergyPlus to be used in a more flexible manner and to accommodate the expanding realm of energy modeling applications.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
NASA NTRSDate not supplied

An Expanded Role for Python in Expediting System Simulation Development

The Python programming language has traditionally been used as a “scripting” language and is not generally recognized as a language for building system simulations, where C++, Java, and other compiled languages are typically used. While very powerful and gaining favor for a large set of programming tasks, Python is generally regarded as not having the speed to directly do the extensive numeric computations required in large-scale simulation. This paper aims to present an approach, supported by case studies, to re-think this assertion. Directly using Python in this new role has the potential to expedite an agile, spiral cycle of development of design-test-modify for systems simulation.

programming language↗
DOE OSTI2024

FLARE: field line analysis and reconstruction for 3D boundary plasma modeling

The FLARE code is a magnetic mesh generator that is integrated within a suite of tools for the analysis of the magnetic geometry in toroidal fusion devices. A magnetic mesh is constructed from field line segments and permits fast reconstruction of field lines in 3D boundary plasma codes such as EMC3-EIRENE. Both intrinsically non-axisymmetric configurations (stellarators) and those with symmetry breaking perturbations of an axisymmetric equilibrium (tokamaks) are supported. The code itself is written in Modern Fortran with MPI support for parallel computing, and it incorporates object-oriented programming for the definition of the magnetic field and the material surface geometry. Extended derived types for a number of different magnetohydrodynamic equilibrium and plasma response models are implemented. The core element of FLARE is a field line tracer with adaptive step-size control, and this is integrated into tools for the construction of Poincaré maps and invariant manifolds of X-points. A collection of high-level procedures that generate output files for visualization is build on top of that. The analysis modules are build with Python frontends that facilitate customization of tasks and/or scripting of parameter scans.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗