Seventy-one years ago, on July 16, 1945, an incredible explosion lit up the New Mexico night sky. This was the Trinity Test, the world’s first nuclear detonation, and it marked the beginning of the Nuclear Age. It also ushered in the age of supercomputers, which essentially began with weapons science at Los Alamos National Laboratory (LANL).

Now a new Trinity, a next generation Cray XC supercomputer is about to take center stage to help the national security labs achieve their primary mission – to provide the nation with a safe, secure and effective nuclear deterrent. When Trinity is completely installed this year it is expected to be the fastest supercomputer in the U.S. and the second or third fastest in the world. The Trinity project is managed and operated by LANL and Sandia National Laboratories under the Alliance for Computing at Extreme Scale partnership.

Three of the people playing key roles—Manuel Vigil (LANL), the Trinity project co-director, Rob Hoekstra, manager of scalable architecture at Sandia, and LANL scientist Hai Ah Nam who is leading the project’s Center of Excellence (COE)—recently discussed some of the challenges in making Trinity a reality, including transitioning from their existing supercomputer, Cielo, which has been the labs front line system since 2013. With the introduction of the Intel Xeon Phi processor (Knights Landing) as part of the Trinity system, a major challenge for the applications community is transitioning codes to the new architecture.

“We knew that with Knights Landing we were dealing with a completely new architecture – a new way of doing business – and we had to provide some help with code modification to move forward,” explained Vigil. “This means not only modernizing current codes, but also informing the new codes for applications that LLNL, Sandia and LANL will be building in the future. We have many million lines of code in our code base. So our primary challenge is the code transition to the new architecture, with the knowledge that a huge investment in time and energy will be required.

“We have established a Center of Excellence (COE),” Vigil continued, “that consists of internal people – mostly software developers and scientists – along with representatives from Cray and Intel, the two primary vendors. Through the COE, Intel and Cray have been directly helping our teams to improve and modernize our codes to take full advantage of the architecture. The Trinity COE is only an initial investment for helping to transition a small number of codes. But the hope is that it will lay the groundwork and provide lessons learned for the rest of the massive amounts of code that need to be transitioned to work with new technologies.”

“Right now we primarily rely on MPI (Message Passing Interface) for parallelism and scalability of our codes,” Hoekstra said. “We view the Trinity architecture, which is based on the new Knights Landing processors, as a real challenge to MPI. In fact, we have to move from MPI to on-node or shared memory models, along with threading and greater vectorization of the code.” The new architecture is a challenge to MPI because the team will have to learn how to do more threading and to better address vectorization.

Hoekstra continued, “Knights Landing features a two-tier high bandwidth memory that is actually in the same package as the processors instead of being on the board but outside the package. This results in a factor of 5 improvement in memory bandwidth performance that we want take advantage of – it has the potential to significantly accelerate parts of our code. But first we have to learn how we can best utilize this new hardware to the greatest advantage for our codes.”

“We are talking about millions of lines of code,” said Nam. “We expect our code transition efforts to take at least five years. One of the advantages of the COE is that we are able to start the process close to a year before the Trinity platform hits the floor.”

To gain understanding of the next-generation architecture of the system, each of the National Nuclear Security Administration (NNSA) labs selected codes that would help them get a handle on the challenges associated with memory, threading, vectorization and rewriting code.

“We realized that with the COE we could not address of all of the codes at Los Alamos, Sandia and LLNL,” Nam added. “What we are doing is initially targeting key codes at each of the labs to illustrate the process and gather lessons learned for other developers who will be involved now and in the future. The COE is used to demonstrate what can be accomplished and identify the biggest challenges that must be overcome.

“The other thing I’d like to emphasize is that the COE for Trinity is also working with the other national labs and their version of the Center targeting other systems. The idea is to address code modernization considering all future platforms – not just specifically for Trinity, because that would be a mistake.”

The COE for Trinity began gaining traction in May 2015. This included not only putting in place resources from Cray, Intel and the labs, but also initiating various kinds of collaborative code explorations such as Cray-led deep dives focused on large scale performance and Intel-led discovery sessions focused on on-node performance for both the Haswell and Intel Xeon Phi processors.

Vigil said they were also able to install some early versions of the Trinity type Intel Knights Landing processors (aka “White Boxes”) at each of the labs – Los Alamos, Lawrence Livermore, and Sandia National Labs, to help gain hands-on experience to learn how the high bandwidth memory and the high degree of parallelism would impact the codes and their performance.

“The major challenge associated with bringing a supercomputer on line is the unknown” Nam said. “You can speculate about what the processor is going to do, on what capabilities the memory will provide and the functionality, performance and stability of the software and platform ecosystem – but you don’t really know. So the COE is an on-going collaborative process where you are exploring the unknown with your vendor partners who have a lot of experience and have a better understanding of how their product is going to work. They don’t understand your exact use cases and other science requirements, so the COE enables us to expose our concerns and have a willing partner to address the issues.

“This joint exploration into the unknown early on is really important; we can get a jump on efficiently using the system over its lifetime. It’s really helpful to unravel the major problems early in the process.”

In addition to the discovery sessions, the COE also had a Dungeon session with Cray and Intel. For the Dungeon session they sent code team members to Intel where they spent a week of 11 to 12 hour days working closely with Intel tools, compiler and application experts and a representative from Cray. They spent time using and learning Intel’s tools and in turn Intel and Cray learned about the complexity in the multiphysics codes from the coding teams. This real time feedback from compiler, tools and performance experts provided opportunity to improve code efficiency and to try out early vendor hardware and software in order to identify issues early in vendor provided tools.

“Profiling tools can be complex in the wealth of features and output they provide in analyzing a code,” Nam noted. “The Intel analysis suite is both powerful and daunting. The Dungeon sessions bring the Intel experts to work closely with code developers in an intense multi-day working session to use the tools to identify bottlenecks through profiling and implement possible fixes.”

Nam continued, “We made progress in a really intense environment where we looked at the key issues in our code and explored how to improve its performance on Trinity’s advanced architecture, which is far more powerful than anything we have worked with before.

“This is an exciting time,” Nam concluded. “We realize we’re just not modernizing for Trinity, but also making strategic decisions to prepare for upcoming systems including future exascale machines.”