Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
DOE OSTI2024

Update on Parallel Process Execution in the Next Generation System Analysis Model (NGSAM)

As of the end of 2022, it is estimated that over 90,000 metric tons of heavy metal (MTHM) of spent nuclear fuel (SNF) were stored at various commercial nuclear power reactor sites (both operating and shutdown) across the United States [1]. The Office of Storage and Transportation within the U.S. Department of Energy’s Office of Nuclear Energy is planning for the transportation, storage, and eventual disposal of SNF and high-level radioactive waste (HLW). To aid in this effort and inform decision-makers about the backend of the spent fuel cycle, systems analysis tools capable of analyzing the various options with respect to SNF and HLW management are being used as well as continuously improved to meet the evolving needs of the program. System analysts typically use these tools to vary underlying assumptions (shipping rates, available facilities, start dates, interim storage capacity, etc.) and study the associated system implications such as timing for clearing sites of SNF, various cost elements, transportation infrastructure acquisition needs, etc.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2025

A Look Towards the Execution of the Low-Temperature TEX Experimental Campaign

To address the mounting need for below roomtemperature nuclear data validation, the Low-Temperature Thermal Epithermal eXperiments (LT-TEX) have been designed. Validation of low-temperature neutron cross sections is necessary to verify any operation at temperatures below room temperature which is typically observed in environments far from the equator. For example, a fissile material transportation truck may routinely observe ambient temperatures down to -40°C, which is the lower temperature bound of the normal conditions of transportation defined in the United States Title 10 Code of Federal Regulations §71.71c2. Additionally, sub-room temperature benchmarks can validate newly produced cross sections, that include novel thermal scattering laws, from North Carolina State University.

LT-TEX↗
DOE OSTI2024

NbZr_BCC_SolidSolution_128atoms_VASP6

We performed density functional theory (DFT) calculations for body-centered-cubic (BCC) structures with 128 lattices sites of solid solution binary alloys niobium-zirconium (Nb-Zr). The electronic structures of alloys have been calculated using Vienna Ab initio Simulation Package (VASP). Within this package the DFT approach is used to reduce many-body Schrodinger equation to set of single particle Kohn-Sham (KS) equations. The generalized electronic exchange-correlation functional is described by generalized gradient approximation with the Perdew-Burke-Ernzerhof parametrization. The electron-ion interactions is described by pseudopotentials developed within the plane-wave basis projector augmented-wave (PAW) approach \cite{PAW}. These pseudopotentials are available at the VASP portal (http://cms.mpi.univie.ac.at/vasp/). Our calculations have been run with the pseudopotentials treating s and p semi-core states as valence in case for the elements Nb and Zr. The electronic densities and potentials are expanded over plane-waves with energy cutoff of 350 eV. 2x2x2 k-mesh and normal precision were used. The alloys were modeled by supercell containing 128 randomly distributed atoms. At initial step the atoms occupy perfect bcc lattice cites. This initial structure was optimized until energy changes less than 1e-6 eV, while forces acting on atoms don't exceed 1e-2 eV/angstrom. The electron-ion interaction is described by PAW pseudopotentials. The calculations have been collected by sampling chemical compositions across the entire compositional range. The chemical compositions have been sampled by progressively changing the number of atoms per constituent by 4. For each chemical composition of binaries and ternaries, the first-principle calculations have been run for 100 randomized arrangements of the constituents on the BCC lattice sites. We collected data for a total of 3,100 randomized atomic structures over 31 chemical compositions. The calculations have been collected on NERSC-Perlmutter and OLCF-Summit using the VASP 6.3.2. The VASP calculations for every atomic structure have been performed in 2 main steps: 1. Starting from an ideal body-centered-cubic (BCC) structure, geometry optimization with low precision has been executed to perform a preliminary optimization of the atomic structure. The output for this calculations is available in the files 0.CONTCAR, 0.OUTCAR, rlx1.out. 2. Using the atomic structure resulting from the preliminary geometry optimization, a second geometry optimization has been performed using normal precision. The output for this calculations is available in the files CONTCAR, OUTCAR, rlx2.out, vaspout.h5, and vasprun.xml. Cases 1-10 have been run without generating the file 'vaspout.h5'. Every chemical composition sampled across the composition range in the dataset has its own directory. The convention used to name the directories for binary alloys is AXBY, where A and B refer to the constituents, whereas X and Y are positive integers that represent the number of atoms for each constituent and their values still sum up to 128. Each atomic structure associated with a specific chemical composition has its own sub-directory within the directory of the corresponding chemical composition. The sub-directories for each atomic structure for each chemical composition are named 'case-*', where * is a positive integer that spans all the values from 1 through 100, extremes included. The files contained in each sub-directory 'case-*' for each atomic structure are as follows: FILES contained in each subdirectory with name "case-N" where N ranges between 11 and 100, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. 0.POSCAR: input file that defines the atomic structure of a system 4. 0.CONTCAR: output file that provides the atomic positions and cell parameters after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 5. 0.OUTCAR: output file that contains detailed information about the progress of a calculation after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.out: file with diagnostic information about the execution of the first geometry optimization with precision variable set to PREC=Low in the INCAR file 7. POSCAR: input file that defines the atomic structure of a system after the first geometry optimization has been run at low precision. This represents the input for the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. CONTCAR: output file that provides the atomic positions and cell parameters after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 9. OUTCAR: output file that contains detailed information about the progress of a calculation after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.out: file with diagnostic information about the execution of the second geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system FILES contained in each subdirectory with name "case-N" where N ranges between 1 and 10, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. {ID}.POSCAR: input file that defines the atomic structure of a system at the beginning of ID execution of geometry optimization with PREC=LOW 4. {ID}.CONTCAR: output file that provides the atomic positions and cell parameters at the end of ID execution of geometry optimization with PREC=LOW in the INCAR file 5. {ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of geometry optimization that has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.{ID}.out: file with diagnostic information about the execution of the ID execution of the geometry optimization with precision variable set to PREC=Low in the INCAR file 7. N{ID}.POSCAR: input file that defines the atomic structure of a system after the geometry optimization run at low precision. This represents the input for the ID execution of the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. N{ID}.CONTCAR: output file that provides the atomic positions and cell parameters after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 9. N{ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.{ID}.out: file with diagnostic information about the ID execution of geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system This research is sponsored by the Artificial Intelligence Initiative as part of the Laboratory Directed Research and Development (LDRD) Program of Oak Ridge National Laboratory, managed by UT-Battelle, LLC, for the US Department of Energy under contract DE-AC05-00OR22725. This work used resources of the Oak Ridge Leadership Computing Facility, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725, under Directorate Discretionary awards MAT025 (Materials Science) and LRN026 (Machine Learning), and INCITE award MAT201. This work also used resources of the National Energy Research Scientific Computing Center, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231, under award ERCAP0025216. REFERENCES (1) Kresse, G. & Hafner, J. Ab initio molecular dynamics for liquid metals. Phys. review B 47, 558 (1993). (2) Kresse, G. & Hafner, J. Ab initio molecular-dynamics simulation of the liquid-metal–amorphous-semiconductor transition in germanium. Phys. Rev. B 49, 14251 (1994) (3) Kresse, G. & Furthmüller, J. Efficiency of ab-initio total energy calculations for metals and semiconductors using a plane-wave basis set. Comput. materials science 6, 15–50 (1996) (4) Kresse, G. & Furthmüller, J. Efficient iterative schemes for ab initio total-energy calculations using a plane-wave basis set. Phys. review B 54, 11169 (1996) (5) Kresse, G. & Joubert, D. From ultrasoft pseudopotentials to the projector augmented-wave method. Phys. review b 59, 1758 (1999)

36 MATERIALS SCIENCE↗
DOE OSTI2024

TaZr_BCC_SolidSolution_128atoms_VASP6

We performed density functional theory (DFT) calculations for body-centered-cubic (BCC) structures with 128 lattices sites of solid solution binary alloys tantalum-zirconium (Ta-Zr). The electronic structures of alloys have been calculated using Vienna Ab initio Simulation Package (VASP). Within this package the DFT approach is used to reduce many-body Schrodinger equation to set of single particle Kohn-Sham (KS) equations. The generalized electronic exchange-correlation functional is described by generalized gradient approximation with the Perdew-Burke-Ernzerhof parametrization. The electron-ion interactions is described by pseudopotentials developed within the plane-wave basis projector augmented-wave (PAW) approach \cite{PAW}. These pseudopotentials are available at the VASP portal (http://cms.mpi.univie.ac.at/vasp/). Our calculations have been run with the pseudopotentials treating s and p semi-core states as valence in case for the elements Ta and Zr. The electronic densities and potentials are expanded over plane-waves with energy cutoff of 350 eV. 2x2x2 k-mesh and normal precision were used. The alloys were modeled by supercell containing 128 randomly distributed atoms. At initial step the atoms occupy perfect bcc lattice cites. This initial structure was optimized until energy changes less than 1e-6 eV, while forces acting on atoms don't exceed 1e-2 eV/angstrom. The electron-ion interaction is described by PAW pseudopotentials. The calculations have been collected by sampling chemical compositions across the entire compositional range. The chemical compositions have been sampled by progressively changing the number of atoms per constituent by 4. For each chemical composition of binaries and ternaries, the first-principle calculations have been run for 100 randomized arrangements of the constituents on the BCC lattice sites. We collected data for a total of 3,100 randomized atomic structures over 31 chemical compositions. The calculations have been collected on NERSC-Perlmutter and OLCF-Summit using the VASP 6.3.2. The VASP calculations for every atomic structure have been performed in 2 main steps: 1. Starting from an ideal body-centered-cubic (BCC) structure, geometry optimization with low precision has been executed to perform a preliminary optimization of the atomic structure. The output for this calculations is available in the files 0.CONTCAR, 0.OUTCAR, rlx1.out. 2. Using the atomic structure resulting from the preliminary geometry optimization, a second geometry optimization has been performed using normal precision. The output for this calculations is available in the files CONTCAR, OUTCAR, rlx2.out, vaspout.h5, and vasprun.xml. Cases 1-10 have been run without generating the file 'vaspout.h5'. Every chemical composition sampled across the composition range in the dataset has its own directory. The convention used to name the directories for binary alloys is AXBY, where A and B refer to the constituents, whereas X and Y are positive integers that represent the number of atoms for each constituent and their values still sum up to 128. Each atomic structure associated with a specific chemical composition has its own sub-directory within the directory of the corresponding chemical composition. The sub-directories for each atomic structure for each chemical composition are named 'case-*', where * is a positive integer that spans all the values from 1 through 100, extremes included. The files contained in each sub-directory 'case-*' for each atomic structure are as follows: FILES contained in each subdirectory with name "case-N" where N ranges between 11 and 80, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. 0.POSCAR: input file that defines the atomic structure of a system 4. 0.CONTCAR: output file that provides the atomic positions and cell parameters after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 5. 0.OUTCAR: output file that contains detailed information about the progress of a calculation after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.out: file with diagnostic information about the execution of the first geometry optimization with precision variable set to PREC=Low in the INCAR file 7. POSCAR: input file that defines the atomic structure of a system after the first geometry optimization has been run at low precision. This represents the input for the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. CONTCAR: output file that provides the atomic positions and cell parameters after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 9. OUTCAR: output file that contains detailed information about the progress of a calculation after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.out: file with diagnostic information about the execution of the second geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system FILES contained in each subdirectory with name "case-N" where N ranges between 1 and 10 and between 81 and 100, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. {ID}.POSCAR: input file that defines the atomic structure of a system at the beginning of ID execution of geometry optimization with PREC=LOW 4. {ID}.CONTCAR: output file that provides the atomic positions and cell parameters at the end of ID execution of geometry optimization with PREC=LOW in the INCAR file 5. {ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of geometry optimization that has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.{ID}.out: file with diagnostic information about the execution of the ID execution of the geometry optimization with precision variable set to PREC=Low in the INCAR file 7. N{ID}.POSCAR: input file that defines the atomic structure of a system after the geometry optimization run at low precision. This represents the input for the ID execution of the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. N{ID}.CONTCAR: output file that provides the atomic positions and cell parameters after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 9. N{ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.{ID}.out: file with diagnostic information about the ID execution of geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system This research is sponsored by the Artificial Intelligence Initiative as part of the Laboratory Directed Research and Development (LDRD) Program of Oak Ridge National Laboratory, managed by UT-Battelle, LLC, for the US Department of Energy under contract DE-AC05-00OR22725. This work used resources of the Oak Ridge Leadership Computing Facility, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725, under Directorate Discretionary awards MAT025 (Materials Science) and LRN026 (Machine Learning), and INCITE award MAT201. This work also used resources of the National Energy Research Scientific Computing Center, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231, under award ERCAP0025216. REFERENCES (1) Kresse, G. & Hafner, J. Ab initio molecular dynamics for liquid metals. Phys. review B 47, 558 (1993). (2) Kresse, G. & Hafner, J. Ab initio molecular-dynamics simulation of the liquid-metal–amorphous-semiconductor transition in germanium. Phys. Rev. B 49, 14251 (1994) (3) Kresse, G. & Furthmüller, J. Efficiency of ab-initio total energy calculations for metals and semiconductors using a plane-wave basis set. Comput. materials science 6, 15–50 (1996) (4) Kresse, G. & Furthmüller, J. Efficient iterative schemes for ab initio total-energy calculations using a plane-wave basis set. Phys. review B 54, 11169 (1996) (5) Kresse, G. & Joubert, D. From ultrasoft pseudopotentials to the projector augmented-wave method. Phys. review b 59, 1758 (1999)

36 MATERIALS SCIENCE↗
DOE OSTI2022

Performance for GPU exceptions

Techniques for improving performance of accelerated processing devices (“APDs”) when exceptions occur are provided. In APDs, the very large number of parallel processing execution units, and the complexity of the hardware used to execute a large number of work-items in parallel, means that APDs typically stall when an exception occurs (unlike in central processing units (“CPUs”), which are able to execute speculatively and out-of-order). However, the techniques provided herein allow at least some execution to occur past exceptions. Execution past an exception generating instruction occurs by executing instructions that would not lead to a corruption while skipping those that would lead to a corruption. After the exception has been satisfied, execution occurs in a replay mode in which the potentially exception-generating instruction is executed and in which instructions that did not execute in the exception-wait mode are executed. A mask and counter are used to control execution in replay mode.

Gutierrez, Anthony T.↗
DOE OSTI2024

Mneme

A simple tool allowing recording the execution of a GPU (CUDA) kernel and replaying that kernel as an independent executable. The tool operates in 3 phases. During compile time the user needs to apply a provided LLVM pass to instrument the code. The pass detects all device global variables and device functions and stores this information with the respective LLVM-IR in the global device memory. The compilation generates a record-able executable. The second phase involves running the application executable with a desired input and using LD_PRELOAD to enable recording. When recording before invoking a device kernel the pre-loaded library stores device memory in persistent storage and associates the memory with the device kernel and an LLVM IR file. At the end of the recorded execution the pre-load library generates a database in the form of a JSON file containing information regarding the LLVM-IR files and the snapshots of device memory. During the third and last phase the user can replay the execution of an kernel as a separate independent executable. Besides executing it the user can modify the LLVM IR file and auto-tune parameters such as kernel launch-bounds or kernel runtime execution parameters (e.g. Kernel Block and Grid Dimensions). Is

Parasyris, Konstantinos↗
DOE OSTI2022

Running Ensemble Workflows at Extreme Scale: Lessons Learned and Path Forward

The ever-increasing volumes of scientific data combined with sophisticated techniques for extracting information from them have led to the increasing popularity of ensemble workflows which are a collection of runs of individual workflows. A traditional approach followed by scientists to run ensembles is to rely on simple scripts to execute different runs and manage resources. This approach is not scalable and is error-prone, thereby motivating the development of workflow management systems that specialize in executing ensembles on HPC clusters. However, when the size of both the ensemble and the target system reach extreme scales, existing workflow management systems face new challenges that hamper their efficient execution. In this paper, we describe our experience scaling an ensemble workflow from the computational biology domain from the early design stages to the execution at extreme scale on Summit, a leadership class supercomputer at the Oak Ridge National Laboratory. We discuss challenges that arise when scaling ensembles to several million runs on thousands of HPC nodes. We identify challenges with composition of the ensemble itself, its execution at large scale, post-processing of the generated data, and scalability of the file system. Based on the experience acquired, we develop a generic vision of the capabilities and abstractions to add to existing workflow management systems to enable the execution of ensemble workflows at extreme scales. We believe that the understanding of these fundamental challenges will help application teams along with workflow system developers with designing the next generation of infrastructure for composing and executing extreme-scale ensemble workflows.

Mehta, Kshitij↗
DOE OSTI2023

diffReplication - An Energy-Aware Fault Tolerance Model for Silent Error Detection and Mitigation in Heterogeneous Extreme-scale Computing Environment

At extreme scale, the frequency of silent errors – a class of errors that remain undetected by low-level error detection mechanisms – increases significantly with the computational complexity of the application and the scale of the computing infrastructure. As hardware and software advances are made to usher in the next scientific era of computing, developing new approaches to mitigate the impact of silent errors remains a challenging problem. In this work, we propose an energy-aware fault-tolerance model, referred to diffReplication to overcome silent errors. In the proposed model, the main process is associated with one replica that executes at the same rate as the main process, and one diffReplica that is executed at a fraction of the main process' execution rate. If the main and its replica reach consensus at the end of a computation phase, the state of the diffReplica is updated and computation is resumed. If the synchronization attempt results in a disagreement, however, the diffReplica increases its execution speed to complete the computation and quickly reach the synchronization barrier. Assuming a single error over any given synchronization interval, a majority voting is used to reach consensus and tolerate silent errors. To further enhance its performance, diffReplication is augmented with speculative execution, whereby the main or its fast replica is selected to continue execution without waiting for the diffReplica. The selection process is based on the previous behaviour of the main and its replica. A performance analysis study is carried out to assess the performance of diffReplication, in terms of the energy saving and time-to-completion reduction achieved by the diffReplication scheme. The experiment shows that speculative execution reduces the time to completion with additional energy, and dynamic decision-making balances the energy consumption and time to completion.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

CLC: A cross-level program characterization method

Characterization of program execution plays a key role in performance improvement. There are numerous transformations applied to each step that a program takes on its lowering from source code to a compiler intermediate representation to machine language to microarchitecture-specific execution. The unpredictable benefit of each transformation step could lead a notionally superior algorithm to exhibit inferior performance once actually run, and it can be hard to discern which step in the transformation path contradicted the code developer’s assumptions. Conventional approaches to program-execution characterization consider the behavior after only a single one of those steps, which limits the information that can be provided to the user. To help address the issue of myopic views of program execution, this paper presents a novel cross-level characterization approach for understanding the behavior of program execution at different levels in the process of writing, compiling, and running a program. We show that this approach provides a richer view of the sources of performance gains and losses and helps identify program execution in a more accurate manner.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

IRIS-MEMFLOW: Data Flow-Enabled Portable Memory Orchestration in IRIS Runtime for Diverse Heterogeneity

Task-based programming models and execution paradigms provide a means to decompose a computation by expressing it as a graph in which each node represents a specific computation operating on memory objects and the edges define the dependencies in the execution flow. In this execution model, independent nodes in the graph can be executed concurrently in different computing devices, making it suitable for heterogeneous systems in which computing devices with different architectures coexist. However, careful memory orchestration across heterogeneous devices is needed because copies of the same memory object may reside in multiple devices during execution. Manually ensuring such an orchestration is quite challenging. Not only must an application developer guard against race conditions, but they must also optimize data movement between the host and devices because unnecessary data movement significantly impacts performance. To mitigate these challenges, we enhance the IRIS heterogeneous runtime and introduce IRIS-MEMFLOW–a data flow–enabled portable memory abstraction for seamlessly orchestrating memory in diverse heterogeneous computing environments. By using data-flow analysis, IRIS-MEMFLOW guards against race conditions while multiple heterogeneous devices access memory objects. IRIS-MEMFLOW also optimizes data movement between the host and devices without manual intervention. As a result, IRIS provides improved programming productivity, performance, and portability for multidevice heterogeneous executions in high-performance computing and cloud systems that run diverse architectures from different vendors. The efficacy of IRIS-MEMFLOW is evaluated through experiments that show its capability in terms of programming productivity, multidevice heterogeneity, portability, and low overhead versus the state of the art.

Monil, M. A. H. [ORNL] (ORCID:0000000334194037)↗
DOE OSTI2020

DayCent data and results for "Robust paths to net greenhouse gas mitigation and negative emissions via advanced biofuels"

DayCent data and results for:J. L. Field, T. L. Richard, E. A. Smithwick, H. Cai, M. S. Laser, D. S. LeBauer, S. P. Long, K. Paustian, Z. Qin, J. J. Sheehan, P. Smith, M. Q. Wang, L. R. Lynd, Robust paths to net greenhouse gas mitigation and negative emissions via advanced biofuels. Proceedings of the National Academy of Sciences (2020). https://doi.org/10.1073/pnas.1920877117 This zip file contains a UNIX-format DayCent model executable, input files, automation code, and associated directory structure necessary to re-produce the DayCent analysis underlying the manuscript. The main script 'autodaycent.py' (written for Python 2.7) opens an interactive command line routine that facilitates:* Calibrating the DayCent pine growth model.* Initializing DayCent for a set of case studies sites.* Executing an ensemble of model runs representing case study site reforestation, grassland restoration, or conversion to switchgrass cultivation. * Results analysis & generation of manuscript Fig. 3. Note that the interactive analysis code requires that all input files to be contained in the directory structure as uploaded, without modification. Executable versions of the DayCent model (https://www.nrel.colostate.edu/projects/daycent/) compatible with other operating systems are available upon request.Please send questions/comments to John.L.Field@gmail.com

Agro-ecosystem function and prediction↗
DOE OSTI2022

Adaptive elasticity policies for staging-based in situ visualization

In situ processing aims to alleviate the growing gap between computation and I/O capabilities by performing data processing close to the data source. In situ processing is widely used to process data generated by multiple data sources, including observation data from edge devices or scientific observational facilities and the simulation data generated by scientific computation on a high-performance computing (HPC) platform. For a scientific workflow that is run on an HPC platform and composed of a simulation program and an in situ data analytics or visualization (abbreviated as ana/vis) task, there is an implicit assumption that the computing resources assigned to the workflow keep static during the workflow execution. However, with the converging trend between the HPC and cloud computing platform, running the in situ ana/vis task in an elastic way is promising to decrease its overhead and improve its resource utilization rate. Resource elasticity represents the ability to change resource configurations such as the number of computing nodes/processes during workflow execution. An elastic job may dynamically adjust resource configurations; it may use a few resources at the beginning and more resources toward the end of the job when interesting data appear. However, it is hard to predict a priori how many computing nodes/processes need to be added/removed during the workflow execution to adapt to changing workflow needs. How to efficiently guide elasticity operations, such as growing or shrinking the number of processes used for in situ analysis during workflow execution, is an open-ended research question. In this article, we present adaptive elasticity policies that adopt workflow runtime information collected during workflow execution to predict how to trigger the addition/removal of processes in order to minimize in situ processing overhead. Taking in situ visualization tasks as an example, we integrate the presented elasticity policies into a staging-based elastic workflow and evaluate its efficiency in multiple elasticity scenarios. Compared with the situation without elasticity or with a static elasticity policy that uses a fixed number of processes for each rescaling operation, the adaptive elasticity policy can save overhead in finding a proper resource configuration and improve resource utilization efficiency. Furthermore, one experiment illustrates that the adaptive elasticity policy saves 41% of core-hours compared with the situation without the resource elasticity.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

funcX: Federated Function as a Service for Science

Here, funcX is a distributed function as a service (FaaS) platform that enables flexible, scalable, and high performance remote function execution. Unlike centralized FaaS systems, funcX decouples the cloud-hosted management functionality from the edge-hosted execution functionality. funcX's endpoint software can be deployed, by users or administrators, on arbitrary laptops, clouds, clusters, and supercomputers, in effect turning them into function serving systems. funcX's cloud-hosted service provides a single location for registering, sharing, and managing both functions and endpoints. It allows for transparent, secure, and reliable function execution across the federated ecosystem of endpoints-enabling users to route functions to endpoints based on specific needs. funcX uses containers (e.g., Docker, Singularity, and Shifter) to provide common execution environments across endpoints. funcX implements various container management strategies to execute functions with high performance and efficiency on diverse funcX endpoints. funcX also integrates with an in-memory data store and Globus for managing data that may span endpoints. We motivate the need for funcX, present our prototype design and implementation, and demonstrate, via experiments on two supercomputers, that funcX can scale to more than 130000 concurrent workers. We show that funcX's container warming-aware routing algorithm can reduce the completion time for 3,000 functions by up to 61% compared to a randomized algorithm and the in-memory data store can speed up data transfers by up to 3x compared to a shared file system.

97 MATHEMATICS AND COMPUTING↗