When one thinks of major manufacturing companies, including Boeing, Proctor and Gamble, John Deere, Caterpillar, Dow, GE and others, from a systems and software perspective, there is little doubt that the competitive edge lies in high performance computing. But for many of these companies, it’s not simply a matter of plugging engineering codes into high core-count, accelerated supercomputers to magically realize better results.
Finite element analysis, computational fluid dynamics and homegrown codes at the largest manufacturing companies have their own unique system needs—but tend to run inside daily workflows where experimentation with new architectures and approaches are pushed down the chain due to competing demands from across the organization. According to Merle Giles, who leads the private sector program and economic development initiatives at the National Center for Supercomputing Applications (NCSA), most of the common engineering applications tend to hum nicely at around 1000 cores. They don’t’ tend to require acceleration but do need major memory to handle decomposition and other critical elements.
So while Giles and his team at NCSA have access to Blue Waters, core counts and scientific application performance are secondary. For the users he’s targeting–those with commercial and mission-critical home-cooked engineering codes–such a massive resource might not have the specific appeal of another far smaller (but far more targeted) option: A pared down, but finely tuned cluster specifically built to address the experimental needs of the “power users” at leading manufacturing companies. Giles’ team has such a hardware resource…and they’re also able to collect the varied expertise across both NCSA and the University of Illinois to bring world class support to bear as well.
To put this difference between system needs in context, consider that memory-tied engineering codes on Blue Waters with its 64 GB of RAM on a single node might do reasonably well, but take a much smaller cluster, in this case, the iForge system that Giles and his team operate in the Digital Manufacturing Lab at NCSA, and these codes can sing through decomposition on 256 GB instead.
The iForge cluster has been benchmarked for common CFD and FEA applications against the mighty Blue Waters for confirmation—which has further bolstered Giles and teams’ mission to keep pushing the edges of what’s useful for the manufacturing companies they’re serving with their private cluster that’s reserved for the experimental “power users” from the big companies listed above. “We want to be complementary to Blue Waters, not redundant,” Giles explained.
If you haven’t heard of iForge, it’s because although it’s been around for the last three years (and churning a profit for Giles to pump directly into the program with more–and more interesting—cores) it’s not part of the more publicized publicly funded efforts one might expect out of a university or national lab/supercomputer center setting. You also haven’t seen it from any LINPACK or other publicized benchmarking runs. Giles says this is because it’s optimized for these users to test and deploy their mission-critical code using some of the newest hardware. For instance, iForge was one of the early recipients of Sandy Bridge when it was available and already sports one of the just-released new Intel Xeon E7 4890 15-core-based nodes–for now.
The goal is simple: let the power users from the high end of digital manufacturing hop on board to take new architectures for a spin, optimize their codes and evaluate them against their existing infrastructure to better understand upgrade/rip and replace ROIs without burdening their own in-house clusters. These users can take valuable lessons about how their code scales and operates, make choices and in turn, Giles and team can turn over valuable feedback to system vendors. Also, they can use these cores for production runs, which the team charges for and that keep the center profitable and support the endless cycle of refreshes and system expansion. And speaking of the system…
We were able to receive a number of deep details about the evolution of iForge from Evan Burness, the Program Manager for the private sector and economic development program at NCSA. Evan narrated the journey of cutting-edge hardware for us, including details about their Intel (and for a while, Opteron) environment, which was slung together by Dell with DDN storage and QDR Infinibad. As Burness described:
“We started iForge in Q3 2011 with “Intel’s Westmere” (116 EP nodes, 3 EX nodes) and AMD’s “Magny Cours” (2 nodes) architectures. That system had 1,584 cores total. In 2012 we upgraded to Intel’s “Sandy Bridge” (128 EP nodes) architecture when it was released to market (Q3 2012), and at the same time increased our AMD node count from 2 to 18, and upgraded the processors to “Interlagos” (Just like the CPU’s on Blue Waters). Through the upgrade, we increased the node count from 121 to 146, and the core count to 2,624.” As a side point, he’s counting 4 Opteron processors in a node as accounting for 32 cores, rather than the 64 AMD might cite since the the “16 core” Opteron chips based on Interlagos and Abu Dhabi only have 8 floating point units, which is what’s really important for their work.
These constant upgrades were part of the master plan for the project—and will continue to be so since the goal is to continue offering new architectures for manufacturing users to test and explore.
Burness says they intended to upgrade again in mid-2013 (this time through Intel’s early access program), but vendor delays pushed that back to January of 2014. At that time, they upgraded to Intel’s “Ivy Bridge” (144 EP nodes) line, and AMD’s “Abu Dhabi’ Line. The Ivy Bridge nodes indeed feature the 10-core variants (Xeon E5 2680 v2), with 96 of the nodes featuring 64 GB of RAM (for CFD) workloads and 48 featuring 256 GB of RAM (for finite element analysis) workloads.
“We also added one (1) Ivy Bridge-EX system directly from Intel, who saw iForge as a particularly good platform at which to throw this new technology given how industry brings real-world development and production problems to this system.” Burness explained. These only were released from Intel in December and January. iForge is now one of the precious few that we can get any details on that features 4 x 15-core Xeon E7 4890 CPUs for a total of 60 cores and 120 threads. Burness and team have also augmented the server with an extra 1.5 terabytes of memory and multiple Infiniband connections.
In addition, he said, they upgraded their network insofar as PCIe gen 3.0 on the Ivy Bridge nodes increased the usable bandwidth of our QDR Infiniband fabric from 25.6 Gb/sec to 32.0 Gb/sec, “all while maintaining the lowest possible latency (even lower than FDR).” Burness says that coupled with all of this, they’re also adding 8 instances of Windows and GUI’d Red Hat Linux in order to provide the “desktop computing” experience for users that need to do so much inside their engineering workflows to support batch processing HPC. “Here, think of the need to run CAD and CAM workloads at one’s computer and then send the files to an HPC cluster. Doing so becomes inherently tougher as the simulated models become more complex and the data sizes grow larger. Having one integrated environment for the entire workflow is a big productivity booster for our industry partners.”
Burness says that, “Throughout all 3 years of operation, iForge has been supported by a GPFS filesystem from IBM running on a DDN SFA-10000 storage system. We pack our storage servers with 192 GB of RAM/server in order to maximize the amount of caching/buffering to RAM, which can really improve performance for I/O intensive applications.” He noted that “A big part of the design focus is on producing a system every year that is as fast or faster than all but a very elite and small number of companies would be able to build and support for themselves (exceptions would General Electric, BP etc.).”
Giles put all of this in real-world terms by referencing a use case with one of the large manufacturers when they first received the early Sandy Bridges. He said that at time, many of their partners weren’t sure how to step up to Sandy Bridge, despite its promise (including AVX capability) for engineering applications. By allowing them to experiment and hit full production runs on the system, Giles says they were able to completely change their workflows, validate the usefulness of the architecture, and push their normal 128-core workflow into 256 core territory. This isn’t something they would have been able to do on their home machines, which are “artificially dumbed down” to support a broader, more policy-based approach to handling daily work.
This work on iForge will be all be overseen by by UI Labs, which is a separate nonprofit organization based out of the university, where it can better leverage academic resources and those found at NCSA as well. This ties in with the announcement this week of a $70 million “grant” (which Giles defines more of a matching funding arrangement similar to NDEMC) for digital manufacturing. This Department of Defense-led project will drive additional matched funds on the order of around $250 million from a number of manufacturing companies and other institutions.
As Burness concluded, “The government funded model of a system that runs in the same configuration for 3-5 years is not good enough for our power users from industry, as they have an insatiable appetite for speed and performance. In addition, we do a lot in design process to ensure a much higher level of uptime than many other HPC systems. A big part of that is our use of the GPFS filesystem. Though it must be licensed and is not faster than Lustre, it is WAYYY more reliable and easier to administer. It’s a huge part of the reason we’re able to achieve 99% uptime on iForge, which is a reliability level that industry demands.”