Search NASA⌕ Search

SEARCH · Search NASA

Results for “Python computer language”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
DOE OSTI2023

Evaluation of OpenAI Codex for HPC Parallel Programming Models Kernel Generation

We evaluate AI-assisted generative capabilities on fundamental numerical kernels in high-performance computing (HPC), including AXPY, GEMV, GEMM, SpMV, Jacobi Stencil, and CG. We test the generated kernel codes for a variety of language-supported programming models, including (1) C++ (e.g., OpenMP [including offload], OpenACC, Kokkos, SyCL, CUDA, and HIP), (2) Fortran (e.g., OpenMP [including offload] and OpenACC), (3) Python (e.g., numpy, Numba, cuPy, and pyCUDA), and (4) Julia (e.g., Threads, CUDA.jl, AMDGPU.jl, and KernelAbstractions.jl). We use the GitHub Copilot capabilities powered by the GPT-based OpenAI Codex available in Visual Studio Code as of April 2023 to generate a vast amount of implementations given simple + + prompt variants. To quantify and compare the results, we propose a proficiency metric around the initial 10 suggestions given for each prompt. Results suggest that the OpenAI Codex outputs for C++ correlate with the adoption and maturity of programming models. For example, OpenMP and CUDA score really high, whereas HIP is still lacking. We found that prompts from either a targeted language such as Fortran or the more general purpose Python can benefit from adding code keywords, while Julia prompts perform acceptably well for its mature programming models (e.g., Threads and CUDA.jl). We expect for these benchmarks to provide a point of reference for each programming model's community. Overall, understanding the convergence of large language models, AI, and HPC is crucial due to its rapidly evolving nature and how it is redefining human-computer interactions.

Godoy, William↗
DOE OSTI2022

NISQ Benchmarking

Test suite of quantum algorithms for Noisy Intermediate Scale Quantum (NISQ) computers. The test suite includes benchmark-style code for quantum volume circuits (QV), fairness sampling circuits, quantum telecloning circuits, and other NISQ benchmark style algorithms on small problems (i.e., up to 100 qubits), such as Variational Quantum Eigensolver (VQE), Hamiltonian Simulation, and Grover unstructured search example circuits. These benchmark-style applications are implemented in quantum software packages, mostly IBM's QISKIT, but may include vendor-specific frameworks, such as PyQuil (for Rigetti) or Q\# for Microsoft, or CirQ (for Google) as the test suite grows with the vendor sample. The test suite also includes numerical simulation code for Quantum Alternating Operator Ansatz (QAOA) algorithms, VQE, Hamiltonian Simulation and search examples. Numerical simulation code simulates quantum computers on classical computers, which is only possible for small problem instances; the implementation framework of choice is typically within Python, using the numpy/scipy libraries as well as extensions to the Julia language.

Pelofske, Elijah↗
DOE OSTI2024

Common Electric Power Transmission System Model JSON Schema Specification

The Common Electric Power Transmission System Model (CTM) is an intuitive, extensible, language-agnostic, and error-resistant specification of electric power network components parameter names and units, and relation between components, intended for use by the research community developing new computational methods for power systems operations and simulation. Power system datasets following the CTM specification can be read as dictionaries and manipulated in that form in most programming languages (e.g., Python, Julia, C++). This standard data structure in CTM makes it easy to work in multiple power systems domains (e.g., economic operation, reliability assessment, electricity markets, stability assessment, etc.) without requiring conversions between use-case-specific file formats with information loss in the process. This repository specifies CTM as a JSON Schema, provides documentation, derivate (code-generated) implementations of CTM, and example data and usage of the schema for important use cases.

Aravena Solis, Ignacio↗
DOE OSTI2022

Autodifferentiable Spectrum Model for High-dispersion Characterization of Exoplanets and Brown Dwarfs

We present an autodifferentiable spectral modeling of exoplanets and brown dwarfs. This model enables a fully Bayesian inference of the high-dispersion data to fit the ab initio line-by-line spectral computation to the observed spectrum by combining it with the Hamiltonian Monte Carlo in recent probabilistic programming languages. An open-source code, ExoJAX, developed in this study, was written in Python using the GPU/TPU compatible package for automatic differentiation and accelerated linear algebra, JAX. We validated the model by comparing it with existing opacity calculators and a radiative transfer code and found reasonable agreements for the output. As a demonstration, we analyzed the high-dispersion spectrum of a nearby brown dwarf, Luhman 16 A, and found that a model including water, carbon monoxide, and H 2 /He collision-induced absorption was well fitted to the observed spectrum (R = 10 5 and 2.28-2.30 μm). As a result, we found that T0 = 1295$^{-32}_{+35}$ K at 1 bar and C/O = 0.62 ± 0.03, which is slightly higher than the solar value. This work demonstrates the potential of a full Bayesian analysis of brown dwarfs and exoplanets as observed by high-dispersion spectrographs and also directly imaged exoplanets as observed by high-dispersion coronagraphy.

79 ASTRONOMY AND ASTROPHYSICS↗
DOE OSTI2021

A NICER View of the Massive Pulsar PSR J0740+6620 Informed by Radio Timing and XMM-Newton Spectroscopy

We report on Bayesian estimation of the radius, mass, and hot surface regions of the massive millisecond pulsar PSR J0740+6620, conditional on pulse-profile modeling of Neutron Star Interior Composition Explorer X-ray Timing Instrument event data. We condition on informative pulsar mass, distance, and orbital inclination priors derived from the joint North American Nanohertz Observatory for Gravitational Waves and Canadian Hydrogen Intensity Mapping Experiment/Pulsar wideband radio timing measurements of Fonseca et al. We use XMM-Newton European Photon Imaging Camera spectroscopic event data to inform our X-ray likelihood function. The prior support of the pulsar radius is truncated at 16 km to ensure coverage of current dense matter models. We assume conservative priors on instrument calibration uncertainty. We constrain the equatorial radius and mass of PSR J0740+6620 to be ${12.39}_{-0.98}^{+1.30}$ km and ${2.072}_{-0.066}^{+0.067}$ M ⊙ respectively, each reported as the posterior credible interval bounded by the 16% and 84% quantiles, conditional on surface hot regions that are non-overlapping spherical caps of fully ionized hydrogen atmosphere with uniform effective temperature; a posteriori, the temperature is ${\mathrm{log}}_{10}(T\,[{\rm{K}}])={5.99}_{-0.06}^{+0.05}$ for each hot region. All software for the X-ray modeling framework is open-source and all data, model, and sample information is publicly available, including analysis notebooks and model modules in the Python language. Furthermore, our marginal likelihood function of mass and equatorial radius is proportional to the marginal joint posterior density of those parameters (within the prior support) and can thus be computed from the posterior samples.

79 ASTRONOMY AND ASTROPHYSICS↗
DOE OSTI2026

Hyperdimensional computing for image classification (HDC) v1.0

This is an implementation of the hyperdimensional computing technique to classify images. It consists of a python script that trains the system for a set of images from a set of images (dataset) specified by the user. This training produces hardware configuration parameters and description vectors that are then loaded into the hardware description part of the project. The hardware description consists of hardware described in Verilog (a well known language for this purpose) that is synthesizable and can be implemented in a real chip. This hardware received the training information generated by python, and then is able to accept images to produce answers for each image on which category (class) from the pre-=trained ones the image belongs to. The hardware and python training scripts are configurable and documented. The advantage of hyperdimensional computing is its robustness to errors and the easy capability for online learning (refining the training during inference slowly over time), which this implementation supports.

Michelogiannakis, Georgios [Lawrence Berkeley Nati↗
DOE OSTI2023

Virtual Engineering Software Framework for Integrated Biomass Conversion Modeling

This presentation covers the design and implementation of a software tool to systematically connect computational models of unit operations to simulate an integrated process of low-temperature conversion of biomass to fuel. This virtual engineering (VE) software was designed with the overarching goal of connecting unit models written in various programming languages and requiring different computational resources within a single, flexible framework. The models and features currently considered for the VE library include mechanistic models for pretreatment, enzymatic hydrolysis, and aerobic bioreaction; high-fidelity computational fluid dynamics (CFD) simulations for enzymatic hydrolysis and aerobic bioreaction; and the capability to perform techno-economic analyses (TEA) using Aspen Plus, a commercial software package. The CFD models require access to high-performance computing (HPC) resources, so in addition to handling multiple programming languages and interfaces, the VE software must also be capable of interacting with an HPC scheduler to submit, run, and post-process jobs. Using the Python programming language, a new VE software package has been developed that contains functionality to manage the input-output communication between various unit models, schedule simulations to run on NREL's HPC and analyze those results, and interface with existing TEA software workflows. A Jupyter-notebook GUI was also created to solicit user input and provide documentation. In cases where multiple models for a particular unit-operation exist, selection between models is accomplished through a simple checkbox, with the appropriate inputs and outputs being parsed and converted seamlessly in the background. Each operation makes use of a different programming language, but the flow of information from pretreatment to enzymatic hydrolysis to bioreaction is managed with an intuitive, centralized file-communication strategy. In this talk, the programming approach and implementation details of the notebook are presented for multiple possibilities of the conversion process, including a demonstration of the ability to manage HPC resources. Additionally, an example of a sensitivity study of treatment parameters governing the overall conversion outcome is shown which highlights the ease of defining new problems using the VE Notebook workflow and leads into a discussion of ongoing work to enable outer-loop optimization studies.

biofuel↗
DOE OSTI2023

coloring v.1.0

SAND2024-02435O The software coloring allows applications written in the C++ language to generate publication-quality 2D plots. Its functionality is similar to Microsoft Excel's chart functionality or the Python language's matplotlib package. The value of coloring is that it is written purely in C++ and thus can be compiled on systems where Python is not available and linked into high performance computing software. For drawing shapes onto an image, coloring uses the mathematical definition of quadratic Bezier splines and uses Newton's method to search for the closest point on a spline to a given query point. This is then used to do accurate sub-pixel sampling to get clean, non-pixelated images. For working with the actual plot data, coloring has basic statistical methods such as finding maxima and minima as well as axis scaling such as logarithms. 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.

Ibanez, Daniel↗
DOE OSTI2021

Hoobas: A highly object-oriented builder for molecular dynamics

Polydispersity and random sequences are ubiquitous features of polymers, and molecular dynamics simulations can help elucidate the impact of disorder in polymer systems. However, currently available packages for building polymer topologies do not enable the user to include randomness in a straightforward fashion. Here, we introduce Hoobas, a molecular builder package that easily handles polydispersity using a prototype-builder design pattern. This enables fast and easy building of systems comprised of thousands of distinct objects. It is written in the Python programming language, which ensures compatibility with a wide range of molecular dynamics packages and tools, as well as easy integration into most workflows.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Performance of Julia for High Energy Physics Analyses

We argue that the Julia programming language is a compelling alternative to currently more common implementations in Python and C++ for common data analysis workflows in high energy physics. We compare the speed of implementations of different workflows in Julia with those in Python and C++. Furthermore, our studies show that the Julia implementations are competitive for tasks that are dominated by computational load rather than data access. For work that is dominated by data access, we demonstrate an application with concurrent file reading and parallel data processing.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

BARC Element Classifier (barc)

SAND2024-02120O This program enumerates and classifies all possible functional elements in several different categories within the Ballistic Asynchronous Reversible Computing (barc) model of computation. barc software is a research tool that is being used to help document the possible digital behaviors of primitive functional elements in the ABRC a.k.a. BARC model of computation. The method of operation of this software leverages elementary concepts and methods from discrete mathematics: combinatorics (permutations), partitions and equivalence classes, symmetry transformations, and the theory of finite groups. Implementation is in Python programming language. 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.

Frank, Michael↗
DOE OSTI2019

A simple json format for storing and exchanging code calculation and experimental results

Calculation codes and code systems give their results in a plethora of different formats and/or files. For instance, MCNP gives a user the MCNP specific output file, the mctal file, the ptrac file, etc. while PARTISN has a PARTISN specific output file and a number of binary files with various kinds of information about the calculation. However, the results we are interested in are always the same. These can be single values such as the effective multiplication factor k eff or the effective delayed neutron fraction β eff . It can be histogram data (such as particle spectra, reaction rates, sensitivity profiles, etc.) or even pointwise data (for example the nuclide composition as a function of time, etc.). It is also worthwhile to note that this would also apply to experimental data that we may wish to compare with as well. Calculation and experimental results can basically be split into two components: attributes (or metadata) and the actual result itself. Attributes represent information about the result that are not necessarily required for its’ interpretation but that are still good to have. Often, these attributes are what we will want to filter results on. This means that these attributes are often the answer to specific questions we may have about the result. The following is a non exhaustive list of such basic questions: what type of result is it: e.g. the effective multiplication factor k eff , the effective delayed neutron fraction β eff , etc.; which case does it relate to: e.g. a specific ICSBEP case such as PU-MET-FAST-001-001; which code and version produced this result: e.g. MCNP 6.2, etc.; which nuclear data library was used to obtain the result: e.g. ENDF/B-VIII.0 or JEFF 3.3; which nuclide and reaction does it apply to (for reaction rates and sensitivity profiles); which volume in the geometry was it calculated in? The second component of the calculation or experimental result is the actual numerical data of the result. It is this data that we want to compare, exchange, plot, interpret, etc. It consists of values with optional uncertainties and units. It also includes the underlying structure (if any structure is required to interpret the result). Depending on the type of result, it may be a single value (e.g. the effective multiplication factor), an array of values (e.g. a reaction rate or particle spectrum) or even a multidimensional array. In order to exchange results between different organisations, for instance for benchmarking, people often resort to spreadsheets or custom text files that need to be filled out. While this approach works well if little information is to be exchanged, it can become cumbersome when dealing with large amounts of data (like for instance particle spectra for thousands of cases). In addition, such an approach does not always capture the metadata we may be interested in to allow for automated processing of these files. The purpose of this report is to propose a standardised json structure to store any type of result and present an associated python interface to interact with these results directly. For such a structure to be useful, it must fulfill a specific set of functional requirements that we try to meet with this proposal. The format must allow for the calculation result to stand by itself. This means that we should not have to look in multiple places to be able to understand it. For example, if the result relates to a particle spectrum, the group structure in which the result is given should be stored with it. The format should be code agnostic. This means that we do not need to know where it came from to understand it. The format should be result type agnostic. This means that the format must be generic enough so that we can even use it for results we have not thought of yet. The format should be relatively easy to interact with through different scripting or programming languages (i.e. the machine interface) while still providing a clean structure that can be used directly by any human.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Creating an MPAS Ocean Shallow Water Core in Julia [Slides]

An MPAS model was created in Julia to test its potential for scientific HPC. Tradeoff between execution speed and development speed: Development languages (e.g. Python) are easy, but slow and production languages (e.g. C) are hard, but fast. Julia aims to be the best of both.

58 GEOSCIENCES↗
DOE OSTI2020

Hypergraph Analytics of Domain Name System Relationships

We report on the use of novel mathematical methods in hypergraph analytice over a large quantity of DNS data. Hypergraphs generalize graphs, as used in network science, to better model complex multiway relations in cyber data. Specifically, casting DNS data from Georgia Tech's ActiveDNS repository as hypergraphs allows us to fully represent the interactions between {\em collections} of domains and IP addresses. To facilitate large-scale analytics, we fielded an analytical pipeline of two capabilities. HyperNetX (HNX) is a Python package for the exploration and visualization of hypergraphs, acting as a frontend. For the backend, the Chapel HyperGraph Library (CHGL) is a library for high performance hypergraph analytics written in the exascale programming language Chapel. CHGL was used to process gigascale DNS data, performing compute-intensive calculations for data reduction and segmentation. Identified portions are then sent to HNX for both exploratory analysis and knowledge discovery targeting known tactics, techniques, and procedures.

Joslyn, Cliff A.↗
DOE OSTI2023

pyEGAF: An open-source Python library for the Evaluated Gamma-ray Activation File

The Evaluated Gamma-ray Activation File (EGAF) is one of the most comprehensive resources for thermal neutron-capture data. This database contains data from prompt gamma activation analysis measurements carried out in a consistent manner using the same experimental configuration at the Budapest Research Reactor for 245 isotopes. Although these valuable datasets have been freely available for many years, one of the drawbacks is the outdated and cryptic Evaluated Nuclear Structure Data File (ENSDF) format that is currently adopted for dissemination, making it difficult for users unfamiliar with the format to access and utilize the data contained therein. Furthermore, the ENSDF format does not readily lend itself to modern computational technologies and a parser is required to interpret the complicated mixed-record format. To help overcome these challenges, we have developed a translator to convert the ENSDF-formatted datasets into an open standard JavaScript Object Notation (JSON) format enabling accessibility to applications using different programming languages running in different environments. To compliment this effort, we have also developed an open-source software package implemented in Python, pyEGAF, that is designed to interact with the JSON data structures for general purpose access, manipulation, and analysis of the neutron-capture $\gamma$-ray data in EGAF. The new format, together with the pyEGAF library, greatly enhances access to the wider applications community where EGAF data may be useful or is required.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2024

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↗
DOE OSTI2020

Do Programmers Prefer Predictable Expressions in Code?

Source code is a form of human communication, albeit one where the information shared between the programmers reading and writing the code is constrained by the requirement that the code executes correctly. Programming languages are more syntactically constrained than natural languages, but they are also very expressive, allowing a great many different ways to express even very simple computations. Still, code written by developers is highly predictable, and many programming tools have taken advantage of this phenomenon, relying on language model surprisal as a guiding mechanism. Additionally, while surprisal has been validated as a measure of cognitive load in natural language, its relation to human cognitive processes in code is still poorly understood. In this paper, we explore the relationship between surprisal and programmer preference at a small granularity—do programmers prefer more predictable expressions in code? Using meaning-preserving transformations, we produce equivalent alternatives to developer-written code expressions and run a corpus study on Java and Python projects. In general, language models rate the code expressions developers choose to write as more predictable than these transformed alternatives. Then, we perform two human subject studies asking participants to choose between two equivalent snippets of Java code with different surprisal scores (one original and transformed). We find that programmers do prefer more predictable variants, and that stronger language models like the transformer align more often and more consistently with these preferences.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Comparing the Performance of Julia on CPUs versus GPUs and Julia-MPI versus Fortran-MPI: a case study with MPAS-Ocean (Version 7.1)

Abstract. Some programming languages are easy to develop at the cost of slow execution, while others are fast at runtime but much more difficult to write. Julia is a programming language that aims to be the best of both worlds – a development and production language at the same time. To test Julia's utility in scientific high-performance computing (HPC), we built an unstructured-mesh shallow water model in Julia and compared it against an established Fortran-MPI ocean model, the Model for Prediction Across Scales–Ocean (MPAS-Ocean), as well as a Python shallow water code. Three versions of the Julia shallow water code were created: for single-core CPU, graphics processing unit (GPU), and Message Passing Interface (MPI) CPU clusters. Comparing identical simulations revealed that our first version of the Julia model was 13 times faster than Python using NumPy, where both used an unthreaded single-core CPU. Further Julia optimizations, including static typing and removing implicit memory allocations, provided an additional 10–20× speed-up of the single-core CPU Julia model. The GPU-accelerated Julia code was almost identical in terms of performance to the MPI parallelized code on 64 processes, an unexpected result for such different architectures. Parallelized Julia-MPI performance was identical to Fortran-MPI MPAS-Ocean for low processor counts and ranges from 2× faster to 2× slower for higher processor counts. Our experience is that Julia development is fast and convenient for prototyping but that Julia requires further investment and expertise to be competitive with compiled codes. We provide advice on Julia code optimization for HPC systems.

54 ENVIRONMENTAL SCIENCES↗