SEARCH · Engineering Papers

Results for “programming 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.

SourceResearch connectionFrom yearThrough year

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

At least 145 records · Page 8

All sources NASA NTRS DOE OSTI

DOE OSTI2019

Parsl: Pervasive Parallel Programming in Python

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

parallel programming↗

DOE OSTI2020

The Kokkos Ecosystem [Brief]

In 2016/2017, the field of High-Performance Computing (HPC) entered a new era driven by fundamental physics challenges to produce ever more energy and cost-efficient processors. Since the convergence on the Message-Passing Interface (MPI) standard in the mid-1990s, application developers enjoyed a seemingly static view of the underlying machine — that of a distributed collection of homogeneous nodes executing in collaboration. However, after almost two decades of dominance, the sole use of MPI to derive parallelism acted as a limiter to improved future performance. While MPI is widely expected to continue to function as the basic mechanism for communication between compute nodes for the immediate future, additional parallelism is required on the computing node itself if high performance and efficiency goals are to be realized. When reviewing the architectures of the top HPC systems today, the change in paradigm is clear: the compute nodes of the leading machines in the world are either powered by many-core chips with a few dozen cores each, or use heterogeneous designs, where traditional CPUs marshal work to massively parallel compute accelerators which has as many as 200,000 processing threads in flight simultaneously. Complicating matters further for application developers, each processor vendor has its own preferred way of writing code for their architecture.The Kokkos EcoSystem was released by Sandia in 2017 to address this new era in HPC system design by providing a vendor independent performance portable programming system for scientific, engineering, and mathematical software applications written in the C++ programming language. Using Kokkos, application developers can be more productive because they will not have to create and maintain separate versions of their software for each architecture, nor will they have to be experts in each architecture's peculiar requirements. Instead, they will have a single method of programming for the diverse set of modern HPC architectures. While Kokkos started in 2011 as a programming model only, it soon became clear that complex applications needed more. It is also critical to have a portable mathematical functions and developers need tools to debug their applications, gain insight into the performance characteristics of their codes and tune algorithm performance parameters through automated processes. The Kokkos EcoSystem addresses those needs through its three main components: the Kokkos Core programming model, the Kokkos Kernels math library, and the Kokkos Tools project.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2016

Lightweight runtime checking of C programs with RTC

The C Programming Language is known for being an efficient language that can be compiled on almost any architecture and operating system. However the absence of dynamic safety checks and a relatively weak type system allows programmer oversights that are hard to spot. In this paper, we present RTC, a runtime monitoring tool that instruments unsafe code and monitors the program execution. RTC is built on top of the ROSE compiler infrastructure. RTC finds memory bugs and arithmetic overflows and underflows, and run-time type violations. Most of the instrumentations are directly added to the source file and only require a minimal runtime system. As a result, the instrumented code remains portable. In tests against known error detection benchmarks, RTC found 98% of all memory related bugs and had zero false positives. Finally, in performance tests conducted with well known algorithms, such as binary search and MD5, we determined that our tool has an average run-time overhead rate of 9.7× and memory overhead rate of 3.5×.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

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↗

DOE OSTI2014

Why scientists should learn to program in Python

Scientists have been central to the historical development of the computer industry, but the importance of software only continues to grow for all areas of scientific research and in particular for powder diffraction. Knowing how to program a computer is a basic and useful skill for scientists. The article introduces the three types of programming languages and why scripting languages are now preferred for scientists. Of them, the authors assert Python is the most useful and easiest to learn. Python is introduced. Also presented is an overview to a few of the many add-on packages available to extend the capabilities of Python, for example, for numerical computations, scientific graphics and graphical user interface programming.

97 MATHEMATICS AND COMPUTING↗

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 OSTI2026

Digitizing Today’s Buildings in the Real World: Lessons from Field Demonstrations

Digital twins, created by generating a virtual replica of a building, enable safe evaluation of operational scenarios and applications like fault detection and diagnosis and advanced controls. However, a prerequisite is the creation of a machine-readable digital representation of a building, currently hindered by fragmented information scattered across mechanical drawings, point lists, and natural language sequences. As a result, digital twin development remains labor-intensive, error-prone, and difficult to validate. To address these challenges, two efforts from ASHRAE aim to support the digitalization of buildings. ASHRAE s223 establishes a semantic model of buildings, representing system components, configuration, and data sources. ASHRAE s231 defines a vendor-neutral programming language for expressing their control logic. As the industry evaluates implementing them in their products, understanding the challenges that vendors and implementers may face is crucial. In this paper, we present findings and lessons learned from field demonstrations in five buildings that implemented control applications using ASHRAE s223 and s231. The demonstrations highlight how semantic modeling and formalized control descriptions can significantly reduce software development time, manual point mapping, and hard-coding. Beyond time efficiency, they enable reliable automation by minimizing human interpretation and providing a means for consistency across projects. We describe the processes and best practices for model creation and model usage, from translating heterogeneous building documentation into semantic representations to implementing control logic in real-world systems. Finally, we discuss the challenges that persist, including integration with legacy software environments, gaps in interoperability, and the level of expertise still required to effectively leverage semantic models.

Prakash, Anand Krishnan↗

DOE OSTI2017

CUDA Computation of the Feynman Distribution

In 2006, NVIDIA Corporation introduced the Computer Unified Device Architecture (CUDA) for C, C++, and Fortran programming languages. The CUDA parallel computing platform uses the Graphics Processing Unit (GPU) of NVIDIA graphics card, and it is designed for parallel computations. In these computations, the same algorithms are executed on the data in parallel. The GPU contains many Streaming Multiprocessors (SM) that can independently execute blocks of threads. A thread is a sequence of serial programmed instructions. The SM executes threads in groups of 32 and a group of 32 threads is called warp. The threads within a block can be synchronized and have access to a shared memory that is visible only to them. Conversely, blocks of threads cannot be synchronized and have access only to the global memory of the graphics card. This memory is called device memory and is independent of the host memory controlled by the Central Processing Unit (CPU). A single thread has access to a local memory (register) that is not visible to any other thread. The part of the program that is executed on the graphics card is called kernel. Each thread of the kernel has a unique identification index that is accessible by the in-built variable threadIdx; the latter is a 3-component vector. A threads block can contain up to 1024 threads. Blocks of threads have a unique identification index that is accessible by the in-built variable blockIdx; the latter is a 3-component vector. The in-built variable blockDim contains the number of threads per block; this variable is a 3-component vector. Threads and blocks represent different levels of parallelism; a kernel is executed as a grid of blocks of threads. Figure 1 illustrates a grid of thread blocks for a GPU with 2 SM. A SM can execute multiple blocks of threads in parallel; a block of threads is executed on a single SM. A GPU can execute multiple kernels concurrently. This work has used the Quadro M5000 graphics card with the following technical specifications: - 2048 cores with 861 MHz frequency, - 16 streaming multiprocessors, - 5.2 trillion transistors, - 8.2 Gb device memory, - 64 kb register memory (per thread), - 48 kb shared memory (per block) - 211.6 GB/s memory bandwidth, and - 3.5 GFLOPS floating point performance.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2017

STARlight: A Monte Carlo simulation program for ultra-peripheral collisions of relativistic ions

© 2016 Elsevier B.V. Ultra-peripheral collisions (UPCs) have been a significant source of study at RHIC and the LHC. In these collisions, the two colliding nuclei interact electromagnetically, via two-photon or photonuclear interactions, but not hadronically; they effectively miss each other. Photonuclear interactions produce vector meson states or more general photonuclear final states, while two-photon interactions can produce lepton or meson pairs, or single mesons. In these interactions, the collision geometry plays a major role. We present a program, STARlight, that calculates the cross-sections for a variety of UPC final states and also creates, via Monte Carlo simulation, events for use in determining detector efficiency. Program summary Program Title: STARlight (v2.2) Program Files doi: http://dx.doi.org/10.17632/xjpf4rxtbj.1 Licensing provisions: GNU GPLv3 Programming Language: C++ External Routines: PYTHIA 8.2 and DPMJET 3.0 are needed for some final states. Nature of problem: The cross-section for ultra-peripheral collisions is obtained by integrating the photon fluxes in transverse impact parameter space, subject to the requirement (which is also impact parameter dependent) that the colliding nuclei do not interact hadronically. The program is a two step process. First, it calculates the cross-sections for the reaction of interest, as a function of W (photon–Pomeron or two-photon center of mass energy), Y (final state rapidity) and pT (final state transverse momentum). Second, STARlight generates Monte Carlo events which can be used to determine cross-sections within specific kinematic constraints or for studies of detector efficiencies. The second step includes the decay of any unstable particles produced in the reaction, with appropriate consideration of particle spins and parity. It outputs these events in ASCII format. Solution method: The program generates a two dimensional look-up table of the production cross-section as a function of final state rapidity and mass. The dimensions of the table are selectable, allowing the user to choose the desired accuracy. For certain final states, a second two-dimensional look-up table, giving the transverse momentum distribution, as a function of rapidity, is also used. With these look-up tables, the program generates final states. Particle decays and the final angular distributions are calculated for each event. Restrictions: The program is focused on ultra-relativistic collisions at Brookhaven's RHIC (Relativistic Heavy Ion Collider) and CERN's LHC (Large Hadron Collider), with final states that are visible in a central detector. At lower energies (i.e., at the CERN SPS), caution should be exercised because STARlight does not account for the longitudinal momentum transfer to the nucleus; this is larger at low beam energies. References: http://starlight.hepforge.org and references in this article.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

DOE OSTI2017

Decision Analyses Related to Groundwater Remediation - 17051

Traditional decision analyses of groundwater remediation scenarios frequently fail because the probability of adverse, unanticipated events occurring is often high. This is driven by many factors including that (1) the models developed to represent the flow and transport in contaminated aquifers are typically simpler than reality and do not account for all the important governing processes, (2) probability distributions are assigned to critical performance parameters (such as model inputs or characteristics of the engineered remediation systems) even though some of these parameters might be unknown or not be very well constrained. However, there is a novel decision analysis methodology and a computational tool based on Bayesian Information-Gap Decision Theory (BIG-DT) that are designed to mitigate the shortcomings of the models and probabilistic decision analyses by leveraging a non-probabilistic decision theory -- information-gap decision theory. The new decision analysis methodology considers possible models that have not been explicitly enumerated and does not require us to commit to a particular probability distribution for model and remediation-design parameters. Both the set of possible models and the set of possible probability distributions grow as the degree of uncertainty increases. The fundamental question that BIG-DT asks is 'How large can these sets be before a particular decision results in an undesirable outcome?'. The decision that allows these sets to be the largest is considered to be the best option. In this way, BIG-DT enables robust decision-support for groundwater remediation problems. Here, we apply BIG-DT to a representative groundwater remediation scenario where different options for hydraulic containment and pump and treat are being considered. BIG-DT requires many model runs and high-performance computing resources are needed when complex models are used. We demonstrate the BIG-DT analyses on a series of synthetic problems that are designed to be consistent with real-world problems such as Los Alamos National Laboratory (LANL) contamination sites. We also discuss a general framework for how the BIG-DT analyses will be carried out at the chromium groundwater contamination site at LANL. BIG-DT is implemented in Julia (a high-level, high-performance dynamic programming language for technical computing) and is part of the MADS framework (http://mads.lanl.gov and http://madsjulia.github.io/Mads.jl). (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

DOE OSTI2021

Data From: Influence of Hydrological Perturbations and Riverbed Sediment Characteristics on Hyporheic Zone Respiration of CO2 and N-2, Journal of Geophysical Research-Biogeosciences

This data package contains pumping data (.txt), parameter matrices, and R code (.R, .RData) to perform bootstrapping for parameter selection for the bioclogging model development. The pumping data were collected from the Russian River Riverbank Filtration site located in Sonoma County, California from 2010-2017 from three riverbank collection wells located alongside the study site. The pumping data is directly correlated with water table oscillations, so the code performs these correlations and simulates stochastic versions of water table oscillations. See Metadata Description.pdf for full details on dataset production. This dataset must be used with the R programming language. This dataset and R code is associated with the publication "Influence of Hydrological Perturbations and Riverbed Sediment Characteristics on Hyporheic Zone Respiration of CO2 and N-2"This research was supported by the Jane Lewis Fellowship from the University of California, Berkeley, the Sonoma County Water Agency (SCWA), the Roy G. Post Foundation Scholarship, the U.S. Department of Energy, Office of Science Graduate Student Research (SCGSR) Program, U.S. Department of Energy, Office of Science, Office of Biological and Environmental Research under award DE-AC02-05CH11231, and the UFZ-Helmholtz Centre for Environmental Research, Leipzig, Germany.

54 ENVIRONMENTAL SCIENCES↗

DOE OSTI2016

Verifying quantitative reliability for programs that execute on unreliable hardware

Emerging high-performance architectures are expected to contain unreliable components that may exhibit soft errors, which silently corrupt the results of computations. Full detection and masking of soft errors is challenging, expensive, and, for some applications, unnecessary. For example, approximate computing applications (such as multimedia processing, machine learning, and big data analytics) can often naturally tolerate soft errors. We introduce Rely, a programming language that enables developers to reason about the quantitative reliability of an application—namely, the probability that it produces the correct result when executed on unreliable hardware. Rely allows developers to specify the reliability requirements for each value that a function produces. We perform a static quantitative reliability analysis that verifies quantitative requirements on the reliability of an application, enabling a developer to perform sound and verified reliability engineering. The analysis takes a Rely program with a reliability specification and a hardware specification that characterizes the reliability of the underlying hardware components and verifies that the program satisfies its reliability specification when executed on the underlying unreliable hardware platform. We demonstrate the application of quantitative reliability analysis on six computations implemented in Rely.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2025

A universal implementation of radiative effects in neutrino event generators

Due to the similarities between electron-nucleus (eA) and neutrino-nucleus scattering (νA), eA data can contribute key information to improve cross-section modeling in eA and hence in νA event generators. However, to compare data and generated events, either the data must be radiatively corrected or radiative effects need to be included in the event generators. We implemented a universal radiative corrections program that can be used with all reaction mechanisms and any eA event generator. Our program includes real photon radiation by the incident and scattered electrons, and virtual photon exchange and photon vacuum polarization diagrams. It uses the “extended peaking” approximation for electron radiation and neglects charged hadron radiation. This method, validated with GENIE, can also be extended to simulate νA radiative effects. This work facilitates data-event-generator comparisons used to improve νA event generators for the next-generation of neutrino experiments. Program Title: emMCRadCorr CPC Library link to program files:https://doi.org/10.17632/hmsxg82vnf.1 Developer's repository link:https://github.com/e4nu/emMCRadCorr Licensing provisions: AGPLv3 Programming language:C++ Nature of problem: Radiative effects can significantly modify the event kinematics and the resulting cross-sections. Such effects must be accounted for when comparing event generators to eA data. Existing radiative correction codes are tailored to specific processes and topologies, and are limited to a restricted phase space defined by the spectrometer acceptance. Therefore, a more general approach is required to apply radiative corrections to semi-inclusive and exclusive eA measurements. Solution method: Our program incorporates real photon radiation from both the incident and scattered electrons, as well as virtual photon exchange and photon vacuum polarization effects. It employs the “extended peaking” approximation for electron radiation while neglecting contributions from charged hadron radiation. The code is fully decoupled from event generator codes and can be used for all event generators in the market.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

DOE OSTI2013

Storyboard method of end-user programming with natural language configuration

A technique for end-user programming includes populating a template with graphically illustrated actions and then invoking a command to generate a screen element based on the template. The screen element is rendered within a computing environment and provides a mechanism for triggering execution of a sequence of user actions. The sequence of user actions is based at least in part on the graphically illustrated actions populated into the template.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2015

Photon-HDF5: an open file format for single-molecule fluorescence experiments using photon-counting detectors

We introduce Photon-HDF5, an open and efficient file format to simplify exchange and long term accessibility of data from single-molecule fluorescence experiments based on photon-counting detectors such as single-photon avalanche diode (SPAD), photomultiplier tube (PMT) or arrays of such detectors. The format is based on HDF5, a widely used platform- and language-independent hierarchical file format for which user-friendly viewers are available. Photon-HDF5 can store raw photon data (timestamp, channel number, etc) from any acquisition hardware, but also setup and sample description, information on provenance, authorship and other metadata, and is flexible enough to include any kind of custom data. The format specifications are hosted on a public website, which is open to contributions by the biophysics community. As an initial resource, the website provides code examples to read Photon-HDF5 files in several programming languages and a reference python library (phconvert), to create new Photon-HDF5 files and convert several existing file formats into Photon-HDF5. As a result, to encourage adoption by the academic and commercial communities, all software is released under the MIT open source license.

59 BASIC BIOLOGICAL SCIENCES↗

DOE OSTI2019

BCL: A Cross-Platform Distributed Data Structures Library

One-sided communication is a useful paradigm for irregular parallel applications, but most one-sided programming environments, including MPI's one-sided interface and PGAS programming languages, lack application-level libraries to support these applications. We present the Berkeley Container Library, a set of generic, cross-platform, high-performance data structures for irregular applications, including queues, hash tables, Bloom filters and more. BCL is written in C++ using an internal DSL called the BCL Core that provides one-sided communication primitives such as remote get and remote put operations. The BCL Core has backends for MPI, OpenSHMEM, GASNet-EX, and UPC++, allowing BCL data structures to be used natively in programs written using any of these programming environments. Along with our internal DSL, we present the BCL ObjectContainer abstraction, which allows BCL data structures to transparently serialize complex data types while maintaining efficiency for primitive types. We also introduce the set of BCL data structures and evaluate their performance across a number of high-performance computing systems, demonstrating that BCL programs are competitive with hand-optimized code, even while hiding many of the underlying details of message aggregation, serialization, and synchronization.

Brock, Benjamin↗

DOE OSTI2019

ROBOT: A Tool for Automating Ontology Workflows

BACKGROUND:Ontologies are invaluable in the life sciences, but building and maintaining ontologies often requires a challenging number of distinct tasks such as running automated reasoners and quality control checks, extracting dependencies and application-specific subsets, generating standard reports, and generating release files in multiple formats. Similar to more general software development, automation is the key to executing and managing these tasks effectively and to releasing more robust products in standard forms. For ontologies using the Web Ontology Language (OWL), the OWL API Java library is the foundation for a range of software tools, including the Protégé ontology editor. In the Open Biological and Biomedical Ontologies (OBO) community, we recognized the need to package a wide range of low-level OWL API functionality into a library of common higher-level operations and to make those operations available as a command-line tool. RESULTS:ROBOT (a recursive acronym for "ROBOT is an OBO Tool") is an open source library and command-line tool for automating ontology development tasks. The library can be called from any programming language that runs on the Java Virtual Machine (JVM). Most usage is through the command-line tool, which runs on macOS, Linux, and Windows. ROBOT provides ontology processing commands for a variety of tasks, including commands for converting formats, running a reasoner, creating import modules, running reports, and various other tasks. These commands can be combined into larger workflows using a separate task execution system such as GNU Make, and workflows can be automatically executed within continuous integration systems. CONCLUSIONS:ROBOT supports automation of a wide range of ontology development tasks, focusing on OBO conventions. It packages common high-level ontology development functionality into a convenient library, and makes it easy to configure, combine, and execute individual tasks in comprehensive, automated workflows. This helps ontology developers to efficiently create, maintain, and release high-quality ontologies, so that they can spend more time focusing on development tasks. It also helps guarantee that released ontologies are free of certain types of logical errors and conform to standard quality control checks, increasing the overall robustness and efficiency of the ontology development lifecycle.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

DOE OSTI2020

Uses of Sensitivity/Uncertainty Techniques for Critical Experiment Design [Slides]

This presentation discusses the programming languages TSUNAMI and TSAR. It also provides a review of experimental designs using sensitivity analysis in regard to 7uPCX fuel design, fission product experiment analysis, MIRTE, and temperature dependent experiments at the Sandia Pulsed Reactor Facility (SPRF).

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗