Doug Baxter is a capability lead for the Molecular Science Computing Facility in the Environmental Molecular Sciences Laboratory (EMSL) at Pacific Northwest National Laboratory. He and his team are responsible for the software side of the operation, and they help experimental scientists get the most out of EMSL’s supercomputing resources. The facility is the home of Cascade, which is ranked number 18 on the current TOP500 list of the world’s most powerful supercomputers.

In this interview, we talk with Doug about EMSL’s Cascade supercomputer, the NWChem software package, and code modernization.

HPCwire: Can you give me a sense of what your daily role is at EMSL?

Baxter: I mainly manage the allocation of resources on our Cascade supercomputer and help our users get up and running on it successfully. Once they get their application running, I have a team of computational biologists, computational chemists and other computer scientists to help them address performance and efficiency.

We’re a national scientific user facility, and we help users from all over the nation working on scientific applications relevant to DOE’s Office of Biological and Environmental Research (BER). They are focused on predictive understanding for biological processes, subsurface flow, contaminants and clean-up, climate modeling, and aerosols.

One thing that makes EMSL special is the combination of our experimental instruments and our high performance computing that provides a theory side to the experimental aspect of science.

HPCwire: Is the work that you’re doing primarily in support of applications running on Cascade?

Baxter: It is primarily in support of Cascade and the corresponding archive system, which is shared with our institutional computing facility. We devote part of our time to outside research projects, including other supercomputing efforts here at the laboratory. We also have an institutional supercomputer, Olympus, and its successor, Constance.

HPCwire: How much of the workload on Cascade is NWChem?

Baxter: NWChem comprises 30 to 40 percent of the workload on Cascade. We keep statistics on what we run on the machine and we’re starting to see an increase in our climate modeling codes, our subsurface flow modeling codes as well as some of our computational biology codes as we have new projects in BER’s areas of interest. But as we support BER’s mission we expect that the computational chemistry pieces will continue to remain a large player.

HPCwire: You commented on climate modeling. Is this a lot of proprietary code?

Baxter: These are mostly codes that come out of NOAA and so they are publicly available codes, including the Weather Research and Forecasting (WRF) model. DOE research heavily utilizes the Community Earth System Model (CESM) and its land model component, the Community Land Model (CLM), both also publicly available. We do a lot of aerosol modeling and that gets down into molecular chemistry level and we’re back into computational chemistry again.

HPCwire: Are many of those codes you’re referring to, other than NWChem, developed for parallel systems?

Baxter: The climate codes and the subsurface flow codes are developed for parallel systems. Parallel systems have been developing over the years as well, so a lot of them have a long history of parallel computing. But that doesn’t necessarily mean they’re set to move on to the next stage of computing, to move on to grander scales of parallelism. That requires some rethinking of the way we’ve traditionally done things in the past.

HPCwire: On that topic of code modernization or code optimization, what does that mean for you and your team as you prepare some of the codes for the many core architectures?

Baxter: Before you get to the parallel stage, you have to start with a good serial code. So some of what we do in preparing code to run at scale is going back to the mathematics and saying, ‘what exactly do we want to solve here?’ Sometimes we have to think differently, in a fundamental way about various things. Traditionally, in parallel computing, the assumption has been, ‘I have a fixed number of resources for the duration of the task that I’m executing and I have a lot of things to do. I partition the tasks that I want done among the players that I have, but my expectation is that all those players play for the full duration of the job and they synchronize with each other.’

One of the difficulties moving forward into exa-scale is global synchronization. As we increase to hundreds of thousands of processes or possibly millions of processes, synchronization becomes untenable. So we must think about things in a non-global-participation way. That requires a fair amount of effort because you need to think differently algorithmically about traditional computing. It used to be that FLOPS were very expensive and memory accesses were relatively inexpensive. So people spent a lot of time saving the results of computation so that they didn’t have to recompute them, doing the expensive part again. Now we’ve got a lot more FLOPS than we have memory accesses, so you can compute much faster than you can move data. That shifts the emphasis – it is sometimes cheaper to recompute a result than have it stored and read back in. So as we move toward greater predictive understanding of the processes that our sponsor is interested in, that requires higher resolution in our models—that means more data points, that means bigger problems to solve. We need more processors to work on problems, but we also have to think about solving them in different ways.

HPCwire: How important is the role of coprocessors moving forward?

Baxter: They are important. They’re really fast at computing but keeping them busy is a challenge, and one of the requirements is the ability to move data to them asynchronously, in a one-sided fashion, which is becoming more prevalent. The Message Passing Interface (MPI) standard is the distributed memory programming paradigm. The MPI 2, and the MPI 3 standards have included one-sided communication protocols where a processor can move data into another processor’s memory space without taxing that processor.

HPCwire: How do you train your staff to get into the right frame of mind?

Baxter: A good starting place is the Jeffers/Reinders book (Intel Xeon Phi Coprocessor High Performance Programming by Jim Jeffers and James Reinders).
Fundamentally, it’s about starting with good serial code and then managing message passing in general. We also spend some effort developing methodologies that work with MPI. One thing I find useful is experimenting with the Intel Symmetric Communication Interface. It’s used to support MPI on the coprocessor. One of the basic ways to use the Xeon Phi coprocessors is to run MPI ranks on each of them so you use the same standard model programming. The difficulty with that is you can’t use all the Xeon Phi coprocessors on more than a handful of nodes because the MPI implementation layer is too memory-intensive. But the SCIF API exposes the communication calls, which allows us to go in and play with that in different ways.

Aside from assisting our various supercomputer users we also have some outside research interests that help improve our ability to help our users. And so part of what I do is work on ways to use those accelerators generically and then push that out to people doing development.

HPCwire: The theme for SC14 this year was “HPC Matters” and for 2015, the theme is “HPC Transforms.” In your own words, why do you think HPC matters?

Baxter: HPC does matter and it continually matters more. We use HPC to solve larger modeling problems, which are designed to help us get what we call predictive understanding of models and processes – such as the flow of radioactive ions leaking from waste tanks. We want to understand how to remediate that problem. Some of what we do is simulate the bacteria that can actually reduce those ions so they precipitate out of solution, making them non-mobile. Some of it is flow analysis of the water table and the surrounding elements to understand if there is a risk of radiation reaching a water source. Some of the modeling that we do is climate modeling to understand aerosols and effects of man-generated pollution on the radiated energy balance and what that is doing to our environment. And those models require lots of data and lots of computation, but they help us understand processes. For something like energy storage, understanding the process helps us control, modify, and improve efficiency.

The other important part of HPC is the predictive modeling. It’s frequently much less expensive to model things and arrive at possibilities for testing experimentally than it is to build many different physical test models. If our model is accurate and looks like a promising way to go, it helps narrow down the breadth of possible solutions in terms of exploring and developing mechanistic, chemical, and biological solutions to technical problems.

HPCwire: Of the work that your team does here, what are you most proud of?

Baxter: At any given time we have about 60 different proposals using our supercomputer. We are proud of the impact we have on science, on our ability to provide a production environment for our users, and our more recent success of transitioning from our previous supercomputer to a new one. It involved planning and experimenting with the old system before we moved it to the new one, and getting the software pieces in order and ready to run. It’s a challenging process, but that was perhaps one of the smoothest transitions we’ve had. We opened the machine to first users on the 6th of December (2013). By the 1st of January all of our users had been ported, all of their codes were running on the new system. So our most significant broad achievement is the transition from a five-year-old supercomputer to the 18th fastest in the world. Migrating users in less than a month is pretty impressive.

HPCwire: Do you have examples of some of the things you can do with Cascade that you couldn’t do with your previous supercomputer, Chinook?

Baxter: One example is in the NWChem arena where we have been able to increase the scale of the problems our users are able to tackle with Cascade.

In terms of peak performance of the machine, our previous machine, Chinook was a 160 teraflop machine; our current machine Cascade is a 3.5 petaflop machine. So that’s more than a 20X improvement in terms of peak performance. Without the accelerators, our expectation was that Cascade would run about three times faster than Chinook. What we found was that it ran four to six times faster.

Getting into the accelerators is a challenge. It takes some effort and rewriting of some code. That’s one of the things we need to get the community to understand is that it’s more than just plunking a machine down on the floor. It takes a software development effort to make these things go. But the return can be worth it. We’ve had some success in getting improved speedups with the accelerators. Linpack-wise, we measure a 2.5 petaflop performance out of the peak 3.4 petaflops. That’s an achievement. We don’t run Linpack on the machine but it’s a measure of the machine’s capacity. Then we work on bringing that kind of improvement to our other codes.