Search NASA⌕ Search

SEARCH · Search NASA

Results for “execution”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
DOE OSTI2018

Clustering execution in a processing system to increase power savings

Embodiments relate to clustering execution in a processing system. An aspect includes accessing a control flow graph that defines a data dependency and an execution sequence of a plurality of tasks of an application that executes on a plurality of system components. The execution sequence of the tasks in the control flow graph is modified as a clustered control flow graph that clusters active and idle phases of a system component while maintaining the data dependency. The clustered control flow graph is sent to an operating system, where the operating system utilizes the clustered control flow graph for scheduling the tasks.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Characterizing the Performance of Executing Many-tasks on Summit

Many scientific workloads are comprised of many tasks, where each task is an independent simulation or analysis of data. The execution of millions of tasks on heterogeneous HPC platforms requires scalable dynamic resource management and multi-level scheduling. RADICAL-Pilot (RP) -- an implementation of the Pilot abstraction, addresses these challenges and serves as an effective runtime system to execute workloads comprised of many tasks. In this paper, we characterize the performance of executing many tasks using RP when interfaced with JSM and PRRTE on Summit: RP is responsible for resource management and task scheduling on acquired resource; JSM or PRRTE enact the placement of launching of scheduled tasks. Our experiments provide lower bounds on the performance of RP when integrated with JSM and PRRTE. Specifically, for workloads comprised of homogeneous single-core, 15 minutes-long tasks we find that: PRRTE scales better than JSM for > O(1000) tasks; PRRTE overheads are negligible; and PRRTE supports optimizations that lower the impact of overheads and enable resource utilization of 63% when executing O(16K), 1-core tasks over 404 compute nodes.

Matteo, Turilli↗
DOE OSTI2016

Technology Maturation in Support of DOE 413.3B Project Execution - 16436

The DOE Order 413.3B 'Program and Project Management for the Acquisition of Capital Assets' provides program and project management direction for the acquisition of capital assets with the goal of delivering projects within the original performance baseline (PB), cost and schedule, and fully capable of meeting mission performance, safeguards and security, and environmental, safety, and health requirements. Execution of complex DOE 413.3B projects depends, in part, upon the successful integration of a technology maturation program. The Low Activity Waste Pre-Treatment System (LAWPS) is executing a detailed technology maturation program under the Technology Readiness Level/Technology Maturation Plan (TRL/TMP) guidance of DOE Order 413.3B. The interaction of the technology maturation process and the project execution including technical, programmatic, and contractual execution, has been a critical component for project success. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2018

A case study evaluating the portability of an executable computable phenotype algorithm across multiple institutions and electronic health record environments

Abstract Electronic health record (EHR) algorithms for defining patient cohorts are commonly shared as free-text descriptions that require human intervention both to interpret and implement. We developed the Phenotype Execution and Modeling Architecture (PhEMA, http://projectphema.org) to author and execute standardized computable phenotype algorithms. With PhEMA, we converted an algorithm for benign prostatic hyperplasia, developed for the electronic Medical Records and Genomics network (eMERGE), into a standards-based computable format. Eight sites (7 within eMERGE) received the computable algorithm, and 6 successfully executed it against local data warehouses and/or i2b2 instances. Blinded random chart review of cases selected by the computable algorithm shows PPV ≥90%, and 3 out of 5 sites had >90% overlap of selected cases when comparing the computable algorithm to their original eMERGE implementation. This case study demonstrates potential use of PhEMA computable representations to automate phenotyping across different EHR systems, but also highlights some ongoing challenges.

Pacheco, Jennifer A.↗
DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗
DOE OSTI2022

Design and execution of a verification, validation, and uncertainty quantification plan for a numerical model of left ventricular flow after LVAD implantation

Left ventricular assist devices (LVADs) are implantable pumps that act as a life support therapy for patients with severe heart failure. Despite improving the survival rate, LVAD therapy can carry major complications. Particularly, the flow distortion introduced by the LVAD in the left ventricle (LV) may induce thrombus formation. While previous works have used numerical models to study the impact of multiple variables in the intra-LV stagnation regions, a comprehensive validation analysis has never been executed. The main goal of this work is to present a model of the LV-LVAD system and to design and follow a verification, validation and uncertainty quantification (VVUQ) plan based on the ASME V&V40 and V&V20 standards to ensure credible predictions. The experiment used to validate the simulation is the SDSU cardiac simulator, a bench mock-up of the cardiovascular system that allows mimicking multiple operation conditions for the heart-LVAD system. The numerical model is based on Alya, the BSC’s in-house platform for numerical modelling. Alya solves the Navier-Stokes equation with an Arbitrary Lagrangian-Eulerian (ALE) formulation in a deformable ventricle and includes pressure-driven valves, a 0D Windkessel model for the arterial output and a LVAD boundary condition modeled through a dynamic pressure-flow performance curve. The designed VVUQ plan involves: (a) a risk analysis and the associated credibility goals; (b) a verification stage to ensure correctness in the numerical solution procedure; (c) a sensitivity analysis to quantify the impact of the inputs on the four quantities of interest (QoIs) (average aortic root flow $Q^{avg}_{Ao}$, maximum aortic root flow $Q^{max}_{Ao}$, average LVAD flow $Q^{avg}_{VAD}$, and maximum LVAD flow $Q^{max}_{VAD}$; (d) an uncertainty quantification using six validation experiments that include extreme operating conditions. Numerical code verification tests ensured correctness of the solution procedure and numerical calculation verification showed a grid convergence index (GCI)95% <3.3%. The total Sobol indices obtained during the sensitivity analysis demonstrated that the ejection fraction, the heart rate, and the pump performance curve coefficients are the most impactful inputs for the analysed QoIs. The Minkowski norm is used as validation metric for the uncertainty quantification. It shows that the midpoint cases have more accurate results when compared to the extreme cases. The total computational cost of the simulations was above 100 [core-years] executed in around three weeks time span in Marenostrum IV supercomputer. This work details a novel numerical model for the LV-LVAD system, that is supported by the design and execution of a VVUQ plan created following recognised international standards. We present a methodology demonstrating that stringent VVUQ according to ASME standards is feasible but computationally expensive.

59 BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2016

A Fault-oblivious Extreme-scale Execution Environment

Exascale computing systems will provide a thousand-fold increase in parallelism and a proportional increase in failure rate relative to today's machines. Systems software for exascale machines must provide the infrastructure to support existing applications while simultaneously enabling efficient execution of new programming models that naturally express dynamic, adaptive, irregular computation; coupled simulations; and massive data analysis in a highly unreliable hardware environment with billions of threads of execution. We propose a new approach to the data and work distribution model provided by system software based on the unifying formalism of an abstract file system. The proposed hierarchical data model provides simple, familiar visibility and access to data structures through the file system hierarchy, while providing fault tolerance through selective redundancy. The hierarchical task model features work queues whose form and organization are represented as file system objects. Data and work are both first class entities. By exposing the relationships between data and work to the runtime system, information is available to optimize execution time and provide fault tolerance. The data distribution scheme provides replication (where desirable and possible) for fault tolerance and efficiency, and it is hierarchical to make it possible to take advantage of locality. The user, tools, and applications, including legacy applications, can interface with the data, work queues, and one another through the abstract file model. This runtime environment will provide multiple interfaces to support traditional Message Passing Interface applications, languages developed under DARPA's High Productivity Computing Systems program, as well as other, experimental programming models. We will validate our runtime system with pilot codes on existing platforms and will use simulation to validate for exascale-class platforms. In this final report, we summarize research results from the work done at the Ohio State University towards the larger goals of the project listed above.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Predicting Execution Times for Disk-based and In-Situ Parallel Data Analytics (Final Technical Report)

In recent years, there has been a significant amount of interests in in-situ analytics on simulation programs. For a variety of reasons, it is desirable to be able to predict the execution time of an analytics program. At the same time, frameworks such as MapReduce have become popular for scientific data analytics. This paper focuses on developing performance models for predicting execution time of parallel data analytics, with a special emphasis on in-situ analytics. We take two distinct approach towards performance prediction. We first expand SKOPE (a SKeleton framewOrk for Performance Exploration) with performance models for disk data read, cache performance, and page fault penalty. Second, an analytical performance model is also developed. We have evaluated our performance prediction framework as well as the analytical model on three hardware setups with well-known data mining algorithms implemented in three programming paradigms, MapReduce, MATE (a MapReduce-like parallel system with an alternate API for multi-core environments) and Smart (a MapReduce-like framework for in-situ analytics). Results show that our performance prediction framework along with the incorporated performance models are capable of accurately predicting execution times for parallel scientific analytics on different hardware setups.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

2020 Exascale Computing Project Annual Meeting (Executive Summary Report)

The Exascale Computing Project (ECP) delivers specific applications, software products, and outcomes on DOE computing facilities. Integration across these elements for specific hardware technologies for exascale system instantiations is fundamental to ECP success. The outcome of the ECP is the delivery of a capable exascale computing ecosystem to provide breakthrough solutions addressing our most critical challenges in scientific discovery, energy assurance, economic competitiveness, and national security. This outcome is not a matter of ensuring more powerful computing systems. The ECP is designed to create more valuable and rapid insights from a wide variety of applications (“capable”), which requires a much higher level of inherent efficacy in all methods, software tools, and ECP-enabled computing technologies to be acquired by DOE laboratories (“ecosystem”). The ECP annual meeting provides a unique opportunity for the core technical expertise in the United States focused on achieving this next plateau of computational science and computing performance to engage in direct discussions on project execution. Face-to-face gatherings in technical communities like this are common and needed for the exchange of scientific ideas and technical performance. The ECP annual meeting stands apart from other technical conferences and meetings in the computing community as it is uniquely and solely focused on the execution of the ECP and the integration of technical activities leading to the creation of the exascale computing ecosystem for the future. The direct interaction of key critical technical staff, who are leaders in their respective fields, and the resulting give-and-take between software, applications, and hardware and the technical co-design therein, is unique and essential to the effective execution of the ECP. The first annual meeting was held in Knoxville, Tennessee, January 31 – February 2, 2017 and brought together, for the first time, a diverse collection of researchers from 16 DOE national laboratories as well as university computer and computational science researchers to discuss shared problems and joint solutions for the development of a capable exascale computing ecosystem. These interactions resulted in focused technical plans and an energized community centered on advances for ECP. The second annual meeting was held in Knoxville, Tennessee, February 5–9, 2018. It included 643 individual thought leaders and performers in application development, software research and deployment, and hardware research and integrators, all of whom are part of the multifaceted, billion dollar HPC community. This meeting provided a platform to discuss and disseminate numerous examples where researchers with common goals and synergistic solutions came together for the first time to deliver tangible results. Additionally, at the 2018 meeting, ECP researchers had the opportunity to digest all US HPC vendor R&D product roadmaps pointing to exascale – not only to learn how their research can play a role, but, more importantly, to influence those roadmaps to ensure successful delivery on DOE applications that will contribute to (if not solve) problems of national interest in national security, science, energy, and health, as well as growing security threats. The third annual meeting was held in Houston, Texas, January 14–17, 2019. With a 19% increase in the number of registrations (768 people), and the change in location, the third annual meeting was considered the most impactful of the three at the time. The new website provided a better platform for the dissemination of the content, the new venue as a meeting hotel instead of a conference center facilitated interactions and discussions after event hours, and the addition of an award-winning mobile event conference app (Whova) transformed dramatically the attendee experience at the event. This fourth annual meeting was held in Houston, Texas, February 3-7, 2020. This meeting had an increase in the number of attendees for a total of 824 people registered (782 attendees) and included numerous enhancements based on feedback and lessons learned from previous meetings, some of which are listed here: Improved quality of the sessions, their material and the whole program.; Had more industry participation and addition of external collaborators from overseas.; Published the full agenda earlier to better accommodate attendance and travel plans based on schedule.; Centralized all sessions in one venue.; Provided additional hotels and room blocks for the attendees.; Improved communication with the audience (links, material, directions, notifications, etc.) to go paperless.; Enhanced side meeting scheduling, management and user experience.; Made available additional space and tables for impromptu meetings and side discussions.; Improved IT and A/V solutions for speakers. In addition, our final survey captured the following points as opportunities for improvement in future meetings: consider a different meeting location that is more pedestrian friendly, reduce talks during working meals to allow more collaboration and informal time, adapt the agenda to acknowledge attendees from different timezones, consider recording some of the tutorials and/or sessions to share broadly with the HPC community, have a larger poster room, provide additional power strips, and improve the WiFi.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

G3P3 Phase 3 Project Execution Plan. Issue 1

The National Solar Thermal Test Facility (NSTTF) at Sandia National Laboratories New Mexico (SNL/NM) developed this Project Execution Plan (PEP) to document its process for executing, monitoring, controlling and closing-out Phase 3 of the Gen 3 Particle Pilot Plant G3P3. This plan serves as a resource for stakeholders who wish to be knowledgeable of project objectives and how they will be accomplished. The plan is intended to be used by the development partners, principal investigator, and the federal project director. Project objectives are derived from the mission needs statement, and an integrated project team assists in development of the PEP. This plan is a living document and will be updated throughout the project to describe current and future processes and procedures. The scope of the PEP covers: Cost, schedule, and scope Project reporting Staffing plan Quality assurance plan Environment, safety, security, and health This document is a tailored approach for the Facilities Management and Operations Center (FMOC) to meet the project management principles of DOE Order 413.3B, Program and Project Management for the Acquisition of Capital Assets , and DOE G 413.3-15, DOE Guide for Project Execution Plans. This document will elaborate on content as knowledge of the project is gained or refined.

14 SOLAR ENERGY↗
DOE OSTI2022

Production Agency Quality Assurance Management Execution Strategy [Thesis]

There are multiple federal directives that Los Alamos National Laboratory (LANL) must follow for the proper implementation of quality assurance, strategic planning, and execution of manufacturing and surveillance operations. Recent assessments identified that manufacturing in all processing areas is dynamic due to influencing scope changes, design modifications, funding adjustments, and staff attrition. In response, this project was started to develop a comprehensive PAQ execution strategy to support the success of LANL’s manufacturing mission. This project’s method for developing an updated architecture was to create an integrated, flexible, reliable, and agile strategic process. The execution plan has five deliverables: 1) an integrated schedule view of PAQ work scope, 2) a resource management plan that aligns with the required scope, 3) a metrics monitoring dashboard, 4) a project management plan for sustaining NAP 401.1A implementation, and 5) a risk management plan. The research design is a mixed-method approach focused on data collection for each deliverable. The methodology entails qualitative and quantitative research, metrics monitoring, data analysis, and the creation of a dashboard. The qualitative methods used include literature reviews and interviews. The quantitative methods include resource, financial, schedule and survey data analysis. Preliminary and final results were peer reviewed by subject matter experts both within the ALDWP organization and deployed support.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗
DOE OSTI2022

Enabling Parallel Execution of System-level Simulations in SAM

This report summarizes the recent code updates related to “element ghosting” in SAM to enable the parallel execution of system-level simulations using multiple processors/cores. Unlike typical MOOSE-based applications, for system-level simulations, SAM mostly deals with a collection of discrete small pieces of meshes, and the connection of physics on these meshes are realized by using “connector” types of components/code structures, such as conjugate heat transfer and flow junctions. The required code implementation is to correctly mark the necessary ghost elements for each type of such components/code structures; thus, the lower-level libraries can correctly perform the necessary data transfer between processors (CPUs) when executed in parallel mode. After the code updates, SAM can now run system-level simulations in the parallel mode. The parallel execution capability was then tested with an ABTR input model with 23k DOFs. Significant speedup was demonstrated when the optimal number of CPUs were used in parallel mode. Future systematic studies on parallelization performance using additional test cases covering different physics/scenarios will be needed to provide additional insights into the scalability of SAM parallelization.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗
DOE OSTI2016

Using redundant transactions to verify the correctness of program code execution

In the described embodiments, a processor core (e.g., a GPU core) receives a section of program code to be executed in a transaction from another entity in a computing device. The processor core sends the section of program code to one or more compute units in the processor core to be executed in a first transaction and concurrently executed in a second transaction, thereby creating a “redundant transaction pair.” When the first transaction and the second transaction are completed, the processor core compares a read-set of the first transaction to a read-set of the second transaction and compares a write-set of the first transaction to a write-set of the second transaction. When the read-sets and the write-sets match and no transactional error condition has occurred, the processor core allows results from the first transaction to be committed to an architectural state of the computing device.

Gurumurthi, Sudhanva↗
DOE OSTI2020

Heterogeneous graphics processing unit for scheduling thread groups for execution on variable width SIMD units

A compute unit configured to execute multiple threads in parallel is presented. The compute unit includes one or more single instruction multiple data (SIMD) units and a fetch and decode logic. The SIMD units have differing numbers of arithmetic logic units (ALUs), such that each SIMD unit can execute a different number of threads. The fetch and decode logic is in communication with each of the SIMD units, and is configured to assign the threads to the SIMD units for execution based on such differing numbers of ALUs.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Further Development of an Execution Strategy Analysis (ESA) Capability and Tool for the Management of Spent Nuclear Fuel (SNF) - 17146

An Execution Strategy Analysis (ESA) capability and tool are being developed to evaluate alternative execution strategies for the potential future deployment of a consolidated Interim Storage Facility as part of an integrated waste management system. Application of the ESA approach not only leverages but also goes beyond traditional project analysis tools. The ESA tool allows for ongoing performance assessment of the evolving project execution plans that take into account significant assumptions, risks, and uncertainties throughout the project lifecycle. Development and application of the ESA capability and tool continued in 2016, primarily focusing on enhancing its flexibility to model a range of scenarios regarding how an integrated system for managing spent nuclear fuel and high-level radioactive waste could be deployed. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2016

Development of an Execution Strategy Analysis (ESA) Capability and Tool for the Management of Spent Nuclear Fuel (SNF) - 16575

An Execution Strategy Analysis (ESA) capability and tool are being developed to evaluate alternative execution strategies for future deployment of a consolidated Interim Storage Facility using a consent-based siting process per the Administration's Strategy for the Management and Disposal of Used Nuclear Fuel and High-Level Radioactive Waste (Strategy). Application of an ESA approach not only leverages but also goes beyond traditional project analysis tools. The ESA tool allows for ongoing performance assessment of the evolving project execution plan that takes into account significant assumptions, risks, and uncertainties throughout the project lifecycle. The ESA process and tool will be used to support the development of plans, budgets, and alternative execution/implementation strategies for meeting the goals of the Strategy. This paper describes the development of the ESA capability and tool and identifies the value of applying such a capability in implementing a long-term strategy for managing spent nuclear fuel and high-level radioactive waste. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2024

Techniques for recovering from errors when executing software applications on parallel processors

In various embodiments, a software program uses hardware features of a parallel processor to checkpoint a context associated with an execution of a software application on the parallel processor. The software program uses a preemption feature of the parallel processor to cause the parallel processor to stop executing instructions in accordance with the context. The software program then causes the parallel processor to collect state data associated with the context. After generating a checkpoint based on the state data, the software program causes the parallel processor to resume executing instructions in accordance with the context.

Hukerikar, Saurabh↗