Researchers from the University of Colorado Boulder (CU-Boulder), Colorado State University (CSU) and the Rocky Mountain Advanced Computing Consortium will soon have access to a half-petaflop heterogeneous Dell PowerEdge C-series supercomputer. Funding for the $3.5 million project was secured through a $2.7 million grant from the National Science Foundation with the remaining amount being provided by the universities as “matching funds.”

CU-Boulder is ready for this refresh. The new 450-teraflops supercomputer, named Summit after the local topology, will replace Janus, another Dell cluster that at five-years-old is ready for retirement. The new Haswell- and GPU-based machine will be three times faster and use half as much energy as its Westmere-based predecessor.

Summit is being rolled out in two phases: the initial 450-teraflops Dell cluster, comprising high-end Xeon nodes, high-memory nodes and GPGPU nodes, is expected to arrive in late May; and a 20-node Intel Xeon Knights Landing partition is expected for late Q3. The main system will employ 22 Intel Omni-Path 48-port switches (8 core/spines) arranged into nonblocking islands of 32 compute nodes with 2:1 oversubscription between islands.

For storage, CU-Boulder and its partners will leverage IBM’s GPFS on DDN’s SFA14KE hyper-converged storage appliance. Packed with 350 4TB drives, there is a total of 1PB usable storage with room for another 1PB of growth capacity.

CU-Boulder opted for the SFA 14KE, DDN’s hyper-converged solution, because of its price/performance relative to the specs needed for the expected workloads.  They have a relatively modest number of GPFS client nodes, so didn’t require a ton of huge fleet of NSD server systems. As we reported in November, the SFA 14K series natively supports Intel’s Omni-Path Architecture (OPA).

While the KNL component is relatively small, Pete Ruprecht, CU-Boulder senior HPC analyst and co-PI of the project, said he is looking forward to using the hardware for proof-of-concept work in tandem with local partners, including the Intel Parallel Computing Center and NCAR, the atmospheric research facility that has massive weather and climate applications. “This will be a great opportunity to begin porting codes onto the KNL manycore architecture,” said Ruprecht.

Although the KNL partition is not expected until the fall, there is already talk about offering access to that portion of the cluster to XSEDE, so that those researchers can begin preparing their codes for the coming generation of larger KNL-systems, such as Cori (at NERSC) and Aurora (at ALCF).

Enthusiastic as to the potential of the socketed Knights Landing, Ruprecht, who led the technical aspect of the NSF grant and the RFP process by which they designed and procured the machine, characterized his experience with the original Phi coprocessor as “only modestly successful.”

“With GPGPU, we’ve had quite good results with people running applications that were designed for the GPU environment allowing them to just download and compile with CUDA. Not too many of our users develop their own GPU software,” he shared. “There’s not the same kind of support in terms of existing software base for Phi right now, so it’s been confined to our more sophisticated users to be able to even try using the Phi coprocessors. From an administrative point of view, having an operating system within an operating system is pretty hard to deal with. I think the advantages of having the Phi directly in the motherboard in the main processor socket make a lot of those concerns go away.”

“Our niche is to be an entry point into really large scale computing and if it’s too difficult for people they just won’t make that step,” added Ruprecht.

This concern over ease-of-use is shared by many in the research computing space. When San Diego Supercomputer Center (SDSC) got their Dell C-Series cluster “Comet” last year, the stakeholders referred to the project as “supercomputing for the 99 percent” highlighting the necessity of serving a large number of researchers who don’t have the resources to build their own cluster. TACC’s Wrangler machine was hatched with a similar mandate.

Like other HPC-capable institutions, CU-Boulder is moving to support more of a mixed workload model. Ruprecht reports that their existing cluster was designed for Linpack-like applications.

“Going forward, we need to expand the breadth of applications beyond that,” he said, “so we are doubling the amount of RAM per core, putting an SSD in each node to help support file-intensive applications that we see in the life sciences, and we are going to use GPFS for the scratch file system because we’ve had pretty clear indications that it will be better for file operation-intensive workloads, which we see with these data-type applications, in comparison with Lustre, which is a more traditional large-file parallel I/O.”

The system will serve more than 1,000 users at CU-Boulder in addition to the CSU and the Rocky Mountain Advanced Computing Consortium contingent. The CU user base is drawn from every college on the campus. The heaviest users are the usual suspects in engineering, astrophysics, material science, although demand is ramping up from fields such as economics, geography and life sciences with many genomics researchers anticipated from the CSU campus.

The system will follow a standard allocated, scheduled model with 10 percent of cycles going to RMACC, and of the remaining portion, two-thirds will go to CU-Boulder and the remaining one-third to CSU. “We will continue with our existing SLURM setup to be able to support wide jobs as well as single-core jobs,” said Ruprecht. “One thing that is different is that we will allow jobs to share nodes so we’ll have a more high-throughput workflow so many little jobs can run through a single core.”

“Our goal is to support both the larger and smaller workflows and we’ll have to do some reconfiguration of the scheduling system but it’s nothing that SLURM can’t handle,” he continued. “We have right now in our current system everything from multi-hundred node jobs down to single node jobs and they all just fit together.”

CU-Boulder is hoping to take delivery of Summit in late May, pending availability of the Omni-Path switches, which have seen a several month delay. Deployment will necessarily be accelerated and compressed on account of that pushing out of general availability. From delivery to acceptance to production, the CU staff is looking at a narrow window of about two months, yet there is a pressing need to rise to the occasion as their current cluster is going off support and will not be able to meet their needs for much longer.

In their favor, CU-Boulder is an early access customer for Omni-Path and Summit is expected to be one of the first large clusters to go into production with the interconnect.

Here’s a further breakdown of the architecture involved:

Phase 1:

• 370 PowerEdge C6320 server nodes with two-socket Haswell E5-2680v3 processors (12-core, 2.5Ghz)
• 5 PowerEdge R930 high-memory nodes with four-socket E7-4830v3 processors with 2 TB RAM
• 10 PowerEdge C4130 GPU nodes with 2x K80
• 22 OPA 48-port switches
• GPFS scratch storage – DDN SFA 14KE – 350 4TB drives

Phase 2:

• 20 Phi nodes with socketed Knights Landing, dual on-die Omni-Path per node