Solving Aerodynamics Problems With Quantum Computers
Interview with William Steadman – Quanscient
Ahead of his presentation at CDFAM DC, we spoke with William Steadman of Quanscient, a Finnish physics simulation company whose research arm works on quantum algorithms for computational fluid dynamics.
In this interview, William walks through the current state of CFD on quantum hardware, including recent results from their custom Lattice Boltzmann Method, how different quantum architectures shape the way a problem is formulated, and where the quantum step actually sits within a hybrid classical workflow.
He also covers how these methods are being integrated into Quanscient’s multiphysics software and the trade-offs he expects to discuss with partners across aerospace, maritime, and automotive.
For those unfamiliar with Quanscient, how would you describe the company and the work you will be presenting at CDFAM DC?
Quanscient is a Finnish physics simulation technology company. Our flagship product, Quanscient Allsolve, is a cloud-based multiphysics simulation software used for advanced simulations in applications such as MEMS, superconductors, and electric motors. I’m part of the company’s research arm, Quanscient Quantum Labs, one of the world’s leading groups in quantum algorithms for CFD,
At CDFAM DC, we’ll show hardware results from our recently published work using our custom Lattice Boltzmann Method and part of current work with pilot customers in aerospace, automotive, and maritime.
The talk will be targeted to those who want an overview of where quantum hardware for CFD is currently and where there will be active developments in the near term.
The abstract references the largest CFD simulations deployed to date on quantum hardware. What defines the scale of these runs, and how do they compare to simulations run on GPU or CPU?
We’ve been focused on the case of simulating a solid object immersed in a fluid, think airfoil, hydrofoil or vehicle. When we talk about scale here, we mean the Reynolds number which can be simulated, which is determined both by the method and for our LBM or analogous algorithms, the grid size encoded on the quantum hardware. In our recent paper, we showed results on quantum hardware of a full 2D method for the incompressible regime and we also have simplified 3D results.
Current quantum hardware is still limited by noise, so that even at very small grid sizes the simulation is corrupted by noise, even though much larger problems could be encoded. So accurate simulations on quantum hardware are still far below GPU and CPU simulations. With the industry moving to error corrected quantum hardware though, we will see new scales of quantum simulations soon and we’ve started this transition as well.
IBM and IonQ represent different quantum architectures. How do their characteristics affect the way a CFD problem is formulated and benchmarked, and where do the results diverge?
There are some different capabilities between the architectures, such as in ion traps and neutral atoms the physical qubits are movable, which opens up ways to make our formulation more efficient.
I would say it is akin to low level performance optimizations for classical compilers, which is key to making the most performance out of a particular hardware, but there is no limitation preventing a model on one hardware from being transpiled for another.
So given the current performance limitations, when we come to a particular quantum hardware, we use a noise model to evaluate what size and type of CFD can be encoded before the hardware noise completely corrupts the results.
That said each generation is better than the previous and once we move the error corrected quantum hardware then each architecture is abstracted in some form.
Walk us through how a simulation moves between the classical and quantum sides of the workflow. Where does the quantum step actually sit in the pipeline, and how is the data handed off in each direction?
That is a good question and I’ll describe two workflows, a current hybrid one and a future end-to-end quantum workflow.
So one key thing is that quantum computers have a set of gates and these all perform linear operations. Now, CFD is notable in that we very often want to solve a highly nonlinear problem.
This leads to hybrid workflows, where we solve a linear subproblem or perform a single timestep, extract the data, do something classically to capture the nonlinear aspect, and then re-encode on the quantum computer.
This works, but comes with the significant overhead of extracting data between the classical and quantum sides. Another option is to come up with a way to approximate or truncate the nonlinearities and encode onto the quantum computer and this is very much an area of active research. This then enables running a full problem on the quantum computer and also opens the possibility of extracting just a single quantity of interest, such as the amount of lift for an airplane wing, from the simulation.
Quantum methods are being integrated into Quanscient’s multiphysics software rather than kept separate. What did that integration require, and how does a user encounter the quantum component in practice?
There is the oft-cited quote, all models are wrong, but some models are useful. The Lattice Boltzmann method (LBM) we are working on is applicable to certain regimes, so we are scaling up our classical LBM algorithms, so that customers will be able to evaluate it for their workflows, and we can give guidance on the levels of accuracy for the quantum algorithm.
Secondly, in Quanscient Allsolve, we demonstrate how to use AI to synthesize a set of high-quality simulations to model the entire design space. This fits nicely, as our intermediate plan for quantum is to use AI to ingest high-quality but limited quantum simulation results and combine them with other data, to provide an advantage on an industrial problem.
For our quantum customers, we are currently focused on benchmarking and building familiarity with the models. Going forward, we expect customers to be interested in both classical and quantum solvers, and that, step by step, the quantum solver will contribute more and more to a unified workflow.
Across aerospace, maritime, and automotive collaborations, what trade-offs are you hoping to put in front of this audience, and what would you like to take away from the conversations at CDFAM DC?
First and foremost, we do want to make the trade-offs clear. One particular trade-off is that while quantum algorithms can operate on scales far beyond classical computing, one cannot necessarily extract the full set of information.
Our goal is to identify and address specific challenges within the aerospace, maritime, automotive, and other key industries where these trade-offs justify further investigation. As the technology matures, we will collaborate closely with industry partners to build confidence in our solutions and overcome their unique operational constraints.
The conversations at CDFAM DC happen at the jagged edge of engineering, where new tools are being built and put to work.
On July 15 and 16 in Washington DC, the people making these tools and the people adopting them will converge across industry, government, and research. If this is the work you are doing, join us. Register at cdfam.com/cd-dc-26/#register.
