Since 1950 the Atomic Weapons Establishment (AWE) has been central to the defense of the United Kingdom — providing and maintaining the warheads for the country's nuclear deterrent. Uniquely among the nuclear powers, AWE covers the whole lifecycle of nuclear warheads in a single organization. This includes initial concept, research and design, through component manufacture and assembly, to in-service support and finally, decommissioning and disposal.
The overall mission of AWE is to provide the UK national capability for a nuclear deterrent on behalf of the Ministry of Defence (MoD). The Government's Strategic Defence Review in 1998 emphasized the continuing importance of AWE to the nation. While highlighting the need for progress on arms control, it confirmed that the United Kingdom continues to require a credible and effective minimum nuclear deterrent. It outlined AWE's tasks for the future:
- To maintain the warheads for the Trident nuclear deterrent, safely and reliably in service.
- To maintain a capability to design a new weapon, should it ever be required.
- To complete the dismantling and disposal of redundant warheads replaced by Trident.
- To develop the skills, technologies and techniques that could underpin future arms limitation treaties.
Trident, a submarine-launched ballistic nuclear weapons system, is currently the United Kingdom's sole nuclear deterrent in both the strategic and sub-strategic roles.
AWE's prime task over the next 20-30 years, therefore, will be to support the Trident system in service by maintaining its warhead stockpile. Following ratification by the United Kingdom of the Comprehensive Nuclear Test Ban Treaty, maintenance of the Trident warheads and the capability to produce a successor will have to be achieved without recourse to nuclear testing.
This will pose a whole new range of scientific and engineering challenges. To meet these challenges, AWE has been working to develop new methods of verifying the safety and reliability of the United Kingdom's nuclear deterrent through a science based program.
The Science and Technology section of the AWE web site provides an introduction to some of the research and development work. In many instances this work stretches the limits of what is achievable and this ensures, there are always scientific and technical challenges to be overcome.
In other words, the tasks for fulfilling AWE's mission require capability supercomputing at its core. This has been true in the past, remains true now and in the future. Capability computing has always been essential, the raison d'être of this field. To put this in context in the late 1990s, President Clinton and the U.S. congress have asked the Federal Labs to come up with a proposal for using computer simulations capable of developing and maintaining nuclear weapons without the need to do physical testing. The program would also have to encompass maintenance and validation of current stockpiles.
It turns out that the DoE spends about a third on integrated computer systems, a third on defense applications, (designs of weapons) and a fifth on design of materials. For these activities they calculated that one needs 100 teraflop to simulate 3-D Transport or 3-D material models. The U.S. program envisaged having systems of this power by year 2005. The initial 20 teraflop — later upgraded to 50 teraflop — Red Storm system (the brainchild of Bill Camp and precursor of the Cray XT3) built by Cray at Sandia, and the IBM Power5 and Blue Gene/L systems, under the umbrella of the ASCI Purple initiative, built at Lawrence Livermore and Los Alamos, presented a clear path to get there. The productivity program with its sights on one petaflop by the year 2009/10 is the next goal.
By year 2000, the Europeans, arrived at the same conclusion as their colleagues in the USA and followed a parallel path. The French ordered a 5 teraflop system from Compaq (now HP). This was updated by a larger Bull system in 2005 as part of their “Tera” program. As all these institutions are in the same business, AWE took a similar path, and updated their previous MPP system, purchasing a 2.88 teraflop IBM Power3 system, in 2001. This gave AWE a 30-fold increase in compute power.
AWE envisaged it would take a decade to put the planned infrastructure in place including software tools. The HPC infrastructure provides the data backbone and simulation capability for their task. For example, they want to experiment with hydrodynamic (CFD) codes, simulating turbulent mixing using various techniques and one billion cells. The original estimate was that their work would require about 25 teraflop by year 2005 and hundreds of teraflop by year 2010. The recent procurement of a 40 teraflop Cray XT3 is the latest step, in a long journey of using supercomputers, as part of AWE's science infrastructure. The Cray XT3 is expected to provide at least a twenty-fold increase; if Cray's tuning work on the benchmarks can be applied to the production codes, this may well turn out to be nearer to thirty-fold.
Choosing the best available computer system is a must, if one is to have a chance, addressing the demanding scientific challenges. The AWE HPC benchmark , constructed for this purpose is based on workload profile characterization and projections of future user requirements. As stated above, AWE is currently running an IBM Power3 system (Blue Oak) with 1,856 processors (16-way Nighthawk nodes), rated at 2.88 teraflop peak performance. Their requirement was to buy a new system delivering 25 times greater sustained performance, as measured by their workload benchmark, and not as peak performance.
The AWE benchmark contains a combination of codes from the whole AWE user community, physicists, engineers and material scientists, weighted to reflect their workload. It measures both capacity (throughput) and capability turnaround. In my view this is one of the best ways to evaluate complex computer systems and establish whether they satisfy the computing needs of your users. Relying on a few kernels will not do. The approach is similar to the one used in the benchmark I developed in the early 1980s for the UK academic research supercomputer center. This too was used for procurement purposes and was based on a rigorous workload profile characterization .
The physicists contributed plasma physics and hydrodynamic codes plus visualization. The engineers contributed codes for solving explicit and implicit (100 MDOFs) models, using as much as 30 million elements. In materials, two unclassified molecular dynamics codes were used, DL-Poly from Daresbury Laboratory and WARP from Sandia. These unclassified benchmark codes represent, as far as is possible, a much larger suite of classified production codes that form the real AWE workload.
HPC systems are very complex and the pitfalls of benchmarking are heightened when dealing with systems of differing speeds. As Ron Bell  gave as an example, consider two systems, A and B, with the processors in system A twice as fast as those in B system and B having twice the number of processors than A. One can fall into the trap of the usual scenario, where capacity can be achieved by partitioning system B into two, running both partitions in parallel, giving the illusion that both systems have the same throughput.
The erroneous conclusion is that system A gives better turnaround times, but has the same throughput. The correct conclusion is system A has better turnaround times and higher throughput than system B because system B must scale further in order to achieve the required job turnaround. Note that system B may be unable to give the required turnaround for some capability jobs. In conclusion, don't compare N-way on A with N-way on B. Adjust N so that turnaround is about the same on A and B.
The capacity throughput benchmark consisted of the following codes with appropriate (weights) in parenthesis. Physics codes: Hydra (1), Corvus (1), PETSc (2), Chimaera (8), CAM (4). Materials codes: Warp (2), Dl-poly (2); and engineering codes: MPP-Dyna (5), Salinas (4). The total value is 29. This was chosen to reflect the BlueOak configuration (64×29 = 1,856 processors).
There were some extra tests to evaluate: Visualization, I/O, TYPHON/IO, Fortran90, the PALLAS communications test and an MPI overlap test.
The design of the throughput benchmark consisted of the reference job-stream run on Blue Oak (BO), where the 1856 CPUs were divided into 29 Groups of 64. In each group repeating 64-way jobs were run on a vendor platform. They then applied “4x BO capability constraint,” requiring turnaround to be <= 0.25 x BO turnaround; and if necessary, parallelism was adjusted to achieve this. The job-streams were run in similar fashion to the Blue Oak system. Thus, turnaround times and hence speedups, were measured. For this benchmark, the mean throughput increase was calculated as the weighted harmonic mean of speedups, scaled by numbers of processing elements (PEs).
A full throughput benchmark will be run across the whole of the installed system, as an acceptance test. The winning vendor had to contract in advance to the throughput figure, relative to Blue Oak. During benchmarking vendors were required to run “mini-throughput benchmark” on 128 PEs. Optionally, they could run any benchmark subset they liked, in order to arrive at the contracted figure for the full benchmark.
When direct capability measures were sought, e.g. comparing a 1024-way Chimaera job on each different target platform, the AWE benchmarking team hit a problem. There were limited benchmark systems, from most or all vendors and very limited benchmark systems, from some vendors. As a partial solution, AWE insisted that vendors estimated turnaround for key capability jobs, furnishing direct evaluation of interconnects (latency/bandwidth and so on). The AWE benchmark team then drew scalability graphs and extrapolated. In addition AWE asked for contracted scalability figures, on industry-standard benchmarks.
As for source code tuning, AWE asked for “as-is” results plus optionally tuned results. What they received from different vendors was a mix of: No tuning “as-is” and tuned results on benchmark system, but only tuned results projected on larger target system. Throughput commitments were based on tuned code, to be done sometime in the future!
This was rejected as an unsound evaluation methodology by AWE. The main comparisons were done on “as-is” code (i.e. like for like). Tuned projections were back-projected by AWE to “as-is,” but gave credit to vendors who provided tuned results, for fact that the tuning of codes demonstrated, that the vendor had relevant application skills.
In running their benchmark AWE found that: “There is a problem with measuring throughput of capability jobs. At modest levels of parallelism, scalability is largely unaffected by interconnect. Scalability is intrinsic to application and the ratio between systems is constant with PE count. At higher PE counts, where performance 'turns over,' relative throughput varies wildly and becomes meaningless.”
Also, it was very difficult to perform the capability test. There were very few benchmark data available, up to “turn over” point. To measure the job turnaround at a point just before “turn over,” the best the system can do, irrespective of number of PEs, became difficult. Generally, a system, scoring better on this measure, would need more PEs to achieve it – so throughput was probably lower. For this reason, capacity (throughput) and capability figures were presented as separate measures, with a warning about the large uncertainties on the capability figures.
AWE staff wanted to be able to say things like: “System A has 10% higher throughput than system B for modestly parallel work, but system B has better scalability – so capability jobs show 20% higher throughput on B. If we assume half of the system will be dedicated to capability jobs, then System B gives more overall throughput.” This was not possible from the benchmark results. They concluded: “The benchmark was too complex for vendors. Throughput test is not really useful as a benchmark. Multiple jobs don't usually interfere much. There was inadequate I/O subsystem on benchmark systems, but this should be excellent as acceptance test. Capability was very difficult to quantify.”
In short, AWE decided that for large-scale applications, (30 million elements) time to completion (turnaround) must be heavily weighted in the selection criteria of a system. Capability systems can always deliver capacity where capability is often beyond capacity systems, but capability is difficult to measure accurately, as vendors do not usually have systems of that size for benchmarking.
Of course other factors often dominate the selection of large-scale systems. For example, one trade-off is price/performance; another is a hidden benefit from having the same system as sites one collaborates with. In other words, it depends on how one constructs the Total Cost of Ownership (TCO) integral. For my money, I would also include ease of use and Mean Time Between Failures (MTBF), especially with systems with tens or hundred thousand processors.
Six vendors offered proposals, Bull, Cray, Dell, IBM, Linux Networx & SGI. The AWE benchmark was run on the vendors proposed systems. The results showed two systems performed significantly better than the other four and these were short-listed. In addition to the AWE benchmark results, an estimate of TCO was calculated and risk factors looked at, as part of the decision process.
After all the factors were evaluated, the Cray offer of a 40 teraflop Cray XT3 system, was accepted as the best option. Measures from the AWE benchmark show that it will deliver almost 30 times the sustained performance of their current Blue Oak system.
In Cray's words: “The Cray XT3 system, Cray's third-generation massively parallel processing product, was designed from the ground up — a development from the Sandia project — to deliver the cost advantages of microprocessors and to operate efficiently and reliably at large scale. The system uses Cray purpose-built interconnect technology, as well as the AMD Opteron processor's direct connect architecture and Hyper-Transport technology, to connect processors and memory at high speed.”
This will be Cray's largest system in Europe and the first Cray XT3 contract worldwide with dual-core processors. The contract, including services, is valued at more than 20 million GBP and calls for Cray to ship the new supercomputer to AWE in the second quarter of 2006, and for the system to enter full production in the second half of 2006.
As Dr. Brian Bowsher, AWE's Director for Research and Applied Science said: “This investment will enable us to make advances on a range of scientific fronts — including weapon physics, materials science and engineering — which will underpin our continued ability to underwrite the safety and effectiveness of the Trident warhead in the Comprehensive Test Ban era.”
 R. Bell, AWE: Presentation at Machine Evaluation Workshop, 6 December 2005 titled: “The AWE HPC Benchmark.”
 C. Lazou “Benchmarking Performance over a Life-Cycle,” (pp55-67), in Evaluating Supercomputers, Edited by Aad van der Steen, published: Chapman and Hall, 1990.
Copyright (c) Christopher Lazou, HiPerCom Consultants, Ltd., UK. February 2006. Brands and names are the property of their respective owners.