Reuben D. Budiardja

The nature of dark energy (DE) remains elusive, even though it constitutes the dominant energy-density component of the Universe and drives the late-time acceleration of cosmic expansion. By combining measurements of the expansion history from baryon acoustic oscillations, supernova surveys, and cosmic microwave background data, the Dark Energy Spectroscopic Instrument (DESI) Collaboration has inferred that the DE equation of state may evolve over time. The profound implications of a time-variable, “dynamical” DE (DDE) that departs from a cosmological constant motivate the need for independent observational tests. In this work, we use a focused set of cosmological hydrodynamical simulations to investigate how DDE affects the properties of the Lyman- α “forest” of absorption features produced by neutral hydrogen in the cosmic web. We find that DDE models consistent with the DESI constraints induce a spectral tilt in the forest transmitted flux power spectrum, imprinting a scale- and redshift-dependent signature relative to standard Λ CDM cosmologies. These models also yield higher intergalactic medium temperatures and reduced Lyman- α opacity compared to Λ CDM . We discuss the observational implications of these trends as potential avenues for independent confirmation of DDE.

The General Astrophysical Simulation System is a code being developed initially and primarily, though not exclusively, for the simulation of core-collapse supernovae on the world’s leading capability supercomputers. This paper—the second in a series—documents capabilities for Newtonian self-gravitating fluid dynamics, including tabulated microphysical equations of state treating nuclei and nuclear matter (“baryonic matter”). Computation of the gravitational potential of a spheroid, and simulation of the gravitational collapse of dust and of an ideal fluid, provide tests of self-gravitation against known solutions. In multidimensional computations of the adiabatic collapse, bounce, and explosion of spherically symmetric presupernova progenitors—which we propose become a standard benchmark for code comparisons—we find that the explosions are prompt and remain spherically symmetric (as expected), with an average shock expansion speed and total kinetic energy that are inversely correlated with the progenitor mass at the onset of collapse and the compactness parameter.

Fortran applications constitute a significant portion of large-scale HPC workloads deployed at many large computational centers. The continued viability of such applications depends on the availability of a robust development environment that can target the increasingly heterogeneous node architectures of modern systems. The amdflang Fortran compiler is AMD’s next-generation compiler that targets x86 CPUs with OpenMP offloading capabilities to AMD GPUs. Based on the upstream LLVM flang compiler, amdflang was officially released as part of ROCm 7 and is currently being deployed as part of the standard AMD programming environment on HPE Cray systems. Given the importance of this transition, this work explores the current capabilities and performance of amdflang, using a wide spectrum of applications from different domains that are representative of the Fortran HPC workloads commonly deployed at computational centers. We assess the capability of amdflang as it relates to base Fortran language support, as well as OpenMP on the CPU and GPU offloading to AMD devices. We discuss the changes and effort needed to port existing codes to use amdflang, and an initial performance evaluation of the ported codes. For a few cases, we also explore the compilation times. We take a breadth-first approach to exploration to provide a guide to the compiler developers, computational centers, and end users as they consider migrating their codes to this new compiler.

Summary: The Oak Ridge Leadership Computing Facility (OLCF) has a long history of supporting and promoting GPU‐accelerated computing starting with the deployment of the Titan supercomputer in 2021 and continuing with the Summit supercomputer which has a theoretical peak performance of approximately 200 petaflops. Because the majority of Summit's computational power comes from its 27,972 GPUs, users must port their applications to one of the supported programming models in order to make efficient use of the system. To prepare the transition to Frontier, the OLCF's exascale supercomputer, users will need to adapt to an entirely new ecosystem which will include new hardware and software technologies. First, users will need to familiarize themselves with the AMD Radeon GPU architecture. Furthermore, users who have been previously relying on CUDA will need to transition to the Heterogeneous‐Computing Interface for Portability (HIP) or one of the other supported programming models (e.g., OpenMP, OpenACC). In this work, we describe our initial experiences and lessons learned in porting three applications or proxy apps currently running on Summit to the HPE/Cray ecosystem to leverage the compute power from AMD GPUs: minisweep, GenASiS, and Sparkler. Each one is representative of current production workloads utilized at the OLCF, different programming languages, and different programming models.

As the US Department of Energy (DOE) computing facilities began deploying petascale systems in 2008, DOE was already setting its sights on exascale. In that year, DARPA published a report on the feasibility of reaching exascale. The report authors identified several key challenges in the pursuit of exascale including power, memory, concurrency, and resiliency. That report informed the DOE's computing strategy for reaching exascale. With the deployment of Oak Ridge National Laboratory's Frontier supercomputer, we have officially entered the exascale era. In this paper, we discuss Frontier's architecture, how it addresses those challenges, and describe some early application results from Oak Ridge Leadership Computing Facility's Center of Excellence and the Exascale Computing Project.

The advent of Exascale computing invites an assessment of existing best practices for developing application readiness on the world's largest supercomputers. This work details observations from the last four years in preparing scientific applications to run on the Oak Ridge Leadership Computing Facility's (OLCF) Frontier system. This paper addresses a range of topics in software including programmability, tuning, and portability considerations that are key to moving applications from existing systems to future installations. A set of representative workloads provides case studies for general system and software testing. We evaluate the use of early access systems for development across several generations of hardware. Finally, we discuss how best practices were identified and disseminated to the community through a wide range of activities including user-guides and trainings. We conclude with recommendations for ensuring application readiness on future leadership computing systems.

Summary: In this article, we summarize the deployment of the Air Force Weather (AFW) HPC11 system at Oak Ridge National Laboratory (ORNL) including the process followed to successfully complete acceptance testing of the system. HPC11 is the first HPE/Cray EX 3000 system that has been successfully released to its user community in a federal facility. HPC11 consists of two identical 800‐node supercomputers, Fawbush and Miller, with access to two independent and identical lustre parallel file systems. HPC11 is equipped with Slingshot 10 interconnect technology and relies on the HPE Performance Cluster Manager software for system configuration. ORNL has a clearly defined acceptance testing process used to ensure that every new system deployed can provide the necessary capabilities to support user workloads. We worked closely with HPE and AFW to develop a set of tests that used the United Kingdom's Meteorological Office's Unified Model and 4‐dimensional variational data assimilation. We also included benchmarks and applications from the Oak Ridge Leadership Computing Facility portfolio to fully exercise the HPE/Cray programming environment and evaluate the functionality and performance of the system. Acceptance testing of HPC11 required parallel execution of each element on Fawbush and Miller. In addition, careful coordination was needed to ensure successful acceptance of the newly deployed lustre file systems alongside the compute resources. In this work, we present test results from specific system components and provide an overview of the issues identified, challenges encountered, and the lessons learned along the way.