We present results from our cosmological N-body simulation which consisted of 2048x2048x2048 particles and ran distributed across three supercomputers throughout Europe. The run, which was performed as the concluding phase of the Gravitational Billion Body Problem DEISA project, integrated a 30 Mpc box of dark matter using an optimized Tree Particle Mesh N-body integrator. We ran the simulation up to the present day (z=0), and obtained an efficiency of about 0.93 over 2048 cores compared to a single supercomputer run. In addition, we share our experiences on using multiple supercomputers for high performance computing and provide several recommendations for future projects.
There are a several other projects which have run high performance computing applications across multiple supercomputers. These include simulations of a galaxy collision @cite_20 , a materials science problem @cite_1 as well as an analysis application for arthropod evolution @cite_22 . A larger number of groups performed distributed computing across sites of PCs rather than supercomputers (e.g., @cite_4 @cite_7 @cite_15 ). Several software tools have been developed to facilitate high performance computing across sites of PCs (e.g., @cite_3 @cite_5 @cite_18 @cite_9 @cite_12 ) and within volatile computing environments @cite_17 . The recently launched MAPPER EU-FP7 project @cite_8 seeks to run multiscale applications across a distributed supercomputing environment, where individual subcodes periodically exchange information and (in some cases) run concurrently on different supercomputing architectures.
@cite_18 @cite_4 @cite_22 @cite_7 @cite_8 @cite_9 @cite_1 @cite_3 @cite_5 @cite_15 @cite_12 @cite_20 @cite_17
1985967703 1987512728 2148988158 2765129600
As a part of the Supercomputing '95 High Performance Computing Challenge, the authors have used the re sources of three of the National Science Foundation NSF supercomputing centers as a single, distributed, heteroge neous metacomputer to carry out the largest simulation of colliding galaxies yet attempted. The metacomputer con sisted of the following machines: TMC CM-5, Cray C90 T3D, IBM SP-2, and SGI Power Challenge. This paper describes the scalable parallel numerical algorithms used to carry out the hybrid N-body gas dynamical simulation, as well as the inter-MPP communication system the authors developed to connect them. The system, called sclib, is simple yet flexible, and consists of a network of communicating objects, or agents. Each communication agent is a process that resides on the front-end processor of a parallel supercomputer and brokers the interactions between the various components of the distributed com putation. The design is independent of host architecture and execution model yet takes advantage of scheduling resources local to the compute servers. As such, it serves as a useful prototype for future research in distributed, heterogeneous, high-performance computing. In this paper, we report on the experimental results of running a large, tightly coupled, distributed multiscale computation over a hybrid High Performance Computing (HPC) infrastructures. We connected EC2 based cloud clusters located in USA to university clusters located in Switzerland. We ran a concurrent multiscale MPI based application on this infrastructure and measured the overhead induced by extending our HPC clusters with EC2 resources. Our results indicate that accommodating some parts of the multiscale computation on cloud resources can lead to low performance without a proper adjustment of CPUs power and workload. However, by enforcing a load-balancing strategy one can benefit from the extra Cloud resources. We connect an EC2-cloud cluster to a university cluster located in Switzerland.We run a distributed multiscale CFD computation over this extended infrastructure.We evaluate and compare the distributed execution to a local execution.We describe our experience of running parallel CFD application on hybrid platforms.Multiscale computation on cloud requires an adjustment of CPUs power and workload. High performance computing has undergone a radical transformation during the past decade. Though monolithic supercomputers continue to be built with significantly increased computing power, geographically distributed computing resources are now routinely linked using high-speed networks to address a broad range of computationally complex problems. These confederated resources are referred to collectively as a computational Grid. Many geographical problems exhibit characteristics that make them candidates for this new model of computing. As an illustration, we describe a spatial statistics problem and demonstrate how it can be addressed using Grid computing strategies. A key element of this application is the development of middleware that handles domain decomposition and coordinates computational functions. We also discuss the development of Grid portals that are designed to help researchers and decision makers access and use geographic information analysis tools. This paper reports our observations from a top-tier supercomputer Titan and its Lustre parallel file stores under production load. In summary, we find that supercomputer file systems are highly variable across the machine at fine time scales. This variability has two major implications. First, stragglers lessen the benefit of coupled I O parallelism (striping). Peak median output bandwidths are obtained with parallel writes to many independent files, with no striping or write-sharing of files across clients (compute nodes). I O parallelism is most effective when the application—or its I O middleware system—distributes the I O load so that each client writes separate files on multiple targets, and each target stores files for multiple clients, in a balanced way. Second, our results suggest that the potential benefit of dynamic adaptation is limited. In particular, it is not fruitful to attempt to identify “good spots” in the machine or in the file system: component performance is driven by transient load conditions, and past performance is not a useful predictor of future performance. For example, we do not observe regular diurnal load patterns.