An in-depth chat with NERSC chief architect Nick Wright exploring how the forthcoming Doudna machine redefines supercomputing to meet real-time demands of science.
For decades, supercomputing infrastructure has been built to serve a particular rhythm: simulate, analyze, write the paper, submit the next job.
Systems ran in long, scheduled blocks. The data came in slow and stayed in place. But modern science doesn’t wait. It unfolds in real time, sometimes at the edge of experiment, sometimes in the middle of an outbreak, sometimes on the clock of a beamline or fusion shot.
And what comes next will not necessarily be batchable.
At NERSC, that urgency now has an architectural expression. The system is called Doudna, named after Nobel laureate Jennifer Doudna, and it is the latest machine being built by the Department of Energy facility. The Dell-built system will be delivered in 2026 and is based on NVIDIA’s CPU+GPU Vera Rubin platform, of which there are only some details.
At the center of Doudna’s design is Nick Wright, who leads NERSC’s Advanced Technologies Group and serves as the system’s chief architect.
Wright well understands what scientific users actually need and what modern infrastructure can realistically deliver. He’s been at the heart of system design on a number of large DoE supers and has authored more than 40 papers on performance, architecture, and system-level design.
We talked to Wright this week to dig into the design specifics (as many as he can divulge) and a sense of where forward-looking articles will look to next.
The Doudna supercomputer is designed to accelerate a broad set of scientific workflows and will be connected to DOE experimental and observational facilities through the Energy Sciences Network, allowing scientists to stream data seamlessly into the system from all parts of the country and to analyze it in near real time.
The most important word in the Doudna system architecture is not GPU or simulation or AI. It's seamlessness.
“What we want is that the user can essentially move from programming the supercomputer to programming the datacenter.”
In the old model, scientists might spend weeks preparing data, launching a job, and then waiting for batch queues to deliver results. Today, with data streaming in from telescopes, sequencers, detectors, and reactors in real time, the infrastructure must respond while the experiment is still live.
Wright tells us the design process began not with hardware, but with use cases.
“As part of the procurement, what we did was put out a set of benchmarks and what we called a ‘workflows whitepaper,’” he said. “That basically described how our users use the machine, not just in a traditional sense, where they create an input, do a big run, create an output, draw a plot, and write a paper…More how they run different applications together as part of a workflow, or how they couple the application on the supercomputer to the fusion plasma experiment, or to the telescope, or the genomic sequencer.”
This was the blueprint NERSC shared with the vendor community, not just as a wish list, but as an explicit architectural challenge. How do you design a system that can handle AI training, traditional simulation, streaming sensor data, and analysis in one pipeline, all without forcing the user to break the workflow into separate, asynchronous stages?
Wright described the goal as moving scientists toward a new model of thinking. “They’re thinking about assuring that there’s a quality of service attached to that data motion—both in a network sense and in the sense of writing to the storage,” he said. “And those quality of service features are a really important concept for this machine.”
The shift is technical, but it’s also conceptual. Doudna is not just an evolution of the its predecessor, Perlmutter, which Wright also helped shape. It is a statement about where scientific systems need to go.
And while Perlmutter was designed to serve both simulation and experimental analysis, Doudna is explicitly built to do that at the same time.
“The batch queue will still be there,” he said, “and there’ll still be a whole lot of people running in it.” But the system is being constructed to support new kinds of users…those who don’t work in weeks or days, but in seconds, or less. “They don’t always want to stay up at 2:00 a.m. every night and hand-manage the interaction with the telescope,” Wright explained. “Automation is an important piece of that too.”
In Doudna, automation and orchestration are not software features layered on top of compute, they are architectural priorities. “That’s a really good word—orchestration,” Wright said. “Can you orchestrate the resources to address the science problem at hand?”
The answer, in this case, had to come from the architecture itself.
As noted, Doudna is not just a computational upgrade to its predecessor, Perlmutter, it is a shift in posture. In design conversations, NERSC emphasized not peak speed, but continuity.
That meant rethinking architecture not as a thing to be operated in isolation, but as a system that could be embedded within the experiment itself.
“What we want is that the user can essentially move from programming the supercomputer to programming the datacenter."
“So they’re not just programming things like ‘how many registers do I have’ or ‘am I getting good occupancy on my GPU?’ They’re thinking about moving the data in and out of the datacenter.”
Wright described workloads where scientists must make rapid decisions based on what the system delivers. “If you’re scheduling time on the tokamak, for example, you want to turn around the result of your analysis by a certain time so you can redo the shot of the tokamak. Or you only have a finite amount of time on the beamline or the telescope, for example.”
Batch queues won’t disappear. But they are no longer the dominant frame. Doudna, as Wright explained, must operate for a broader kind of user, in a broader kind of world. “This is sort of about reaching a new segment of the user community at NERSC,” he said. “Kind of supporting the needs of the Office of Science.”
As Wright describes it, Doudna isn’t a resource you schedule. It’s a system NERSC’s diverse users can rely on, one that’s live, adaptive, and designed for what happens next.
But for Doudna to work in this capacity, the system cannot simply run jobs. It must carry them.
This means more than fast interconnects or high-throughput storage. It means orchestrating a system that understands data not as static input and output, but as something in motion. Think words like streaming, staged, sequenced, often before the scientist even knows what they need to look at.
At the heart of Doudna’s infrastructure are two types of storage systems, each built for distinct scientific behaviors.
“The basic idea is we’re going to have two kinds of storage systems on the machine,” Wright said. “One is what I would call a traditional high-performance parallel file system, which is to meet the needs of more modeling and simulation workloads running at scale.”
Alongside the traditional file system (Spectrum Scale) is a second, more modern storage layer. Though not yet announced publicly, it includes support for quality-of-service-driven workloads, those that involve streaming data, inference, or time-sensitive experimental inputs.
The idea is that the architecture should be able to accommodate very different workflows, ones that don’t just require throughput, but predictability.
And that brings us back to the network itself. Wright acknowledged that while not everything can be disclosed, some future-facing mechanisms are under evaluation. “We’re certainly exploring the possibility of programming the network to enable quality of service,” he tells us.
This includes efforts to mitigate latency outliers and support fine-grained orchestration of data paths across the system. “There’s kind of two aspects to that,” he said. “One is just getting the bits across the wire in a timely manner without hitting a long tail latency every now and again.”
The second is more ambitious: programmatic control over how and when data moves. “What software and features you can put on top of those kinds of networking devices to actually move the data around on the user’s behalf,” Wright said. “That’s kind of the programmability orchestration piece too.”
What matters most is not the part number or protocol. It’s the intent. The system must not just support multiple types of science, it must let them all proceed at once, and at full stride.
For decades, supercomputers were built with one kind of user in mind: the traditional computational scientist, fluent in MPI and Fortran, familiar with compilers, batch schedulers, and shell scripts. This user still exists, Wright agrees, but the growing reality, especially in research facilities like NERSC, is that the shape of the user base has changed. And so the systems must change with it.
When asked what had to be rethought architecturally in Doudna. “One is that, on its own, HPC is not a market that drives things now. AI is the predominant market force there.”
The question Wright and his team asked themselves was not whether to resist that change, but how to leverage it. “How much of these technologies could we utilize for the needs of scientific computing?” he said. “How many of them can we leverage, both in a hardware and a software sense?”
Some of that reckoning is also purely generational. “Something like a third to a quarter of our users are actually graduate students,” Wright adds. “And so they are coming in expecting a world that doesn’t look like a traditional batch queue system with Fortran and a makefile, right?”
These users are shaped by modern tooling, shaped by cloud infrastructure, shaped by the machine learning ecosystem. “They’re used to this more AI-influenced, Kubernetes, function-as-a-service kind of world,” Wright explains.
Doudna’s architecture had to make room for that. It had to meet users where they already are, without abandoning the existing base. “It behooves us not only to take advantage of those kinds of things, but it is also somewhat of an expectation of our users that some of those things are there,” he said.
This dual responsibility—to serve the traditional HPC workload and also accommodate the evolving, often AI-native workflows of a new generation—may be one of the most complex design challenges NERSC has ever faced.
It’s not just about containers or scheduling policies. It’s about how scientists think, how they learn, how they expect infrastructure to behave.
One of the more obvious points about the new system is that with great computational power comes great…well, power usage. At a certain scale, electricity stops being an infrastructure detail and becomes the system’s defining constraint.
Doudna is not the first supercomputer to push past the limits of a facility’s original electrical envelope. But it may be the first NERSC system designed with the assumption that future machines can’t just draw more power, they have to justify it. Not in raw performance terms, but in terms of scientific impact per watt. Or, as Nick Wright puts it, science per joule.
“As part of the NERSC-10 effort… we are actually upgrading the building as well,” Wright said. “We’re putting in more power, and it’s sort of an inevitable consequence of the technology trends. In order to keep increasing performance, you need to keep increasing the power of the facility.”
“Clearly though, we can’t keep doing that forever,” Wright said. Which is why Perlmutter has served as a proving ground for energy-aware practices and power optimization at scale. “We’re doing a lot of work on Perlmutter, and we will continue to do a lot of work on NERSC-10… to understand where the power is going and where the energy is going.”
The real goal is to understand whether a system can make energy use intelligent…contextual, responsive, even user-controlled. “Can we get it to the point where we optimize the science per joule? We’re not there yet. We’ve got a long way to go. But that’s kind of the way we’re thinking about it.”
And the strategies for getting there aren’t just about hardware. They’re about control.
There was much to consider on this front. “What architectural features can we encourage vendors to introduce that would enable a user to control power and energy usage in ways that make sense?” Wright reflected.
Right now, most users have access to crude mechanisms (power caps, for instance) but nothing truly dynamic. “You can put a power cap on, right? But that’s a relatively crude way of doing it.”
What Wright envisions is something finer-grained. “You might imagine that you run a code that’s memory bound, and so it says, ‘Turn up the memory power to 11, please, and turn the GPU power down,’” he explained. “And then conversely, the next person comes in and knows they’re compute bound, and so they do the opposite.”
And playing with recision doesn’t just apply to workloads it also applies to power.
Doudna, like many newer systems, is being built with increasing support for mixed-precision compute, especially in domains where AI models or surrogate approximations allow for lower numerical precision without sacrificing scientific validity.
“I think that generally goes back to the point earlier,” Wright said. “Scientific computing is going to have to figure out how to take advantage of lower precision where it makes sense.”
The work is ongoing. “There are some features of the architecture I can’t talk about that do kind of balance those particular needs across the user space,” Wright said.
Most of those details are embargoed until NVIDIA’s GTC in 2026. “There are details of the architecture I can’t tell you about right now,” Wright said. “But hopefully will be announced at GTC.”
Until then, what matters most is that the problem is finally being treated as part of the architecture itself—not an optimization layer added after the fact, but a structural concern baked into the way the system runs and what it runs for.