The National Energy Research Scientific Computing Center (NERSC) at Berkeley Lab has recently begun installing Edison, the Cray supercomputer that will exceed two peak petaflops when its fully deployed in a couple of months. But the center is already prepping for its next-generation system, which is expected to be an order of magnitude more powerful. That supercomputer may be the center’s last big deployment prior to the exascale era.

That system, under the code name NERSC-8, is in its earliest stages. The RFI (Request For Information) for the system just went out in mid-December, with the RFP (Request For Proposal) is slated for the second quarter of 2013. If all goes as planned, NERSC-8 be awarded to some lucky vendor in the fourth quarter of the year, with system delivery expected to start before the end of 2015. System cost is expected to be in the range of $50 to $100 million

Since the last two big NERSC systems, Hopper (NERSC-6), an XE6 and now Edison (NERSC-7), an XC30, were both supplied by Cray, they would appear to be the odds on favorite to supply NERSC-8 as well. That’s not likely to prevent vendors like IBM and SGI from bidding on the system, especially since the RFP will actually specify two systems: the NERSC-8 one and “Trinity”, an NNSA supercomputer for Los Alamos National Laboratory (LANL) and Sandia National Laboratories (SNL). That system is also slated for deployment in 2015.

No doubt the DOE is looking to save some money by combining the procurement between the labs. It’s a little bit of an odd arrangement though, inasmuch as NERSC is under the DOE’s Office of Science, while Los Alamos and Sandia are part of the agency’s National Nuclear Security Administration division. But their supercomputer refresh cycles are apparently close enough together to make a dual-purpose RFP a reasonable bet.

Also, the computing requirement of these labs seem to align closely enough to use the same platform. Like NERSC’s Hopper, the top supercomputer at LANL/SNL, dubbed Cielo, is also a Cray XE6 — yet another reason to believe that Cray has the inside track on this procurement. Unlike the open science Hopper however, Cielo supports classified codes for the US nuclear stockpile stewardship program.

Since these supercomputers will be installed in the 2015/2016 timeframe and are intended to run for four to six years, they represent the pre-cursor to the exascale machines planned for the end of the decade. And although NERSC-8 and Trinity are likely to be in the sub-100-petaflop range, they are the architectural stepping stones to those exaflop or near-exaflop machines five years further down the road.

The draft of the technical requirements for the NERSC-8/Trinity platform doesn’t specify peak (or Linpack) FLOPS. Performance requirements are described in terms of mini-application benchmarks provided by NERSC and, for Trinity, an ASC (Advanced Simulation and Computing) code suite.

The NERSC mini-apps are a set of codes that support a variety of science applications that aligns with the DOE’s mission, especially physics codes of various stripes, and climate modeling and analysis. With the mini-apps as the benchmark, the goal for NERSC-8 is to deliver a system that performs 10 to 30 times faster than Hopper. For Trinity, performance is expected to be 20 to 60 times faster.

An order of magnitude performance increase in three years is certainly doable in the fast-paced world of supercomputing. The biggest challenge, especially for NERSC, will be to provide a system that can bring along the 600 or so science applications that are currently running on the Berkeley hardware. Spread across around 5,000 users (the largest user base of any DOE center), these applications represent a considerable manpower investment in software.

This explains NERSC’s conservative approach of supercomputing architectures to date. Hopper, and now Edison, are CPU-only machines, so moving the code base between them will be relatively easy. According the Kathy Yelick, Associate Laboratory Director of Computing Sciences at NERSC, attending to the needs of hundreds of applications and thousands of users requires a different approach than centers with a more specialized user base. “There are things you can do if you’ve got 6 applications that you can not do if you’ve got 600,” she told HPCwire.

The problem is that the shortest and cheapest path to double-digit petaflops today involves add-on accelerators like GPUs and now Intel’s Xeon Phi coprocessors. But because these devices are remote from the CPU (connected via PCIe, without direct access to main memory), a significant amount of software work can be required to get codes to take advantage of the extra FLOPS. That’s why, with 600 applications in tow, NERSC has shied away from such systems.

Although NERSC is one of the largest labs for the DOE, its top system, Hopper, sits at number 19 on the TOP500, although when Edison come online it may briefly penetrate the top 10. Prestige aside, that’s resulted in a capacity gap for NERSC’s numerous users. According to Yelick, even with Edison their demand will be an order of magnitude greater than what they can provide. Ideally, she says, they would like to have a 10-petaflop system up and running today.

They could have built such a machine, but it would have required either discrete accelerators (a programming model they would rather skip) or something more proprietary like the Blue Gene platform (an architecture they have avoided). The hope is that by 2015, they will be able to get something on the exascale roadmap, but with a programming model that is reasonably friendly to CPU-based codes.

That most likely means integrated heterogeneous processors like NVIDIA’s “Project Denver” ARM-GPUs, AMD’s x86-GPU APUs, or whatever Intel brings to the table with integrated Xeon Phi coprocessing. Although more complex than a pure CPU solution from a software point of view, the integrated designs at least avoid the messy PCIe communication and the completely separate memory space of the accelerator device.

According to Yelick, they’re trying to take the middle path here. Her thinking is that if you switch programming models too early, the developers can get caught in an architectural cul-de-sac that will be replaced in a few years with something more general-purpose. But if you switch too late, your center and applications can become irrelevant. “It’s a complicated time to make these decisions,” says Yelick.