Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 1,207 records · Page 67
All sourcesNASA NTRSDOE OSTI
DOE OSTI2020

pnnl/isomorphic

Isomorphic is a Ruby library for specifying isomorphisms between Ruby objects. The inventive features of the new Ruby library are as follows: Domain-specific language (DSL) for declaration of isomorphisms between Ruby objects. Functional references (viz., "lenses") for getter/setter operations. To our knowledge, this is the first library of its kind for the Ruby programming language. Moreover, to our knowledge, this is the first implementation of the "functional references" concept within the Ruby programming language.

Borkum, Mark↗
DOE OSTI2026

SEED: Semantic Energy Exploration and Discovery

The Bioenergy Knowledge Discovery Framework (KDF) hosts a vast repository of specialized data, yet traditional keyword-based search methods often struggle to provide direct answers, requiring significant domain expertise and manual effort to filter through raw documents. To overcome these barriers, this software introduces a semantic search engine that enables both specialists and non-specialists to query the KDF using natural language. By shifting from rigid keyword matching to intent-based retrieval, the tool automatically identifies and ranks the most relevant sources within the database. The system functions by processing natural language queries to extract the most pertinent information, delivering an AI-generated plain-language summary alongside exact supporting quotes from retrieved documents. This integrated approach provides users with immediate, evidence-based answers while eliminating the need for exhaustive manual review. By surfacing direct insights and contextual evidence, the software enhances the usability of existing KDF resources and democratizes access to complex bioenergy data. Ultimately, this semantic search solution accelerates the discovery process and supports faster, more informed decision-making across the bioenergy sector.

Pan, Meiyu (Melrose) [Oak Ridge National Laborator↗
DOE OSTI2026

Wolf

The Workflow Orchestration Language Framework (WOLF) is an agentic framework grounded in natural language with an architecture inspired by reinforcement learning (RL)—designed to orchestrate, scale, and accelerate complex workflows. The concept of WOLF was born out of the very successful ASC Tri-lab Multi-Agent Design Assistant (MADA) project, but extends beyond its domain-specific design agents to provide a more general and extensible architecture. WOLF capitalizes on the lessons learned from MADA and is fully aligned with Sutton’s The Bitter Lesson—that the most enduring progress in AI comes from general-purpose methods that scale with computation, rather than narrow techniques built on domain-specific human knowledge. In this spirit, WOLF enables agents to autonomously learn workflows, capture strategies as reusable playbooks, and build a growing corpus of interpretable, auditable “wisdom artifacts.” These artifacts, expressed in natural language, bridge human and machine understanding while preserving adaptability and scalability as computational power continues to expand.

Boureima, Ismaeal↗
DOE OSTI2021

A survey of software implementations used by application codes in the Exascale Computing Project

The US Department of Energy Office of Science and the National Nuclear Security Administration initiated the Exascale Computing Project (ECP) in 2016 to prepare mission-relevant applications and scientific software for the delivery of the exascale computers starting in 2023. The ECP currently supports 24 efforts directed at specific applications and six supporting co-design projects. These 24 application projects contain 62 application codes that are implemented in three high-level languages—C, C++, and Fortran—and use 22 combinations of graphical processing unit programming models. The most common implementation language is C++, which is used in 53 different application codes. The most common programming models across ECP applications are CUDA and Kokkos, which are employed in 15 and 14 applications, respectively. This article provides a survey of the programming languages and models used in the ECP applications codebase that will be used to achieve performance on the future exascale hardware platforms.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Managing genomic variant calling workflows with Swift/T

Bioinformatics research is frequently performed using complex workflows with multiple steps, fans, merges, and conditionals. This complexity makes management of the workflow difficult on a computer cluster, especially when running in parallel on large batches of data: hundreds or thousands of samples at a time. Scientific workflow management systems could help with that. Many are now being proposed, but is there yet the “best” workflow management system for bioinformatics? Such a system would need to satisfy numerous, sometimes conflicting requirements: from ease of use, to seamless deployment at peta- and exa-scale, and portability to the cloud. We evaluated Swift/T as a candidate for such role by implementing a primary genomic variant calling workflow in the Swift/T language, focusing on workflow management, performance and scalability issues that arise from production-grade big data genomic analyses. In the process we introduced novel features into the language, which are now part of its open repository. Additionally, we formalized a set of design criteria for quality, robust, maintainable workflows that must function at-scale in a production setting, such as a large genomic sequencing facility or a major hospital system. The use of Swift/T conveys two key advantages. (1) It operates transparently in multiple cluster scheduling environments (PBS Torque, SLURM, Cray aprun environment, etc.), thus a single workflow is trivially portable across numerous clusters. (2) The leaf functions of Swift/T permit developers to easily swap executables in and out of the workflow, which makes it easy to maintain and to request resources optimal for each stage of the pipeline. While Swift/T’s data-level parallelism eliminates the need to code parallel analysis of multiple samples, it does make debugging more difficult, as is common for implicitly parallel code. Nonetheless, the language gives users a powerful and portable way to scale up analyses in many computing architectures.

Science & Technology - Other Topics↗
DOE OSTI2022

The Policy Mullet: Good Intentions in the Front, Bad Policy in the Back

To achieve important policy goals like decarbonization, energy efficiency, and social justice, it is important to translate high-level policy into operational practice. Establishing sustainable purchasing goals has been one important part of this translation. However, not all sustainable purchasing policies are equally effective for organizations. In this study, we analyze sustainable purchasing policies collected from 30 public-sector organizations. We discuss a theoretical framework of optimal policy language and use that framework to evaluate the policies we collected. We believe that an ideal sustainable purchasing policy can increase the likelihood of implementation success by providing more product-specific guidance, giving authority to procurement staff, setting performance targets, and requiring reporting to account for progress. In our review of public sector sustainable purchasing policies, we found that policy language is less than ideal when measured against the framework. Based on our findings, we highlight the best practice language organizations can use in their sustainable purchasing policies to meet sustainability goals. While there is more work needed to inform best practices with sustainable purchasing policies, we recommend that organizations utilize existing frameworks when developing a sustainable purchasing policy to encourage better implementation.

99 GENERAL AND MISCELLANEOUS↗
DOE OSTI2023

CMakePPLang: An object-oriented extension to CMake

CMakePPLang is an object-oriented extension to the CMake language written entirely using the original CMake language, with the goal of making projects built on CMake easier to create and maintain. That said, CMakePPLang has different coding practices, paradigms, and standards than the original CMake language, much in the same way that C++ coding differs from C coding despite some level of interoperability. Currently, CMakePPLang is used within the CMakePP organization as the foundation for two in-progress projects: CMakeTest and CMaize. CMakeTest provides a solution for unit testing CMake and CMakePPLang code. CMaize is a CMake tool to simplify interoperability between projects and writing their build systems.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2013

Neurons to algorithms LDRD final report.

Over the last three years the Neurons to Algorithms (N2A) LDRD project teams has built infrastructure to discover computational structures in the brain. This consists of a modeling language, a tool that enables model development and simulation in that language, and initial connections with the Neuroinformatics community, a group working toward similar goals. The approach of N2A is to express large complex systems like the brain as populations of a discrete part types that have specific structural relationships with each other, along with internal and structural dynamics. Such an evolving mathematical system may be able to capture the essence of neural processing, and ultimately of thought itself. This final report is a cover for the actual products of the project: the N2A Language Specification, the N2A Application, and a journal paper summarizing our methods.

Rothganger, Fredrick H.↗
DOE OSTI2016

Highlights of X-Stack ExM Deliverable Swift/T

Swift/T is a key success from the ExM: System support for extreme-scale, many-task applications1 X-Stack project, which proposed to use concurrent dataflow as an innovative programming model to exploit extreme parallelism in exascale computers. The Swift/T component of the project reimplemented the Swift language from scratch to allow applications that compose scientific modules together to be build and run on available petascale computers (Blue Gene, Cray). Swift/T does this via a new compiler and runtime that generates and executes the application as an MPI program. We assume that mission-critical emerging exascale applications will be composed as scalable applications using existing software components, connected by data dependencies. Developers wrap native code fragments using a higherlevel language, then build composite applications to form a computational experiment. This exemplifies hierarchical concurrency: lower-level messaging libraries are used for fine-grained parallelism; highlevel control is used for inter-task coordination. These patterns are best expressed with dataflow, but static DAGs (i.e., other workflow languages) limit the applications that can be built; they do not provide the expressiveness of Swift, such as conditional execution, iteration, and recursive functions.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Introduction to Python for CMF Authority Users

This talk is a very broad over view of Python that highlights key features in the language used in the Common Model Framework (CMF). I assume that the audience has some programming experience in a shell scripting language (C shell, Bash, PERL) or other high level language (C/C++/ Fortran). The talk will cover Python data types, classes (objects) and basic programming constructs. The talk concludes with slides describing how I developed the basic classes for a TITANS homework assignment.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Effective Vectorization with OpenMP 4.5

This paper describes how the Single Instruction Multiple Data (SIMD) model and its extensions in OpenMP work, and how these are implemented in different compilers. Modern processors are highly parallel computational machines which often include multiple processors capable of executing several instructions in parallel. Understanding SIMD and executing instructions in parallel allows the processor to achieve higher performance without increasing the power required to run it. SIMD instructions can significantly reduce the runtime of code by executing a single operation on large groups of data. The SIMD model is so integral to the processor s potential performance that, if SIMD is not utilized, less than half of the processor is ever actually used. Unfortunately, using SIMD instructions is a challenge in higher level languages because most programming languages do not have a way to describe them. Most compilers are capable of vectorizing code by using the SIMD instructions, but there are many code features important for SIMD vectorization that the compiler cannot determine at compile time. OpenMP attempts to solve this by extending the C++/C and Fortran programming languages with compiler directives that express SIMD parallelism. OpenMP is used to pass hints to the compiler about the code to be executed in SIMD. This is a key resource for making optimized code, but it does not change whether or not the code can use SIMD operations. However, in many cases critical functions are limited by a poor understanding of how SIMD instructions are actually implemented, as SIMD can be implemented through vector instructions or simultaneous multi-threading (SMT). We have found that it is often the case that code cannot be vectorized, or is vectorized poorly, because the programmer does not have sufficient knowledge of how SIMD instructions work.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Evaluation of the FIR Example using Xilinx Vivado High-Level Synthesis Compiler

Compared to central processing units (CPUs) and graphics processing units (GPUs), field programmable gate arrays (FPGAs) have major advantages in reconfigurability and performance achieved per watt. This development flow has been augmented with high-level synthesis (HLS) flow that can convert programs written in a high-level programming language to Hardware Description Language (HDL). Using high-level programming languages such as C, C++, and OpenCL for FPGA-based development could allow software developers, who have little FPGA knowledge, to take advantage of the FPGA-based application acceleration. This improves developer productivity and makes the FPGA-based acceleration accessible to hardware and software developers. Xilinx Vivado HLS compiler is a high-level synthesis tool that enables C, C++ and System C specification to be directly targeted into Xilinx FPGAs without the need to create RTL manually. The white paper [1] published recently by Xilinx uses a finite impulse response (FIR) example to demonstrate the variable-precision features in the Vivado HLS compiler and the resource and power benefits of converting floating point to fixed point for a design. To get a better understanding of variable-precision features in terms of resource usage and performance, this report presents the experimental results of evaluating the FIR example using Vivado HLS 2017.1 and a Kintex Ultrascale FPGA. In addition, we evaluated the half-precision floating-point data type against the double-precision and single-precision data type and present the detailed results.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

2018 Annual Site Environmental Report

Los Alamos National Laboratory’s (the Laboratory’s) annual site environmental reports are prepared annually by the Laboratory’s environmental organizations, as required by U.S. Department of Energy Order 231.1B, Administrative Change 1, Environment, Safety, and Health Reporting, and Order 458.1, Administrative Change 3, Radiation Protection of the Public and the Environment. The following chapters in this report discuss our success in complying with environmental laws, regulations, and orders (Chapter 2, Compliance Summary); how we manage the Laboratory’s environmental performance (Chapter 3, Environmental Programs); how we monitor for air emissions of radioactive materials and climate conditions (Chapter 4, Air Quality); how we monitor for effects of Laboratory operations on groundwater quality (Chapter 5, Groundwater Monitoring); how we monitor the movement of chemicals and radionuclides by storm water runoff and the levels of chemicals and radionuclides in deposited sediment (Chapter 6, Watershed Quality); how we monitor for the presence, levels, and effects of chemicals and radionuclides in plants, animals, soil, and vegetation (Chapter 7, Ecosystem Health); and finally, what radionuclide dose or risk from chemical exposure members of the public may experience as a result of Laboratory operations (Chapter 8, Public Dose and Risk Assessment). This report follows plain language guidelines, as required for federal agencies by the Plain Language Act of 2010. More information about plain language can be found at http://www.plainlanguage.gov/index.cfm. You will notice we have substantially reduced the use of acronyms and abbreviations and are using active voice and personal pronouns. We hope you find this report useful. If you have suggestions for improving this report, additional questions, or want a copy of this report, please contact us at envoutreach@lanl.gov, or call the Communications Office at 505-665-7000. This report, its supplemental tables, and the 2018 Annual Site Environmental Report Summary are available at http://www.lanl.gov/environment/environmental-report.php. Note: This document has been revised since it was initially published on September 23, 2019. The revisions included corrections to figure and table references, changes in heading levels, adding blank pages where appropriate, and changes of an editorial nature.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2020

A software package for modeling and simulating fault graphs

This report describes a novel fault graph modeling language and a simulation tool for executing models specified in the language. The modeling language has three primary features that distinguish it from similar reliability analysis tools. These are (1) a random variable modeling several distinct outcomes of a single fault; (2) chains of faults in which one fault triggers another; and (3) time to fail sampled from probability distributions including positive normal, exponential, Weibull with a minimum, or immediate. These features are motivated by their use in a historical analysis of centrifuge reliability.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

DOE Express Quantum Computing Application Teams (QCAT FY20 Report)

The QCOR project consists of 4 main research tasks: 1) scientific applications and algorithm development for machine learning (ML) and quantum theories of condensed matter systems and lattice gauge theories; 2) high-level quantum-classical (HLQC) language and domain specific language (DSL) development; 3) compiler and interfaces development for the HLQC language; and 4) hardware-level control, optimization, and algorithms libraries. In the succeeding sections we report on progress towards our research tasks during the 2020 calendar year.

75 CONDENSED MATTER PHYSICS, SUPERCONDUCTIVITY AND↗
DOE OSTI2023

S4PST: Sustainability for Programming Systems and Tools: May Workshop Report

The US Department of Energy (DOE) Exascale Computing Project (ECP) has fostered and strengthened the use of modern software engineering practices for developing applications and libraries, and this effort has resulted in the coordinated and interoperable E4S1 and xSDK2 ecosystems. Although this approach is cost-effective, it relies on robust programming systems and tools (PST) as the underlying foundation for our HPC software. At present, our primary PST stack consists of traditional high-performance computing (HPC) languages, namely Fortran, C, C++, and the popular Python language for data analysis and AI workflows. These languages support various programming frameworks and run-time abstractions that enable parallelism and concurrency across multiple node architectures and thousands of nodes through a variety of interconnect systems. However, to accommodate users’ diverse needs, certain aspects of the HPC ecosystem are delegated to vendor-specific or third-party implementations that extend beyond a particular scientific domain. This broader scope results in a multitude of specifications and variations, which leads to a complex orchestration of many-ecosystems. Unfortunately, this complexity in the ecosystem imposes additional overhead costs on consumers during the latter stages of the development cycle. In addition to the software ecosystem challenge, the upcoming conclusion of the ECP by December 2023 has raised significant concerns within the HPC programming systems community, from both the economic and social perspectives. The ECP has implemented a management structure for software development and funding decisions across all ECP participants by following a conventional hierarchical and centralized approach. However, this structure has prompted certain considerations within the community, particularly in anticipation of the Software Sustainability initiative by the DOE’s Advanced Scientific Computing Research Program (ASCR). For the success of this new initiative, it is of utmost importance to secure consistent funding and foster close engagement with researchers and core developers of existing programming-system products. This collaboration is vital to maintaining the critical capabilities of the current software during the transition phase while proactively adapting to future technology and workforce trends. The community recognizes the significance of adapting to emerging trends and is aware of the inherent fragility of the HPC software ecosystem, particularly in relation to programming systems that cater to all users. The ability to adapt and evolve is essential to staying relevant and effectively addressing these technical, economic, and social challenges. The S4PST team, which represents one of the six ASCR Software Sustainability seedling projects, is dedicated to tackling these challenges through community-based approaches that go beyond the scope of the DOE. This involves collaboration between national laboratories with academia, non-DOE institutions, hardware and system vendors, and international partners. By fostering these partnerships, we aim to create a robust and sustainable HPC software ecosystem that can effectively meet the needs of the community. This new community effort, driven by the eight DOE labs, will take on the responsibility of guiding funding decisions for programming-systems development and maintenance with transparency and consistency across all decisions. Additionally, the team will offer common technical services to the programming systems community, irrespective of their funding situations, and facilitate community-wide incubation to proactively nurture the software ecosystem. By actively engaging with stakeholders and employing a collaborative approach, we can collectively shape the future of programming systems and ensure a robust and thriving HPC software landscape. On May 11–12, 2023, the S4PST team conducted its inaugural kick-off workshop at the Innovative Computing Laboratory (ICL) in the University of Tennessee, Knoxville, hosted by Hartwig Anzt. The workshop encompassed various sessions dedicated to presentations and discussions, with the aim of comprehending the team members’ perspectives on the vision of software sustainability. Additionally, the workshop aimed to identify the technical, economic, and social requirements for sustaining the programming-systems community in the field of HPC. This report provides a summary of the S4PST effort by highlighting five major thrust areas discussed during the workshop: (i) community, (ii) technical support, (iii) training and diversity, (iv) verification, validation and correctness, and (v) emerging technologies. It also encompasses an overview of the presentations and discussions held throughout the event, our views and potential synergies with other seedling efforts, along with the outcomes and key takeaways from our initial discussions.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Electric Vehicle Charging for Residential and Commercial Energy Codes: Technical Brief

Numerous studies show that sales of electric vehicles (EVs) have grown consistently over recent years in the U.S. The U.S. Energy Information Administration (EIA) estimated 3 million EVs were on the road in 2022, and the Edison Electric Institute (EEI) forecasts a total of 26.4 million EVs on the road by 2030. Based on this forecast, EEI projects the need for an additional 12.9 million EV charge ports by 2030. If EV charging infrastructure fails to keep pace with sales of EVs it could result in consumers stranded without options to power their vehicles. EVs are capable of providing substantial benefits to the consumers. EVs are less expensive to operate than conventional internal combustion engine vehicles, have lower maintenance costs, and have the convenience of fueling (charging) at home or work. Studies conducted in California show that costs associated with installing EV charging infrastructure can be substantially more expensive for retrofit scenarios compared to new construction, making inclusion of EV infrastructure in new construction codes a cost-effective policy option to increase infrastructure to meet growing demands. PNNL tracks adoption of mandatory EV provisions across the U.S. As of December 20, 2024, 12 states (California, Oregon, Washington, Colorado, New Mexico, Illinois, Maryland, Delaware, New Jersey, Rhode Island, Massachusetts and Vermont) and 53 local governments have added EV provisions to their building codes, local ordinances and zoning requirements. Originally published in 2022, this tech brief has been revised to align with recent model energy code committee discussions and published EV infrastructure code language. This technical brief summarizes market trends, costs and benefits, and provides sample code language for EV charging infrastructure for consideration to be included in model codes, such as the International Energy Conservation Code (IECC) and ANSI/ASHRAE/IES Standard 90.1, as well as directly by states and local governments in their building codes. The technical brief summarizes related efforts undertaken by states and local governments, and builds upon language considered during the 2021 and 2024 IECC development cycles.

2021 IECC↗
DOE OSTI2026

Compositional Reasoning for Hierarchical State Machines

Harel statecharts and its derivatives are popular graphical languages for specifying discrete control systems via hierarchical state machines. Separately, there has been a long line of work on specifying concurrent systems with process calculi which come equipped with an algebraic theory, the ability reason compositionally about various temporal properties, and strong type systems. While these two approaches to modeling systems are tantalizingly similar, the integrated reasoning principles that exist for process calculi have not been demonstrated in hierarchical state machines. A key issue is that operational theories for process calculi do not behave like control systems, and thus, there is virtually no tool support for modeling control systems with such languages. For a control system designer, bringing the integrated, more scalable reasoning from the process calculi to state-machine languages would enable the specification of more complex systems and a more modular systems development process. Our insight is that we can recover many important results from the process calculi in hierarchical state machines with local scope. We employ a structural operational semantics, which is ubiquitous in process and 𝜆-calculi but uncommon in hierarchical statemachine formalizations, to enable inductive reasoning about behavior. Taking inspiration from the structure of process calculi metatheories, we define a calculus of refinement and equivalence that we prove sound with respect to local notion of (bi)simulation. Furthermore, we prove that the calculus preserves the behavioral properties of reactivity, observational determinism, traces, and linear temporal properties. Our results are mechanized in the Rocq proof assistant.

97 MATHEMATICS AND COMPUTING↗