Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “PYTHON”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 505 records · Page 28

Improving the Performance of NEML2 with Modern Graph Compilation Backends

NEML2 vectorizes constitutive-model evaluation for large-scale multiphysics simulation, using PyTorch as its tensor backend so that a batch of material-point updates runs on CPU or GPU through a single implementation. In the two prior reports in this series it was a C++-native library, deployed through TorchScript tracing and just-in-time (JIT) compilation; it has since been rewritten from the ground up into a Python-native library deployed through Ahead-of-Time Inductor (AOTInductor), a modern PyTorch graph-compilation backend. The rewrite is driven by a persistent tension, not a language preference: NEML2 composes constitutive models at runtime from a registry of small, independently-authored pieces, and that flexibility is difficult to reconcile with the compile-time knowledge an efficient GPU kernel needs. This report documents the rewrite and the investment that accompanied it: the AOTInductor export pipeline that turns a Python-authored model into a portable, Python-free compiled artifact loadable from pure C++; the eager and compiled runtimes and the new implicit solver layer built on them; a head-to-head benchmark of legacy JIT against AOTInductor; the physics-model catalog and its worked examples; the developer tooling; and the corresponding overhaul of MOOSE’s NEML2 integration that lets MOOSE consume it. A central objective is to examine whether modern PyTorch graph-compilation backends are effective for MOOSE GPU integration. The benchmark answers directly: AOTInductor outperforms legacy JIT on every GPU scenario measured, by 1.0–4.5×. Modern graph-compilation backends are effective for MOOSE GPU integration, and AOTInductor specifically – not compilation in the abstract – is why.

Hu, Gary (Tianchen) [Argonne National Laboratory (↗

Variational Quantum Chemistry Programs in JaqalPaq

We present example quantum chemistry programs written with JaqalPaq, a python meta-programming language used to code in Jaqal (Just Another Quantum Assembly Language). These JaqalPaq algorithms are intended to be run on the Quantum Scientific Computing Open User Testbed (QSCOUT) platform at Sandia National Laboratories. Our exemplars use the variational quantum eigensolver (VQE) quantum algorithm to compute the ground state energies of the H2, HeH+, and LiH molecules. Since the exemplars focus on how to program in JaqalPaq, the calculations of the second-quantized Hamiltonians are performed with the PySCF python package, and the mappings of the fermions to qubits are obtained from the OpenFermion python package. Using the emulator functionality of JaqalPaq, we emulate how these exemplars would be executed on an error-free QSCOUT platform and compare the emulated computation of the bond-dissociation curves for these molecules with their exact forms within the relevant basis.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

A symbolic framework to obtain mid-fidelity models of flexible multibody systems with application to horizontal-axis wind turbines

Abstract. The article presents a symbolic framework (also called computer algebra program) that is used to obtain, in symbolic mathematical form, the linear and nonlinear equations of motion of a mid-fidelity multibody system including rigid and flexible bodies. Our approach is based on Kane's method and a nonlinear shape function representation for flexible bodies. The shape function approach does not represent the state of the art for flexible multibody dynamics but is an effective trade-off to obtain mid-fidelity models with few degrees of freedom, taking advantage of the separation of space and time. The method yields compact symbolic equations of motion with implicit account of the constraints. The general and automatic framework facilitates the creation and manipulation of models with various levels of complexity by adding or removing degrees of freedom. The symbolic treatment allows for analytical gradients and linearized equations of motion. The linear and nonlinear equations can be exported to Python code or dedicated software. There are multiple applications, such as time domain simulation, stability analyses, frequency domain analyses, advanced controller design, state observers, and digital twins. In this article, we describe the method we used to systematically generate the equations of motion of multibody systems and present the implementation of the framework using the Python package SymPy. We apply the framework to generate illustrative land-based and offshore wind turbine models. We compare our results with OpenFAST simulations and discuss the advantages and limitations of the method. The Python implementation is provided as an open-source project.

Branlard, Emmanuel (ORCID:0000000277506128)↗

HAMR - Heterogeneous Accelerator Memory Resource (HAMR) v1.0

HAMR is a library defining an accelerator technology agnostic memory model that bridges between accelerator technologies (CUDA, HIP, ROCm, OpenMP, Sycl, OpenCL, Kokos, etc) and traditional CPUs in heterogeneous computing environments. HAMR is light weight and implemented in modern C++. HAMR can be used to manage memory with in a single code or as a data model for coupling codes in a technologically agnostic way. HAMR provides a Python module for coupling C++ and Python codes which implements zero-copy data transfers to and from Python using the Numpy array interface and Numba CUDA array interface protocols.

Loring, Burlen↗

Statistical Mechanics on Lattices (smol) v0.0.1

smol is a Python implementation of the Cluster Expansion Method and extensions of this methodology; which is used to fit applied lattice models from first principle calculations for subsequent use in Monte Carlo simulations for computing thermodynamic and statistical properties of atomic configuration. smol has a several notable advantages over other similar software packages. The first being its Python implementation which makes it easy to use even for users with little software and coding skills. Despite being implemented in Python, essential Monte Carlo routines are implemented in Cython such that performance is not compromised and is competitive even to similar software implemented in C/C++. Furthermore, the package has specific functionality for handling complex ionic materials (such as cathodes and electrolytes) that is not readily available in other packages. Lastly, the software has a flexible and modular design with the intention of making it fast and efficient to develop and extend the methodology.

Barroso-Luque, Luis↗

Data release for A search for extremely-high-energy neutrinos and first constraints on the ultra-high-energy cosmic-ray proton fraction with IceCube

<h1 id="summary">Summary</h1> <p>Title: Data Release for A search for extremely-high-energy neutrinos and first constraints on the ultra-high-energy cosmic-ray proton fraction with IceCube</p> <p>The IceCube observatory analyzed 12.6 years of data in search of extremely-high-energy (EHE) neutrinos above 5 PeV. The resultant limit of the search (Fig 1), and the effective area of the event selection (Fig 7), are provided in this data release.</p> <h1 id="contents">Contents</h1> <ul> <li><p>README file: this file</p> </li> <li><p><code>differential_limit_and_sensitivity.csv</code>: a comma separated value file, giving the observed experimental differential limit, and sensitivity, of the search as a function of neutrino energy. This is the content of Fig 1 in the paper. The first column is the neutrino energy in GeV. The second column is the limit in units of GeV/cm2/s/sr. The third column is the sensitivity in units of GeV/cm2/s/sr.</p> </li> <li><p><code>effective_area.csv</code>: a comma separated value file, giving the effective area of the search as a function of energy. This is the content of Fig 7 in the paper. The first column is the neutrino energy in GeV. The second column is the total effective area of the search, summed across neutrino flavors, and averaged across neutrinos and antineutrinos, in meters-squared. The third column is the effective area of the search for the average of electron neutrino and electron antineutrinos in units of meters-squared. The fourth column is the same as the third, but for muon-flavor neutrinos. The fifth column is the same as the third and fourth, but for tau-flavor neutrinos.</p> </li> <li><p><code>demo.py</code>: a short python script to demonstrate how to read the files. Run like <code>python demo.py</code>. A standard base python installation is sufficient, as the only dependencies are numpy and matplotlib.</p> </li> </ul> <h1 id="contacts">Contacts</h1> <p>For any questions about this data release, please write to analysis@icecube.wisc.edu</p>

Astronomy and Astrophysics↗

Ancient scientific basis of the "great serpent" from historical evidence

Zoological data and a growing mythology contributed to ancient Western knowledge about large serpents. Yet little modern attention has been paid to the sources, transmission, and receipt in the early Middle Ages of the ancients' information concerning "dragons" and "sea serpents." Real animals--primarily pythons and whales--lie behind the ancient stories. Other animals, conflations of different animals, simple misunderstandings, and willful exaggerations are found to account for the fanciful embellishments, but primitive myths played no significant role in this process during classical times. The expedition of Alexander the Great into India (327-325 B.C.) and the Bagradas River incident in North Africa (256 B.C.) had enormous repercussions on the development of serpent lore. Credible evidence is found for the presence of ancient populations of pythons living along the North African coast west of Egypt and along the coast of the Arabian Sea between the Indus River and the Strait of Hormuz--places where they no longer exist today. The maximum sizes of ancient pythons may have been greater than those of today's specimens.

Emblems and Insignia/history↗

A Multidisciplinary Tool for Systems Analysis of Planetary Entry, Descent, and Landing (SAPE)

SAPE is a Python-based multidisciplinary analysis tool for systems analysis of planetary entry, descent, and landing (EDL) for Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune, and Titan. The purpose of SAPE is to provide a variable-fidelity capability for conceptual and preliminary analysis within the same framework. SAPE includes the following analysis modules: geometry, trajectory, aerodynamics, aerothermal, thermal protection system, and structural sizing. SAPE uses the Python language-a platform-independent open-source software for integration and for the user interface. The development has relied heavily on the object-oriented programming capabilities that are available in Python. Modules are provided to interface with commercial and government off-the-shelf software components (e.g., thermal protection systems and finite-element analysis). SAPE runs on Microsoft Windows and Apple Mac OS X and has been partially tested on Linux.

Samareh, Jamshid A.↗

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗

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↗

Ramdb: The NASA Raman Spectral Database (version 1.00).

Given that, in most instances, minimal sample preparation is required and due to its contactless instrument design, Raman spectroscopy is one of the most versatile vibrational spectroscopic techniques for the chemical analysis of environmental and biological specimens. The diversity of applications of Raman spectroscopy ranges anywhere from art [1] to planetary science missions [2]. The advancement in the use of Raman spectroscopy in Solar System missions, notably in post-mission sample return analysis, requires a spectral library holding the broad range of specimens that could be found in Solar System sources. For this purpose, we have initiated the development of a Raman spectral database (Ramdb) at NASA Ames Research Center. Currently, the database includes experimental and theoretical Raman spectra of PAHs [3, 4], as well as laboratory Raman spectra of amino acids, carbon allotropes, minerals, and analogs relevance to Earth Sciences [5], Exobiology [6], Planetary [7], and Astrochemistry [8] to name just a few examples. Ramdb can be found on the web at www.astrochemistry.org/ramdb, where raw and processed Raman spectra can be downloaded in CSV format. The laboratory Raman spectra are measured using a laser Raman spectrometer (JASCO NRS-5500-532QRI). The Raman instrument is equipped with three excitation lasers, with wavelengths of 405, 532, and 785 nm. A clean silicon substrate is used as the internal standard for wavenumber calibration. Powdered samples were prepared (microscopic >10 um, grounded microscopic < 10 um) on glass slides. Some raw data exhibited a background signal arising as a combination of laser-induced fluorescence from the sample. To correct this background, we developed a Python pipeline that uses open-source Python libraries. Ramdb provides both raw and processed (using Python pipeline) data, which includes tabulated Raman shift transitions and other measurement details. The theoretical Raman band positions of PAHs (pyrene monomers and tetramer clusters) were computed using density functional theory (DFT) with the help of the Gaussian 16 suite of programs [9]. In the near future, Ramdb will serve as a repository of Raman spectral data from Laboratory Astrophysics and Planetary Science experiments involving the irradiation of organic compounds under simulated space and planetary conditions. In addition, online and offline tools will be developed for utilising the database for comparison to the user’s sample.

N Punnakayathil↗

Improving Access to the GEOS Composition Forecast Model with API Development and Ingestion into Google Earth Engine

The GEOS Composition Forecast (GEOS-CF) model produces forecast and historical estimates of atmospheric composition and meteorology fields, which provide useful insight into air quality issues and events. In a year for which Canadian wildfires created adverse air quality conditions in the eastern United States, access to model fields such as PM2.5 are in high demand. The GEOS-CF team at the NASA Global Modeling and Assimilation Office (GMAO) first developed in-house solutions to improve data access via the CF API, and recently partnered with Google to ingest a collated set of model diagnostics into the Google Earth Engine (GEE) data repository. GEOS-CF model output is also being ingested into AWS storage. Creating these various open access points to GEOS-CF model diagnostics provides the public with an opportunity to easily interact with air quality information. Users are able to use a temporally consistent global grid of air quality fields in machine learning applications, mapping tools, and data informatics. Hosting GEOS-CF forecasts and the historical timeseries of these chemistry and meteorology fields in GEE allows users to create dynamic JavaScript-based air quality applications in the GEE code editor. GEOS-CF users can also access the model output via the GEE Python application programming interface (API), making it easy to perform various analyses with Python. This presentation will show two examples of accessing the GEOS-CF model through GEE. The first is an example application made in the GEE code editor which allows users to view time series plots and downscaled maps of surface level NO2. The second example exhibits using the GEE Python API to create a machine learning model to temporally gap-fill between air quality observations. These examples are an introduction to the many possible benefits of having open access to the GEOS-CF model through multiple platforms.

Callum Wayman↗

Improving Access to the GEOS Composition Forecast Model with API Development and Ingestion into Google Earth Engine

The GEOS Composition Forecast (GEOS-CF) model produces forecast and historical estimates of atmospheric composition and meteorology fields, which provide useful insight into air quality issues and events. In a year for which Canadian wildfires created adverse air quality conditions in the eastern United States, access to model fields such as PM2.5 are in high demand. The GEOS-CF team at the NASA Global Modeling and Assimilation Office (GMAO) first developed in-house solutions to improve data access via the CF API, and recently partnered with Google to ingest a collated set of model diagnostics into the Google Earth Engine (GEE) data repository. GEOS-CF model output is also being ingested into AWS storage. Creating these various open access points to GEOS-CF model diagnostics provides the public with an opportunity to easily interact with air quality information. Users are able to use a temporally consistent global grid of air quality fields in machine learning applications, mapping tools, and data informatics. Hosting GEOS-CF forecasts and the historical timeseries of these chemistry and meteorology fields in GEE allows users to create dynamic JavaScript-based air quality applications in the GEE code editor. GEOS-CF users can also access the model output via the GEE Python application programming interface (API), making it easy to perform various analyses with Python. This presentation will show two examples of accessing the GEOS-CF model through GEE. The first is an example application made in the GEE code editor which allows users to view time series plots and downscaled maps of surface level NO 2 . The second example exhibits using the GEE Python API to create a machine learning model to temporally gap-fill between air quality observations. These examples are an introduction to the many possible benefits of having open access to the GEOS-CF model through multiple platforms.

Callum Wayman↗

Xstar Atomic Database: The PyXstar Package

We present a progress report on the development of PyXstar, a Python package to manage the data (input, output, intermediate, atomic database, and model-grids) associated with the XSTAR code for treating photoionized and collisionally ionized plasmas. The PyXstar modular structure and database retrieval scheme are described, and its functionality is illustrated with Python functions and classes for performing database searches. We briefly compare PyXstar with two other Python spectrum modeling tools: PyNeb and PyAtomDB.

Claudio Mendoza↗

An Autonomous MCP Bridge to Rucio: Enhancing Data Management Accessibility for High Energy Physics

The Rucio Data Management System [1] is an important tool used by High Energy Physics experiments, including those at Fermi National Accelerator Laboratory, to store and manage exabyte-scale scientific datasets. Despite its central role in coordinating data across globally distributed storage sites, Rucio's command line interface (CLI) presents a steep learning curve, and makes it difficult for scientists to navigate through. To solve this issue, a containerized Model Context Protocol (MCP) [2] server was built that connects Large Language Models directly to Rucio, allowing AI agents to handle data tasks by using simple, natural language rather than memorized terminal commands. The core engineering focus of this project was moving the server away from slow terminal commands that require text parsing and replacing them with a native Python Client API toolset and a planned REST API framework. Moving to the Python API handles data operations directly in memory, which helps clear up formatting errors, provides the AI with clean, structured JSON data and speeds up tool execution. To prove that the system actually works, a benchmarking pipeline was also built with various questions to test the AI across four different model configurations. The questions included finding data scopes, tracking down specific datasets, and checking replication rules. Through benchmarking, early runs showed that with raw terminal text, the model would get confused and stuck, whereas switching to the Python API to feed the AI clean, structured data yielded massive improvement. By creating an intelligent and autonomous bridge to a storage network, this project shows how AI can be implemented in scientific data management, which ultimately helps scientists at Fermilab spend less time sorting through data and more time focusing on their experiments and analysis.

Akella, Kashyap [William Rainey Harper Coll.]↗

SEAS Communication Engine: An Extensible, Flexible Wrapper for Co-Simulation Agents

When modeling and analyzing the power grid and other large scale systems, researchers often express scenarios as optimization problems and feed them into advanced software solvers. In order to allow multiple solvers to communicate with each other and share data from different domains, the National Renewable Energy Laboratory (NREL) and associated Department of Energy (DOE) labs have developed a software framework called the Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS). HELICS allows cosimulation via a collection of client libraries for different languages that can be called from the appropriate optimization software. However, these client libraries do not provide a higher level of abstraction beyond reading and writing data off of the shared HELICS bus. In this paper, we describe a new software library called the SEAS Communication Engine that exposes a higher-level API for running cosimulation problems. The SEAS Engine provides a class-based abstraction on top of the Python HELICS client, in order to allow users to implement their domain-specific cosimulations without needing to interact with core HELICS primitives. This will make adoption of HELICS and cosimulation in general easier, by exposing a simpler API. In the second part of the paper, we validate our library on a collection of different simulation examples, including the canonical IEEE 13 Bus Feeder. Lastly, we demonstrate using the SEAS Engine to directly call domain-specific code written in the Julia programming language. Our hope is that this will serve as a template for easily calling software in different programming languages via the SEAS Engine, thereby avoiding code duplication and complexity.

co-simulation↗

Tsdat: An Open-Source Data Standardization Framework for Marine Energy and Beyond

Many organizations are tasked with the collection and processing of large quantities of data from various measurement devices. Data reported from these sources are often not interoperable with datasets and software used by analysts and other organizations in the same domain, introducing barriers for collaboration on large-scale projects. This poses a particular problem for cross-device comparisons and machine learning applications, which rely on large quantities of data from multiple sources. To address these challenges, the open-source Time-Series Data Pipelines (Tsdat) Python framework was developed by Pacific Northwest National Laboratory, with strategic guidance and direction provided by the National Renewable Energy Laboratory and Sandia National Laboratories to facilitate collaboration and accelerate advancements in the marine energy domain through the development of an open-source ecosystem of tools. This paper will describe the Tsdat framework and the data standards within which it operates. A beta version of Tsdat has been released and is being used by several projects in marine energy, wind energy, and building energy systems.

big data↗

PyOECP: A flexible open-source software library for estimating and modeling the complex permittivity based on the open-ended coaxial probe (OECP) technique

Here, we present PyOECP, a Python-based flexible open-source software for estimating and modeling the complex permittivity obtained from the open-ended coaxial probe (OECP) technique. The transformation of the measured reflection coefficient to complex permittivity is performed based on three different methods. The software library contains the dielectric spectra of common reference liquids, which can be used to transform the reflection coefficient into the dielectric spectra. Several Python routines that are commonly employed (e.g., SciPy and NumPy) in the field of science and engineering are required only so that the users can alter the software structure depending on their needs. The modeling algorithm exploits the Markov Chain Monte Carlo method for the data regression. The discrete relaxation models can be built by a proper combination of well-known relaxation models. In addition to these models, electrode polarization, a typical measurement artifact for interpreting dielectric spectra, can be incorporated into the modeling algorithm. A continuous relaxation model, which solves the Fredholm integral equation of the first kind (a mathematically ill-posed problem), is also included. This open-source software enables users to freely adjust the physical parameters to obtain physical insight into their materials under test and will be consistently updated for more accurate measurement and interpretation of dielectric spectra in an automated manner. This work describes the theoretical and mathematical background of the software, lays out the workflow, and validates the software functionality based on both synthetic and empirical data included in the software.

97 MATHEMATICS AND COMPUTING↗