A practitioner trying to simulate a noisy quantum computer faces a choice that physics textbooks do not answer: which method for turning continuous noise into discrete trajectories will be cheapest on the specific hardware they happen to be running. A new preprint argues the answer is not universal. It depends on the machine, the noise level, the time-step, and how many cores can be thrown at the problem.
The paper, "Computational regimes in matrix-product-state-based quantum trajectory simulations", proposes a cost-resolved framework for simulating open quantum systems, the standard name for quantum computers interacting with their environment. Instead of asking which simulation method is "best" in the abstract, the authors decompose the total computational cost into three parts: memory per trajectory, runtime per trajectory, and sampling effort (the number of noise realizations needed to average out the randomness).
The framing matters because, as the preprint shows, two simulation methods that are physically equivalent, meaning they describe the same quantum evolution, can shift the cost around rather than reduce it. One method may use less memory per trajectory but demand far more trajectories to converge to the right answer. Another may be cheap to run on a single trajectory but require more memory to capture the quantum correlations. The total bill changes with the hardware, the noise, and the size of the system being simulated.
To make that trade-off explicit, the authors introduce two dimensionless "inflation factors." The first, α, measures bond-dimension inflation, or how much the memory needed to represent a single trajectory grows above a baseline. The second, κ, measures sampling inflation, meaning how many more trajectories the method demands to reach the same statistical accuracy. Together, α and κ pick out the preferred stochastic unraveling, the specific recipe for turning the continuous noise into discrete jumps, under a given set of memory and parallelism constraints. The preprint pairs these two numbers with a decision map for practitioners: estimate α and κ from a small pilot run, then read off the cost-favorable method for the available hardware.
That decision map is the practical contribution. It turns a math choice that has historically been settled by personal taste or community convention into a measurable engineering parameter. A group writing a grant, designing a simulation pipeline, or choosing between quantum hardware platforms can now ask, in concrete terms, which method will be cheapest for their setup, instead of inheriting whatever default the field happens to use.
The framework is benchmark-dependent, and the authors are explicit about that. The α and κ values are extracted from modest pilot simulations, and the decision maps are drawn from specific noise-channel benchmarks (depolarizing noise, dephasing, amplitude damping), not from a proof of universal optimality. The paper's own framing is that the computationally favorable unraveling can change with the setup, not that the authors have found the best one. The preprint, hosted on arXiv, is not yet peer-reviewed, and the quantitative claims would benefit from independent replication across a wider range of noise models and system sizes.
What the result does establish, and what practitioners can act on now, is a shared vocabulary for a choice the field has been making implicitly. Simulating noisy quantum hardware is a hardware-aware design problem rather than a pure-math problem, and the preprint gives the community a protocol, two dimensionless numbers, a decision map, and a cost decomposition, for treating it that way.