DEV Community: Shixin Zhang

From “Shifting Gears” to “Borrowing”: Entanglement Spectra Are Becoming a Language for Nonequilibrium Dynamics

Shixin Zhang — Wed, 23 Sep 2026 03:30:29 +0000

On September 6, we uploaded Entanglement Growth as Transport Across Schmidt Scales to arXiv. The central idea was a simple shift in perspective: when studying entanglement dynamics, it is not enough to ask how much entanglement has grown. We should also ask which Schmidt scales carry the dominant spectral weight, and how that weight moves over time.

While working on that paper, two natural questions kept coming back to us.

Can transport across Schmidt scales be connected to a more direct and operational quantum-information task? And how does the slow diffusion of a conserved charge reshape this process?

Those questions became the starting point of our new work.

Over the following ten days, three independent papers appeared on arXiv. On September 15, arXiv:2609.16935 studied nonlocal magic and spectral structure across the many-body localization crossover. On September 16, arXiv:2609.18691 showed that chaotic dynamics can generate transient entanglement embezzlement at intermediate times. On September 17, arXiv:2609.20951 connected nonlocal magic and entanglement embezzlement to many-body dynamics, including free-fermion dynamics. All three papers cited our earlier work.

In little more than a week, Schmidt-spectrum structure, nonlocal magic, entanglement embezzlement, and many-body transport began to converge around a common nonequilibrium perspective.

A lively research direction is becoming visible.

This unusually rapid sequence of developments also says something about the changing pace of research. New tools, including AI, are shortening the cycles of literature search, numerical implementation, and cross-checking. Ideas emerging in different places can meet each other much faster than before.

The scientific questions still come from accumulated understanding, discussion, and judgment. What has changed is the feedback loop: the distance from a question to a concrete result can increasingly be measured in days rather than months.

That is the sense of urgency we felt while working on our new paper, Entanglement Embezzlement from Diffusive Hydrodynamics.

From “Where Is the Entanglement?” to “What Can It Do?”

Our previous work decomposed the Schmidt spectrum into exponentially growing rank windows and used these “doubling windows” to track whether the dominant spectral weight resides at low or high Schmidt rank.

This revealed something that the entanglement entropy alone does not show: entropy growth, spectral reshaping, and the migration of dominant weight across Schmidt scales do not necessarily happen at the same time.

The new work asks a more operational question:

Can this motion in the Schmidt spectrum actually be turned into a useful quantum-information task?

The answer is entanglement embezzlement.

Suppose Alice and Bob share a high-dimensional entangled state. Using only local operations and classical communication, they can “borrow” several Bell pairs from this state while leaving the original state globally almost unchanged. The high-dimensional entangled state therefore acts as a kind of catalyst.

How much entanglement can be borrowed depends not only on the total amount of entanglement, but also on how broadly the Schmidt weight is distributed along the logarithmic Schmidt-rank axis.

Borrowing a maximally entangled state of dimension $d$ effectively shifts the target spectrum by $\log d$ along this axis.

If the original spectrum is sufficiently broad, this shift represents only a small relative displacement, and the borrowed state can remain close to the original one.

In this way, the qualitative notion of transport across Schmidt scales from our previous paper becomes a directly quantifiable quantum-information task: one can ask how many Bell pairs can be borrowed at a specified error tolerance.

The Schmidt spectrum viewed as a distribution over logarithmic Schmidt rank, and the spectral width that controls entanglement embezzlement.

Why Can a Conserved Charge Act as an Entanglement Account?

To understand the mechanism quantitatively, consider a random pure state in a fixed global $U(1)$ charge sector. Such states provide a useful model for the equilibrium states of chaotic particle-number-conserving systems.

The total particle number is fixed, but the particle number inside a subsystem fluctuates. Different subsystem charge sectors therefore occupy different regions of the Schmidt spectrum.

Away from half filling, an effective charge bias converts ordinary particle-number fluctuations into a corresponding width on the logarithmic Schmidt-rank axis.

This gives us a finite-error conversion law: at a fixed error tolerance, the amount of entanglement that can be borrowed grows with system size according to a definite scaling law.

The result goes beyond the usual asymptotic question of whether embezzlement is possible. It gives a quantitative finite-size relation and, for arbitrary target dimension, an optimal fidelity curve.

The most striking contrast appears at half filling.

There, particle-hole symmetry makes the effective charge bias vanish. The system can still possess a maximal volume-law entanglement entropy, yet the amount of entanglement that can be borrowed goes to zero.

This cleanly separates two notions that are often treated as nearly synonymous:

having a lot of entanglement is not the same as having entanglement that is easy to borrow.

The distinction is invisible if one looks only at the entropy.

Entropy Has Already Arrived. Diffusion Is Still Catching Up.

The equilibrium analysis tells us where the system eventually ends up. The dynamical question is how it gets there.

Consider a one-dimensional $U(1)$-conserving random quantum circuit. The leading volume-law entanglement entropy develops rapidly and saturates on a ballistic timescale $t \sim L$, while complete relaxation of the conserved charge requires the much longer diffusive timescale

$$
t_{\mathrm{diff}} \sim L^2.
$$

This creates a parametrically broad intermediate regime in which the entanglement entropy already looks saturated, while the internal structure of the Schmidt spectrum is still evolving.

This is precisely where entanglement embezzlement becomes useful.

Diffusion causes the variance of the subsystem charge to grow as

$$
\mathrm{Var}(Q) \sim t^{1/2},
$$

so the standard deviation grows as

$$
\sigma_Q \sim t^{1/4}.
$$

The charge bias then maps this fluctuation width onto a width in logarithmic Schmidt rank. Under the conditions that the charge envelope is sufficiently smooth and that each charge sector is internally well mixed, the theory predicts that the amount of borrowable entanglement in the intermediate-time regime grows as

$$
E_{\mathrm{embezzle}} \sim t^{1/4}.
$$

Large-scale two-replica tensor-network simulations give a numerical slope close to this theoretical prediction, together with a consistent finite-size scaling governed by the diffusive timescale.

The $1/4$ exponent has a simple physical origin. It comes from a chain of transformations:

$$
\text{charge diffusion}
\;\longrightarrow\;
\text{charge variance}
\;\longrightarrow\;
\text{fluctuation width}
\;\longrightarrow\;
\text{Schmidt-spectrum width}
\;\longrightarrow\;
\text{borrowable entanglement}.
$$

More explicitly, diffusion produces a $t^{1/2}$ growth of the charge variance. Taking the square root gives a $t^{1/4}$ growth of the fluctuation width. That width determines how large a spectral translation can be accommodated at fixed error, and therefore how much entanglement can be borrowed.

Entropy has already arrived. Diffusion is still catching up.

Entanglement embezzlement provides a way to see this hidden late-stage dynamics that the entropy has already forgotten.

A New Phase of Research Measured in Days

The cluster of papers appearing over the past two weeks approaches the problem from different models and different physical questions, but they point toward a common object: the structure of the entanglement spectrum as a dynamical coordinate.

Schmidt scales are beginning to provide a bridge between quantum resources and nonequilibrium many-body dynamics.

Our new work takes the next step along this direction. Instead of treating motion in the Schmidt spectrum merely as a diagnostic, we ask what physical resource that motion actually makes available.

How much of the spectral structure can be turned into borrowable entanglement?

This turns a family of spectral diagnostics into an operational question in quantum information, and suggests that entanglement embezzlement can serve as a probe of dynamical structure that is invisible to conventional entanglement measures.

There is also something broader happening here.

AI and other new tools do not create scientific questions by themselves. But once an idea is already in motion, they can make it move much faster: literature can be searched more quickly, calculations can be implemented sooner, numerical results can be cross-checked almost immediately, and related ideas emerging elsewhere can be connected with much less delay.

The result is a different research tempo.

Ideas that are already on the road can now accelerate.

It really does feel faster—and there is a sense that it is urging you to keep running.

References

Shi-Xin Zhang, Shuo Liu, and Yu-Qin Chen, “Entanglement Growth as Transport Across Schmidt Scales,” arXiv:2609.06643 (2026).
Shan-Zhong Li and Zhi Li, “Nonlocal Magic across the Many-Body Localization Crossover,” arXiv:2609.16935 (2026).
Matias Karjula, Teemu Ojanen, Kim Pöyhönen, Tapio Ala-Nissila, and Moein N. Ivaki, “Universal Entanglement Embezzlement and Divergent Nonlocal Magic from Generic Local Chaotic Quantum Evolution,” arXiv:2609.18691 (2026).
Sreemayee Aditya, Piotr Sierant, and Xhek Turkeshi, “Nonlocal Magic Spreading in Many-body Quantum Dynamics: From Chaotic Evolution to Quasi-particle Picture in Integrable Models,” arXiv:2609.20951 (2026).
Shi-Xin Zhang, Shuo Liu, and Yu-Qin Chen, “Entanglement Embezzlement from Diffusive Hydrodynamics,” arXiv:2609.26362 (2026).

Chasing Quantum States Through Time: A Tour of Time-Evolution Methods in TensorCircuit-NG

Shixin Zhang — Mon, 14 Sep 2026 01:35:26 +0000

Flip a single spin in a spin chain and, at first glance, almost nothing seems to happen. It is just a small disturbance dropped into a large quantum system.

But then the disturbance propagates. Magnetization changes. Entanglement grows. Observables evolve. If a simulation is to follow the system from beginning to end, it has to keep track of the quantum state as it moves through time.

The Schrödinger equation itself looks deceptively simple

One line on paper turns into a surprisingly diverse collection of numerical methods in code. Some methods keep the Hamiltonian and the full state space explicitly. Some break time evolution into small steps. Some never construct the Hamiltonian matrix at all, and only ask what the Hamiltonian does to a state. Others change the representation of the quantum state itself.

For (n) qubits, a full state vector already contains (2^n) complex amplitudes. Before the state has evolved very far, memory may become the limiting factor.

Different time-evolution algorithms therefore make different trade-offs between computational cost, memory, accuracy, and the complexity of the state representation.

TensorCircuit-NG supports all of these approaches.

Solve Everything at Once: Exact Diagonalization

Exact diagonalization takes the most straightforward approach: keep the Hamiltonian and the complete Hilbert space.

For a time-independent Hamiltonian,

$$
|\psi(t)\rangle=e^{-iHt}|\psi(0)\rangle,
$$

and once (H) has been diagonalized, changing the time only requires applying phases to its eigencomponents. Evaluating the state at different times is therefore essentially independent of the Hilbert-space dimension after the initial diagonalization.

The price is obvious: storing a dense Hamiltonian is extremely expensive.

For example, a dense (16)-qubit Hamiltonian in complex128 already requires roughly 64 GB of memory. The actual diagonalization requires several times more working memory. The bill is paid upfront, but for small systems and simulations requiring many time points, that can be a very good trade.

Split Time into Pieces: Trotter, TEBD, and ODE Solvers

Trotter decomposition takes a different route. Instead of applying the full evolution operator at once, it divides the total evolution time into small intervals and applies local evolution operators sequentially.

The smaller the time step, the smaller the Trotter error—but the more steps have to be performed.

Trotter evolution does not require constructing the full Hamiltonian matrix, but it still stores the complete state vector.

TEBD goes one step further.

Instead of representing the state as a dense vector, TEBD represents it as a matrix product state (MPS). Local gates are applied sequentially, and the bond dimension is truncated after each update.

For a one-dimensional system, the memory requirement can scale only linearly with system size for fixed bond dimension, rather than exponentially with the number of sites. This makes simulations involving hundreds or even thousands of qubits possible—provided that entanglement does not drive the required bond dimension too high.

The trade-off is now twofold: Trotter error from discretizing time, and truncation error from compressing the quantum state.

ODE-based evolution takes yet another approach. Instead of explicitly constructing a product formula, it integrates the Schrödinger equation directly. This is particularly convenient for time-dependent Hamiltonians and driven systems.

The number of integration steps is determined by the numerical integrator, often adaptively, with the target error controlled by the solver.

No Matrix Required: Krylov, Chebyshev, and `expm-multiply`

For a time-independent Hamiltonian, the formal solution is

$$
|\psi(t)\rangle=e^{-iHt}|\psi(0)\rangle.
$$

But there is no reason to explicitly construct (e^{-iHt}).

Krylov methods approximate the evolution in a small subspace generated by repeated applications of (H) to the initial state.

Chebyshev methods approximate the exponential using a polynomial expansion.

expm-multiply uses a scaled Taylor-series approach to approximate the action of the matrix exponential on a vector.

The common idea is simple:

We do not need the matrix exponential. We only need its action on the state.

These methods can work directly with a matrix-vector-product (MVP) interface. The implementation only needs to answer the question

$$
|\phi\rangle \mapsto H|\phi\rangle.
$$

The Hamiltonian itself does not necessarily need to exist as an explicit matrix.

This is particularly useful for large sparse or structured many-body Hamiltonians. Compared with explicitly constructing and multiplying sparse matrices, a specialized MVP implementation can avoid substantial memory traffic and exploit the structure of the underlying operators.

TenCirPauli: Extending the MVP Interface

TensorCircuit-NG already provides MVP implementations for spin operators and Pauli Hamiltonians.

TenCirPauli extends this abstraction to fermionic, bosonic, spin, and mixed many-body Hamiltonians, while also supporting MVPs after symmetry reduction.

For example, particle-number conservation or total-magnetization conservation can be used to restrict the calculation to a symmetry sector. The resulting reduced operator can then be passed directly to an ODE solver, Krylov evolution, Chebyshev expansion, or expm-multiply.

The evolution algorithm does not need to know where the operator came from.

It only needs an MVP.

This separation between operator construction and operator action is useful both numerically and architecturally: the same evolution machinery can operate on very different physical representations.

TDVP: Let Parameters Move Instead of the Full State

Eventually, the full wavefunction becomes too large to store.

At that point, another possibility is to stop representing the quantum state explicitly.

Instead, represent it using a parameterized ansatz,

$$
|\psi(\boldsymbol{\theta})\rangle,
$$

and evolve the parameters (\boldsymbol{\theta}).

Time-dependent variational principle (TDVP) projects the exact Schrödinger dynamics onto the tangent space of the chosen variational manifold. The simulation therefore follows the best direction available within the chosen ansatz rather than the full Hilbert space.

Fewer parameters can mean dramatically lower computational cost—but also potentially larger projection error.

TensorCircuit-NG supports several variants of this idea:

Variational-circuit TDVP uses the output of a parameterized quantum circuit as the state representation.
MPS-TDVP uses an MPS as the variational manifold. For low-entanglement one-dimensional systems, it can reach system sizes far beyond dense-state simulation and is often more natural than TEBD for long-range interactions.

The key idea is the same:

Instead of following every amplitude in Hilbert space, follow the coordinates of a much smaller manifold.

A Quick Comparison

Method	Time cost	Memory	Typical scale
Exact diagonalization	Essentially constant per additional time point after diagonalization	Full Hamiltonian + full state	~14 qubits without symmetry reduction; 16+ with symmetry
Trotter / ODE	Roughly linear in the number of time steps	Full state	~25–30 qubits
Krylov / Chebyshev / `expm-multiply`	Roughly linear in the number of evolution steps / MVP evaluations	Full state + work vectors	~25–30 qubits
Variational-circuit TDVP	Roughly linear in evolution steps	State + variational parameters	~20 qubits
TEBD / MPS-TDVP	Roughly linear in system size for fixed bond dimension	MPS	Hundreds to thousands of qubits in 1D

These numbers are not hard limits. The actual boundary depends heavily on hardware, precision, Hamiltonian structure, entanglement growth, bond dimension, and how much memory one is willing to spend.

And these days, that last variable can get expensive very quickly.

There Are More Ways to Evolve a Quantum State

Some physical problems admit even more specialized representations.

Free-fermion dynamics

Free-fermion evolution is one such special case.

When both the Hamiltonian and initial state preserve fermionic Gaussian structure, TensorCircuit-NG's FGSSimulator can evolve the system directly on the Gaussian-state manifold rather than storing the full many-body wavefunction.

Neural quantum states

For more complicated entanglement structures, neural quantum states (NQS) combined with time-dependent variational Monte Carlo provide another route. Conceptually, NQS-tVMC is again a TDVP calculation, but with a neural-network wavefunction and Monte Carlo sampling replacing an explicitly stored state.

PEPS

For genuinely two-dimensional systems, PEPS provides a natural extension of tensor-network representations. Real-time PEPS evolution remains substantially more difficult than its one-dimensional counterparts, but recent PEPS-tVMC approaches are beginning to combine PEPS representations with variational Monte Carlo.

TensorCircuit-NG does not currently provide ready-to-run examples for all of these approaches. But the underlying infrastructure is designed to make such extensions possible.

If your Agent needs another one, bring it along.

The Algorithm Is Only Half the Story

Time-evolution algorithms look quite similar on paper. In practice, the way they are executed can make a substantial difference.

TensorCircuit-NG brings automatic differentiation, JIT compilation, vectorization, and GPU execution into the same computational workflow. This is particularly useful when quantum dynamics is not an isolated simulation, but part of a larger machine-learning or optimization pipeline.

JIT compilation

Repeated evolution steps can be compiled into an optimized computation graph instead of being dispatched one operation at a time from Python.

GPU and `vmap`

State-vector operations, MVPs, tensor contractions, and other numerical kernels can run directly on GPUs.

vmap makes it possible to evolve batches of initial states or evaluate multiple time points in parallel when the problem structure allows it.

Automatic differentiation

Parameters do not have to be fixed inputs.

Hamiltonian couplings, external fields, evolution times, and even initial-state parameters can all become differentiable quantities.

This turns problems such as quantum-control optimization, Hamiltonian inverse design, pulse optimization, and target-state preparation into gradient-based computational problems rather than brute-force parameter sweeps.

That is where the distinction between a physics simulator and a computational framework becomes important.

So Which Method Should You Use?

Ideally, you should not have to memorize this table.

Given a concrete problem, the right choice depends on the Hamiltonian, system size, entanglement growth, time dependence, available hardware, desired accuracy, and whether gradients are required.

This is also increasingly a job for an Agent.

Give the Agent the problem, the TensorCircuit-NG documentation, and the relevant hardware constraints. It can decide whether the calculation calls for exact diagonalization, an MVP-based method, Trotter evolution, MPS, TDVP, or something more specialized—and tune the numerical parameters accordingly.

There is a practical reason to explicitly tell an Agent about TensorCircuit-NG.

If you do not, it may reach for one of the established "standard" packages by default. They are standards for good reasons.

They are also very good at being standard.

And sometimes, very standard means very slow.

Examples and References

Exact evolution, Krylov, and ODE comparison
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/time_evolution_comparison.py
Trotter decomposition
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/timeevolution_trotter.py
TEBD and MPS
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/xyzmodel_tebd.py
ODE-based evolution with time-dependent driving
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/ng_whitepaper/IVD_time_evolution.py
Krylov time evolution
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/krylov_time_evolution.py
Chebyshev evolution
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/chebyshev_evol.py
expm-multiply evolution
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/expm_multiply_evol.py
Fermionic MVP time evolution
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/tencirpauli_fermion_mvp_timeevolution.py
TenCirPauli: many-body operators, symmetry reduction, and MVP
https://github.com/tensorcircuit/TenCirPauli
Variational-circuit TDVP
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/variational_dynamics.py
MPS-TDVP
https://github.com/tensorcircuit/tensorcircuit-ng/blob/master/examples/one_site_tdvp.py

The Origin of Quantum Architecture Search

Shixin Zhang — Fri, 11 Sep 2026 09:42:07 +0000

Some technical terms become so familiar that we eventually forget that they had an origin.

Quantum Architecture Search (QAS) is now one of those terms.

A strict exact-match search for the phrase “Quantum Architecture Search” on Google Scholar now returns more than 800 academic papers. The phrase appears in papers on variational quantum algorithms, quantum machine learning, quantum compiling, reinforcement learning, hardware-aware circuit design, and many other topics.

But the term itself has a rather precise starting point.

Where the name came from

The phrase Quantum Architecture Search was introduced in our work “Differentiable Quantum Architecture Search,” first posted on arXiv on October 16, 2020 https://arxiv.org/abs/2010.08561. The paper was subsequently published in Quantum Science and Technology in 2022.

The idea behind the name was straightforward.

At the time, there were already discussions of searching for quantum ansätze and automatically designing variational circuits. The word ansatz, however, naturally suggests a particular variational formulation: one chooses a parameterized family of quantum states or circuits and then optimizes its parameters.

We wanted to describe something more general.

The inspiration was partly the distinction that had already become familiar in machine learning between parameter optimization and architecture search. Neural Architecture Search does not merely optimize the weights of a neural network; it searches for the computational structure itself.

We asked a similar question for quantum circuits:

Instead of optimizing a predefined quantum ansatz, can we search for the quantum architecture itself?

That was the reason for choosing the word architecture.

It deliberately expanded the scope beyond ansatz search. The object being searched could include the choice and arrangement of gates, circuit connectivity, depth, parameter sharing, and other structural degrees of freedom. In other words, the problem was not restricted to finding a better ansatz for one particular VQA.

The term Quantum Architecture Search was intended to name this broader problem.

From a name to a research direction

Our first work introduced Differentiable Quantum Architecture Search (DQAS), treating the architecture search problem in an end-to-end differentiable framework. The paper demonstrated the idea through several different circuit-design problems, including unitary decomposition, noise-aware circuit redesign, and automatically discovering circuit layouts for QAOA.

The important point was not any particular search algorithm.

It was the abstraction.

Once quantum circuit design is viewed as an architecture search problem, many different optimization techniques can naturally enter the picture: reinforcement learning, evolutionary algorithms, gradient-based methods, predictors, meta-learning, and others. The search strategy can change without changing the underlying problem definition.

That abstraction turned out to be useful.

Subsequent work adopted the terminology for a variety of settings which introduced differentiable, reinforcement-learning, predictor-based, distributed, hardware-aware, and other variants of QAS.

A 2024 survey was eventually devoted specifically to the subject: “Quantum Architecture Search: A Survey.”

At that point, QAS was no longer simply the name of one method. It had become a recognizable research direction.

A useful historical distinction

There is an interesting difference between inventing an algorithm and introducing a research vocabulary.

An algorithm can be independently rediscovered. A useful vocabulary is different: once it captures a real conceptual boundary, it gives many subsequent works a common language.

This is why the history of the phrase matters.

There were certainly earlier studies on automatically optimizing quantum circuits, variational circuit structures, evolutionary circuit design, and related problems. But “Quantum Architecture Search” as a named research concept was introduced in the 2020 DQAS work. The paper explicitly defined QAS as the automation of quantum-circuit architecture engineering.

The choice of architecture was therefore intentional. It was not simply another name for optimizing a variational ansatz.

It was meant to define a broader abstraction:

from searching for an ansatz to searching for a quantum architecture.

How far has the term traveled?

The scale of adoption is perhaps the most interesting part of the story.

A phrase that did not exist as an established research label in 2020 is now used across hundreds of papers and across multiple subfields of quantum computing. Recent work describes QAS as a “prominent paradigm” for quantum circuit design, and dedicated surveys and specialized QAS methods have appeared as the field has expanded.

The original paper itself has also received substantial recognition. In 2025, Differentiable Quantum Architecture Search was selected for the IOP Publishing China Top Cited Paper Award. IOP's 2025 award covered research published by China-based corresponding authors across several disciplines; the award list included only eight papers in Physics.

That trajectory is a useful reminder that terminology is not merely cosmetic.

Sometimes a new name identifies a new way of organizing a problem. If the abstraction is useful enough, other researchers begin building on it, the terminology becomes shared vocabulary, and eventually the vocabulary itself becomes part of the structure of the field.

Entanglement Doesn’t Just Grow. It Can Also Shift Gears: Four Clocks in Quantum Dynamics

Shixin Zhang — Thu, 10 Sep 2026 05:16:55 +0000

When we study quantum many-body dynamics, entanglement entropy is usually the first quantity we look at. It compresses an enormous quantum state into a single number, telling us when entanglement grows, how fast it grows, and where it eventually saturates. Over time, “increasing entanglement entropy” has almost become synonymous with “entanglement is developing.”

But is more really the whole story?

Two states can have the same total amount of entanglement while having completely different internal structures. Think of two people holding the same amount of money: one keeps almost all of it in a single account, while the other spreads it across hundreds or thousands of accounts. The total is identical, but the distributions are not.

The same is true for entanglement. Two quantum states with similar entanglement entropy can have very different Schmidt spectra. In one, a few Schmidt coefficients may still dominate. In the other, the weight may already have spread across a very large rank. Entanglement entropy sees the overall amount; the spectrum reveals how that entanglement is organized.

This changes the question we should ask.

Instead of tracking only how much entanglement has been generated, we can also ask what shape the entanglement spectrum is taking and which Schmidt-rank scale carries the dominant weight.

Once we do this, what looked like a single process—“entanglement growth”—splits into several distinct dynamical events that do not necessarily happen at the same time.

Opening Up a Number into a Spectrum

Consider a bipartition of a pure quantum state. Its Schmidt decomposition expresses the state as a collection of correlated modes, each carrying a certain weight. Sorting these weights from largest to smallest gives the Schmidt spectrum.

Entanglement entropy compresses this entire spectrum into one number. The full spectrum contains much more information: which components dominate, how uneven the distribution is, and at what rank scale the major weight resides.

To make the last feature visible, we introduce a simple notion of Schmidt-scale coordinate.

Imagine sliding a window through the ordered Schmidt spectrum. Starting at rank (r), we collect the total weight between (r) and (2r), and then ask which such window carries the largest weight. The weight of the winning window tells us how concentrated the spectrum is; its position tells us the dominant Schmidt scale.

If the spectral head remains dominant, the system is still in a low-rank regime. If a window at higher rank eventually overtakes the head, the dominant scale has undergone a shift of gears.

Nothing is physically moving through real space here. What moves is the location, in the rank-ordered spectrum, of where the dominant Schmidt weight resides.

Thermalization and MBL: Two Routes Through the Entanglement Spectrum

A disordered spin chain provides a particularly clear contrast. Neighboring spins interact, while each site experiences a random local field.

In the thermal regime, the system gradually thermalizes. Entanglement entropy grows rapidly, with an approximately linear regime. At the same time, the largest Schmidt weights progressively lose their dominance, and the dominant spectral window moves toward higher ranks.

Entanglement is not merely being generated. Its weight is being redistributed toward increasingly complex Schmidt scales.

The many-body localized (MBL) regime tells a different story.

Interactions still generate entanglement, and the entanglement entropy can continue to grow logarithmically. Higher-rank Schmidt components continue to appear as well. Yet the dominant spectral weight can remain pinned near the head of the spectrum, without undergoing the same shift toward higher rank scales.

This is something entanglement entropy alone cannot reveal.

Thermal and MBL systems can both exhibit entanglement growth, but the internal dynamics of their spectra can be fundamentally different. In particular, the generation of more entanglement and the transport of dominant weight across Schmidt scales can become decoupled.

Figure: Dynamics of different entanglement-related quantities in thermal and many-body-localized systems

One Spectrum, Four Clocks

The Schmidt-scale coordinate is only one way to look inside the spectrum. The shape of the spectrum is changing as well.

Anti-flatness measures how uneven the Schmidt weights are. It vanishes when all nonzero Schmidt weights are equal, and becomes large when a few large weights coexist with many much smaller ones.

Starting from a product state, there is initially only one nonzero Schmidt weight, so the anti-flatness is zero. As the system evolves, new Schmidt components appear, but they are highly unequal in magnitude. The spectrum therefore becomes increasingly uneven.

Later, as weight spreads across more and more components, the distribution begins to flatten again. Anti-flatness consequently develops a pronounced intermediate-time peak—a temporary barrier in the dynamics.

There is another quantity that follows its own clock: magic.

Magic is a resource-theoretic notion in quantum computation. Certain highly entangled states—stabilizer states, for example—can nevertheless be simulated efficiently on a classical computer. Nonlocal magic quantifies how far the evolving entanglement structure departs from this efficiently simulable stabilizer description.

Its dynamics can develop an intermediate-time barrier of its own.

We can therefore place four characteristic events on the same time axis:

The entanglement clock: the peak in the entanglement-growth rate, around [figure];
The roughness clock: the peak of anti-flatness, around [figure];
The magic clock: the peak of the exact nonlocal magic, around [figure];
The shift clock: the point at which more than half of the samples have left the spectral head, around [figure].

The important point is their ordering.

Even after the entanglement-growth rate has peaked, the entanglement spectrum continues to reorganize. After the spectrum reaches its maximum roughness and nonlocal magic reaches its peak, the dominant spectral weight still takes additional time to migrate toward higher Schmidt scales.

This ordering remains robust across system sizes and disorder strengths. In the MBL regime, however, the fourth clock may simply never ring.

Figure: The ordering of the four dynamical clocks

Why Does the Shift Clock Ring Last?

The answer lies in the competition between the head and the tail of the Schmidt spectrum.

Imagine that the largest Schmidt weight sits at the head, while the remaining weight forms a long tail. As weight flows from the head into the tail, different measures respond at different thresholds.

When the tail carries roughly one quarter of the total weight, the contrast between the dominant head and the rest of the spectrum is strongest, producing the peak in spectral roughness.

As the tail approaches roughly half of the total weight, the nonlocal magic reaches its maximum.

Only when the tail grows sufficiently large—roughly beyond two thirds in the relevant spectral picture—can a higher-rank window overtake the original head and trigger the shift of the dominant Schmidt scale.

In this sense, the ordering of roughness → magic → shift is already encoded in the geometry of the spectrum itself.

The same ordering also appears in random quantum circuits, suggesting that these clocks are not merely a peculiarity of one particular spin-chain model, but may reflect a more general feature of entanglement-spectrum dynamics.

What Changes Is Not Just the Quantity We Measure, but the Question We Ask

Each observable answers a different question:

Entanglement entropy: How much entanglement is there?
Anti-flatness: How uneven is the Schmidt spectrum?
Nonlocal magic: How far has the entanglement structure moved away from a stabilizer description?
Schmidt-scale coordinate: At what rank scale does the dominant weight reside?

The point of introducing four clocks is not simply to add four more curves to a plot of entanglement entropy.

It is to separate processes that have traditionally been compressed into the single phrase “entanglement growth.”

Entanglement is generated.

The spectrum becomes rough.

Nonlocal magic reaches a barrier.

And eventually, the dominant weight shifts to a new Schmidt-rank scale.

Entanglement entropy is an extraordinarily useful number. Perhaps it has become too convenient: by reducing a complicated spectrum to a single scalar, it can make several distinct dynamical processes look like one.

Once we open the spectrum back up, a hidden set of gears becomes visible.

They do not all turn together.

And the dynamics of entanglement, it turns out, is not simply a story of getting more entangled. It is also a story of reorganization, redistribution, and changing scale.

References

Lv Zhang, Shi-Xin Zhang, Heng Fan, and Shuo Liu, Revealing Entanglement-Growth Mechanisms through the Magic Barrier, arXiv:2607.09875 (2026).

Shi-Xin Zhang, Shuo Liu, and Yu-Qin Chen, Entanglement Growth as Transport Across Schmidt Scales, arXiv:2609.06643 (2026).

Goodbye to Manual Code Review: The Vibe Coding Experiment Behind TenCirPauli

Shixin Zhang — Wed, 26 Aug 2026 12:12:37 +0000

In the previous article, we discussed why we started TenCirPauli and why we chose its technology stack. Many structured tasks in quantum operator processing involve dynamic data structures, discrete computations, and variable-length results. Providing a high-performance, Rust-native runtime for these workloads is the product motivation behind TenCirPauli.

This article is about how it is developed.

TenCirPauli is an extreme experiment in software development: the implementation is delegated entirely to AI. The developer does not write—or even read—any line of code. The goal is to explore whether this new development paradigm can support a rigorous scientific computing software project at meaningful scale.

TensorCircuit-NG Still Uses the “Old-School” Approach

TensorCircuit-NG takes a relatively conservative approach to development.

When we encounter an issue or want to add a feature, we first work out the implementation strategy and then give the AI detailed instructions. After the AI makes the changes, a human reviews every modified file and essentially every significant addition or deletion, checking that the implementation follows the project's conventions and design principles.

For a mature project with years of history and a large user base, this approach may be necessary.

Such projects accumulate a large amount of implicit knowledge that is never fully documented: why an interface is named a certain way, what seemingly unnecessary branch exists for backward compatibility, which coding patterns are intentional, and which internal conventions should never be changed casually. This knowledge is scattered across source code, issues, historical behavior, and the experience of maintainers. It is extremely difficult for an AI to reconstruct all of that context reliably.

This development model has kept TensorCircuit-NG stable. It protects existing abstractions, semantics, and coding conventions, while preventing AI from introducing local workarounds simply to get a task done.

If we simply started “vibe coding” inside such a project, however, the result could be very different. Old implicit conventions would gradually be overwritten, while new conventions would not have enough time to stabilize. Interfaces and internal structures could quickly lose coherence.

That is why we chose a new project for this experiment.

A new project has no historical baggage to preserve. Public interfaces, internal boundaries, testing methodology, and Agent collaboration workflows can all be designed from day one—and, importantly, they can be developed according to the AI's own preferences rather than being constrained by decades of accumulated human conventions.

The Development Workflow

TenCirPauli has already grown far beyond the scale of a toy demonstration. The project now contains more than 80,000 lines of code, roughly half Python and half Rust.

That is large enough for interface design, module boundaries, performance, and maintainability issues to emerge naturally. It is also large enough to test whether this development model can actually scale.

In TenCirPauli, the developer's role is concentrated on goals, specifications, key architectural decisions, and acceptance criteria.

The workflow roughly looks like this:

A high-capability AI analyzes the goal and develops an initial Spec.
The human decides on key interfaces, semantics, and architectural trade-offs, and aligns them with the Spec.
A medium-capability AI implements the design.
A high-capability AI reviews the implementation and generates a Review Report.
The implementation AI fixes the identified issues.
Automated tests and benchmarks provide objective evidence.
The process is repeated as the project evolves.
Periodic global AI inspections scan the repository for accumulated problems.

In other words:

High-capability AI → formulate goals and write the Spec
↓
Human → decide key interfaces, semantics, and architectural trade-offs
↓
Medium-capability AI → implement the Spec
↓
High-capability AI → review the implementation and generate a Review Report
↓
Medium-capability AI → fix the issues

The division of labor is deliberate.

The high-capability model is responsible for understanding the problem, proposing solutions, and evaluating the result. The medium-capability model handles implementation and repairs. The human makes design trade-offs and keeps the overall system aligned. Automated infrastructure provides continuous evidence.

The Spec Is Where Human–AI Collaboration Matters Most

A Spec is much more than a feature checklist.

For a nontrivial scientific computing component, it needs to define the API surface and internal boundaries: invocation patterns, conceptual terminology, return values, data lifetimes, error types, the division of responsibilities between languages, performance and resource requirements, as well as independent reference implementations and benchmark-based acceptance criteria.

Writing the initial Spec is therefore the most human-intensive part of the entire workflow.

A high-capability AI can propose several interface designs, compare approaches used by existing libraries, and analyze complexity, resource consumption, language boundaries, and future extensibility.

The developer, meanwhile, keeps asking the more fundamental questions:

What does the user actually need?

Which abstraction should remain hidden?

Which performance trade-offs are worth making?

Which parts are over-engineering without a real use case?

Which design decisions will become painful once the project scales?

This process often takes many rounds of discussion. The goal is to keep challenging the design until the interfaces and the major implementation strategy can survive serious scrutiny.

Once the Spec is properly aligned, implementation becomes almost mechanical.

Even when a single change involves thousands—or tens of thousands—of lines of code, current AI systems can handle the actual implementation surprisingly well.

Mature Libraries Provide the Coordinates

It is remarkably cheap to generate software from scratch with AI. But mature software libraries still play an essential role.

TenCirPauli draws on projects such as QuSpin, OpenFermion, TensorCircuit-NG, PauliPropagation.jl, and QLDPC.

But what we primarily borrow from these projects is not their code or interface design.

We use them for two things:

established correctness references and measurable performance baselines.

Correctness references provide something against which a new implementation can be tested. Existing libraries, physical models, and published examples cover many cases that are difficult to derive correctly from scratch.

Performance baselines provide something equally important: a sense of scale.

Suppose a program is optimized from 10 seconds down to 1 second. That sounds like a spectacular 10× improvement. But if a mature library solves the same problem in 100 milliseconds, the program is still an order of magnitude too slow.

Without a baseline, it is difficult to know how fast a piece of scientific software should be, or whether an optimization is actually attacking the important bottleneck.

TenCirPauli has been developed within this coordinate system.

Different mature frameworks provide correctness and performance references for different classes of workloads. TenCirPauli then uses tireless AI-driven optimization to push the implementation far beyond those baselines.

The project's performance pages and research examples record these comparisons.

What is perhaps most surprising is that even medium-capability AI models can now outperform many mature scientific software implementations across a surprisingly broad range of workloads.

Tests, Benchmarks, and Global Repository Inspections

Once human code review is removed, tests and benchmarks become the core mechanisms of quality control.

They need to continuously answer several questions:

Is the result correct across different scales, boundary cases, representative workloads, and independent references?
Is the public API correct, including parameters, return values, error types, failure timing, and deterministic behavior?
Does the benchmark represent real user workloads, and does it distinguish one-time preparation costs from repeated execution?
Has a modification introduced a regression in correctness or performance?

A single AI Review primarily examines the current changes and their alignment with the Spec. It cannot reliably detect every problem that accumulates across an entire repository.

That is why TenCirPauli also performs periodic global AI inspections.

Each inspection focuses on a clearly defined set of questions and rescans the repository from a different perspective. It can search for hidden bugs and boundary-condition failures, identify performance bottlenecks, remove dead code and duplicated implementations, and clean up accumulated technical debt.

A single review handles the changes in front of us.

A global inspection handles the entropy accumulated over time.

Together, these two rhythms help keep the project in a low-entropy state.

Will AI Make Mistakes?

Of course.

The repository may still contain hidden performance inefficiencies, subtle bugs that are difficult to trigger, or layers of redundant code that accumulated over time.

These problems are difficult to eliminate completely. But human-reviewed code has exactly the same problem—and often a worse one.

The meaningful engineering question is therefore not whether every line of code is perfect.

The question is whether the main execution paths have sufficiently strong correctness tests and performance baselines.

If the important paths consistently produce correct results and complete within a reasonable amount of time, the software has a solid foundation for real-world use.

As the old saying goes: if it walks like a duck and quacks like a duck, it is a duck.

Users ultimately care about whether the software produces the right answer, does so within a reasonable amount of time, and integrates reliably into their workflow.

The User Is an Agent

TenCirPauli can of course be used directly by humans. It provides Python APIs, documentation, examples, and integration with TensorCircuit-NG.

But from the beginning, its more important user has been the Agent.

This changes some of the traditional trade-offs in software abstraction.

For performance and deterministic execution, an internal implementation may deliberately sacrifice some generality. It can retain specialized low-level implementations while exposing programmable layers of abstraction above them.

The result is not necessarily the most elegant abstraction for a human programmer.

It can instead be a much more flexible substrate for an Agent to call, compose, and optimize.

Maintainability Can Also Be Agent-Driven

A common criticism of software is:

“It works, but the codebase is a mess.”

That criticism is based on an implicit assumption: the future maintainer will be a human who needs to understand the source code before modifying it.

That assumption is changing.

TenCirPauli is maintained by Agents as well.

As long as the project has clear Specs, accumulated context, sufficiently strong tests, performance records, and real integration cases, an Agent can be instructed to locate a problem, propose a modification, implement it, and verify the result.

As long as Agents can continue to perform those maintenance operations reliably, the maintainability of the project remains under control.

This suggests a new form of implementation agnosticism:

First, ask whether the user-facing behavior works.

Then, ask whether the correctness and performance evidence remains stable.

Finally, ask whether an Agent can continue to modify and validate the system.

The source code itself becomes less important than the system of specifications, evidence, interfaces, and automated maintenance surrounding it.

Conclusion

TenCirPauli is both a performance sprint in Rust-based quantum software and an experiment in redefining the role of the developer.

It asks a deliberately extreme question:

Can rigorous scientific computing software be built without humans writing—or even reading—the code?

The answer so far is surprisingly close to yes.

More importantly, the experiment points toward something larger than TenCirPauli itself.

When AI can generate, review, test, benchmark, optimize, and maintain software, the developer's role moves upward—from implementing algorithms line by line to defining problems, designing abstractions, setting constraints, and building systems of evidence that continuously verify the result.

This is not simply a faster way to write software.

It may be the beginning of an irreversible shift in how software—and eventually scientific computing itself—is built.

When High-Level Abstractions Become the Bottleneck: Quantum Scientific Computing in the AI Era

Shixin Zhang — Sun, 16 Aug 2026 02:24:19 +0000

Choosing scientific software is choosing the space in which a team can think. In the AI era, a program is a computational object that Agents can inspect, compose, differentiate, compile, batch, optimize and move across hardware. The underlying infrastructure determines how much of that space remains available as the work evolves.

An advanced scientific stack keeps the mathematics visible while allowing execution to change. It preserves computational structure across representations, makes important decisions available for deliberate optimization and lets different scientific objects participate in the same program.

Quantum circuits, tensor networks, neural networks, Hamiltonians and other physical operators should have equal status inside the system. Their composition should be a native operation, so a team can continue developing the problem without repeatedly rebuilding its computational language.

TensorCircuit-NG is built around this idea. It is a unified scientific computing infrastructure for quantum physics and AI, with one tensor-native path through differentiation, compilation, acceleration and execution.

A framework is a theory of scientific work

Every framework encodes a theory of scientific work. It determines which representations are visible, where execution is fixed and how much of the computation a team can reshape when a problem crosses boundaries. Some frameworks organize work around a predetermined device or workflow. That pattern is efficient while the problem remains inside its original boundary. Quantum research crosses boundaries constantly:

exact simulation becomes approximate simulation or tensor-network contraction;
a circuit becomes part of a neural network or a many-body model;
a scalar expectation becomes a batched gradient or a distributed computation;
a local prototype becomes a GPU, multi-GPU or hardware workflow;
a standard circuit becomes a custom state, operator, noise model or evolution.

High-level encapsulation creates abstraction leakage at each transition. PennyLane’s device, QNode and transform pattern makes this visible: hidden representations surface as conversion overhead, fixed transformations become unsupported operations, and device assumptions constrain differentiation, batching and compilation. A clean entry interface can become a fixed research workflow, leaving the researcher to adapt the problem to the framework instead of keeping the computational structure open.

AI Agents make this boundary more consequential. Agents can explore low-level compositions and search for better execution plans through feedback. Their value depends on the space of valid compositions exposed by the infrastructure. A rigid workflow narrows that space; a composable substrate expands it.

TensorCircuit-NG keeps backend, dtype, JIT, differentiation, vectorization, contraction, slicing, state representation, memory strategy and device placement inside the programming model. Researchers and Agents can therefore work directly with the decisions that determine how a scientific program scales.

Quantum–AI scientific computing as one infrastructure

Quantum-AI research needs a shared computational language. TensorCircuit-NG gives quantum circuits, states, operators, Hamiltonians, tensor networks, neural networks and physical models equal status inside one tensor-native system.

This shared representation keeps scientific structure intact as a problem changes form. A circuit can become part of a neural model, a Hamiltonian can change representation without changing the surrounding calculation, and a differentiable program can move from local exploration to large-scale execution without being rebuilt around a new workflow.

This is the infrastructure required for quantum-AI research: quantum physics, machine learning and high-performance numerical computing operating inside one composable system.

Performance reveals the architecture

The architectural choice is measurable. Published TensorCircuit comparisons make the difference visible through direct performance ratios.

These results compare TensorCircuit with PennyLane-Lightning, PennyLane's fastest backend, and show a consistent lead across the reported CPU and GPU workloads.

For value-and-gradient evaluation of a one-dimensional TFIM objective, TensorCircuit was faster than PennyLane at every reported CPU and GPU point:

Circuit	CPU advantage	GPU advantage
10 qubits, 3 layers	15.6x	25.8x
16 qubits, 16 layers	4.0x	29.6x
22 qubits, 11 layers	5.3x	PennyLane OOM; TensorCircuit completed

For batched MNIST QML—binary 3-versus-6 classification with a 10-qubit, depth-3 circuit—TensorCircuit led at every reported batch size:

Batch size	CPU advantage	GPU advantage
32	82.9x	12.0x
128	105.2x	2.3x
512	103.5x	3.7x

The TensorCircuit-NG paper reports a 2.3x CPU advantage over the PennyLane baseline for 256 classical-shadow snapshots of a 20-qubit state. The same workload reaches the sub-second range on an RTX 5090 through the JAX tensor backend.

The distributed VQE results extend the scale: an eight-H200 system delivers a 7.5x strong-scaling improvement from one to eight GPUs, reaches 40 qubits and 20 layers, and differentiates a circuit with 11,700 trainable parameters.

The pattern is consistent across variational simulation, QML, structured Hamiltonians, classical shadows and distributed execution. The numbers measure more than speed: they show the value of keeping scientific representations, transformations and execution strategies open inside one composable tensor-native system.

The organization encoded in the stack

A scientific computing stack shapes the way a team thinks. When representations and execution decisions remain open, a team can move continuously between theory, experiment and production without repeatedly redesigning its computational language.

TensorCircuit-NG supports this mode of work across quantum physics, AI and HPC. The continuity changes the economics of exploration: more ideas can be tested, more optimizations remain available, and fewer research paths are closed by an early abstraction choice.

That is the meaning of an advanced production direction. The sophistication lies in the organization of the computing system: preserving structure, exposing decisions and keeping the route from discovery to scale open.

ORBIT-Q provides a corresponding Agent-oriented signal. In its reported framework comparison, TensorCircuit-NG achieved the highest solve success rate and the lowest artifact-runtime slowdown among the evaluated frameworks. The result reflects the same principle: an Agent performs better when the underlying scientific substrate is rich, coherent and open to optimization.

The default for advanced projects

Advanced projects should prioritize TensorCircuit-NG for quantum programming. Advanced organizations should build their quantum-AI scientific stack around TensorCircuit-NG.

Choosing a scientific stack is choosing what a team can keep open while it works. TensorCircuit-NG makes that openness a property of the architecture: the structure of a problem remains visible, the computational pieces remain composable, and execution strategies remain available for deliberate change as the research evolves. This is how a tool becomes part of an advanced organization's way of thinking rather than another workflow to conform to.

References

Tensor Networks Do Not Mean Approximate Simulation: The Right Way to Understand TensorCircuit-NG

Shixin Zhang — Tue, 11 Aug 2026 09:09:10 +0000

When introducing TensorCircuit-NG, people often ask: Is it mainly suited to low-entanglement states? Is it essentially a matrix product state (MPS) simulator? Since it uses tensor networks, are its results approximate?

These questions are easy to ask because many people are first introduced to tensor networks through MPS; in practical MPS applications, SVD truncation is also very common. As a result, MPS, tensor networks, and approximate simulation gradually become conflated.

The correct picture of TensorCircuit-NG is that it provides multiple modes for quantum circuit simulation. The most commonly used Circuit and DMCircuit can perform exact contractions of complete circuit tensor networks, producing exact results consistent with state-vector or density-matrix simulators. MPSCircuit, meanwhile, is a dedicated MPS simulator: it can use truncation to control the computational cost, or remain exact when no truncation is applied.

Therefore, tensor networks do not necessarily imply approximation, nor do they necessarily imply the use of MPS. To understand TensorCircuit-NG, the most important thing is to distinguish the core data structures, exactness, and use cases behind its different simulation modes:

Simulation mode	Core data structure	Exact?	Typical use cases
`Circuit`	Complete circuit tensor network	Yes	Full amplitudes, local observables, arbitrary circuits
`DMCircuit`	Complete density-matrix tensor network	Yes	Open systems, noisy quantum evolution
`MPSCircuit`	Matrix product state (MPS)	Optional (depending on whether truncation is used)	One-dimensional local circuits, low-entanglement systems

Tensor Networks Are Not an Approximation Algorithm

The most important concept here is that a tensor network is first and foremost a way to represent and compute with a problem, not an approximation algorithm.

The initial state, quantum gates, and measurement operators in a quantum circuit can all be represented as tensors. Connecting these objects according to the circuit structure produces a tensor network.

The next step is to contract these tensors one by one according to some chosen order. This process can itself be exact, just like matrix multiplication; it does not inherently involve any approximation.

Approximation usually comes from additional compression operations. For example, to limit the size of intermediate tensors, one may discard some of the smaller singular values or limit the dimensions of internal connections. This is an optional computational strategy, not part of the definition of tensor networks.

In other words, “tensor networks” and “truncation” are two separate issues. The former describes how a computation is organized, while the latter describes whether the computation is actively compressed.

`Circuit` in TensorCircuit-NG: Exact Contraction of Complete Circuits

The most commonly used Circuit in TensorCircuit-NG is not an approximate simulator designed for low-entanglement states.

It organizes the initial state and quantum gates into a complete circuit tensor network, and then contracts the network according to the specific task. Users can compute the complete output state, or directly compute amplitudes, probabilities, expectation values, and other observables.

In this process, TensorCircuit-NG does not perform a low-rank approximation, and its results match those of a traditional state-vector simulator exactly.

This leads to an important distinction: a traditional state-vector simulator often explicitly stores the entire quantum state as a large vector and repeatedly updates it. Tensor-network simulation, by contrast, can preserve the circuit structure, choose a suitable contraction order, and compute the target quantity only when it is actually needed. If the user wants the complete output wavefunction, they ultimately still have to deal with the scale of the complete output itself. However, if the user only cares about a local observable or needs just a small number of amplitudes and probabilities, tensor networks may avoid generating a large number of irrelevant intermediate results.

Therefore, the advantage of TensorCircuit-NG is not “trading accuracy for speed,” but “improving efficiency through more flexible computational organization.”

Compared with State-Vector Simulators, Where Does the Speedup Come From?

If we view a traditional state-vector simulator as a fixed, global tensor-contraction scheme, it typically maintains the complete quantum state explicitly and applies quantum gates in a relatively fixed order. TensorCircuit-NG instead formulates the same problem as a tensor network and searches for a more suitable contraction path based on the topology of that network.

The key to performance is finding a better computational order. A better contraction path can often significantly reduce the size of intermediate tensors, memory usage, and total computational cost; for some problems, the speedup can even reach several orders of magnitude.

This means that the core advantage of TensorCircuit-NG is not a trade-off between accuracy and efficiency, as one might easily assume. The results from Circuit match those of a state-vector simulator exactly, and the results from DMCircuit match those of a complete density-matrix simulator exactly, while using less memory and achieving higher throughput.

From this perspective, compared with traditional state-vector simulators, TensorCircuit-NG offers a “free lunch”: unchanged accuracy, a consistent programming interface, and significantly better time and space efficiency.

`DMCircuit`: Complete Density-Matrix Simulation Based on Tensor Networks

DMCircuit follows the same philosophy. TensorCircuit-NG’s DMCircuit describes quantum systems directly at the density-matrix level. Quantum gates, noise channels, and measurement processes are all incorporated into a complete density-matrix tensor network, which is then evaluated through exact contraction.

Therefore, DMCircuit does not mean that some low-rank approximation is applied to noise, nor does it default to sampling only a few trajectories. It performs a complete simulation of mixed-state evolution. This naturally incurs higher computational and storage costs than pure-state simulation, but those costs correspond to a more complete physical description.

This is also why the claim that “TensorCircuit-NG is only suitable for low-entanglement pure states” is a misconception. It can readily handle complete density matrices and open-system evolution.

MPS Is One Special Form of Tensor Network

So, what exactly is MPSCircuit?

An MPS, or matrix product state, is a special tensor-network structure. Each qubit position is represented by a local tensor, and neighboring positions are connected through internal bonds. This structure is particularly well suited to one-dimensional local circuits and low-entanglement states, and an MPS can represent the corresponding quantum state using far fewer resources than a complete state vector.

However, an MPS does not inherently mean approximation either.

In principle, any finite-size quantum state can be represented exactly as an MPS; the required internal bond dimension may simply be very large. During MPS evolution, retaining all the information makes it possible to obtain exact results. Approximation errors from SVD truncation arise only when the size of the internal bonds is actively limited.

Therefore, MPSCircuit can be either an approximate simulator or an exact simulator. The key question is whether truncation is performed, not simply whether the simulator is based on MPS.

The source of confusion is that, in large-scale computations, people often use MPS truncation because it is an effective way to control computational cost. Over time, many people come to mistake this commonly used truncated-MPS approach for the essence of MPS, and then go one step further and assume that all tensor-network simulation methods are approximate.

Beyond the Three Main Modes: More Native Simulators

The Circuit, DMCircuit, and MPSCircuit introduced above are three important examples for understanding the simulation philosophy of TensorCircuit-NG, but they are not the whole story.

Another core design principle of TensorCircuit-NG is to choose a more native and efficient data structure based on the specific structure of the quantum system and circuit, rather than forcing every problem to use the same general-purpose representation. Different physical models and circuit types often have a simulator that is best suited to them.

For example, QuditCircuit targets qudit systems whose local dimension is greater than two; StabilizerCircuit targets Clifford and stabilizer circuits, using the stabilizer formalism to represent and evolve quantum states; FGSSimulator targets fermionic Gaussian states and exploits the structure of correlation matrices; and U1Circuit targets circuits with symmetries, working directly in the particle-number-conserving subspace.

What these simulators have in common is that they do not reduce every problem to explicitly storing a complete wavefunction. For circuits with special structure, using the corresponding native representation can greatly reduce unnecessary computational and memory costs while preserving exactness.

Therefore, the right way to understand TensorCircuit-NG is not to begin by asking whether it is an approximate MPS simulator. Instead, ask: What structure does the current problem have? Should we use a complete circuit tensor network, a complete density matrix, an MPS, or a specialized representation such as stabilizers or fermionic Gaussian states?

If one concludes that TensorCircuit-NG “is only suitable for low-entanglement states” or “can only perform approximate simulation” simply because it uses tensor networks, one is actually mistaking one common use case for the operating principles of the entire framework.

In summary, tensor networks are a computational framework, MPS are a special structure, and truncation is an optional strategy. The core advantage of TensorCircuit-NG is to make its data structures fit the problem as closely as possible: where generality is needed, it performs complete and exact tensor-network contractions; where special structure exists, it uses more native, specialized simulators. By choosing a more suitable representation for each scenario, it can provide both greater efficiency and equally rigorous results.

Why I Developed TenCirPauli

Shixin Zhang — Mon, 10 Aug 2026 16:12:47 +0000

A technical note from the author of TensorCircuit-NG.

TensorCircuit-NG is already a very capable framework. I built it to make quantum-circuit programming expressive, differentiable, and practical across several numerical backends. It gives users a clean circuit frontend, a flexible backend abstraction, automatic differentiation, JIT compilation, and access to the tensor-network and accelerator ecosystems. For regular tensor programs, these choices work extremely well. They let a researcher describe a circuit at a high level and still obtain compiled numerical execution underneath.

Many of the workflows I care about fit this model beautifully. State preparation, parameterized gates, expectation values, dense tensor contractions, and repeated optimization steps all benefit from JAX's transformation system. Once a program has been traced and compiled, its steady-state execution can be remarkably fast. TensorCircuit-NG has become strong precisely because it takes this model seriously instead of hiding the backend behind a collection of unrelated special cases.

TenCirPauli grew out of the next question: what happens when a quantum workflow contains a substantial amount of computation that does not look like a regular tensor program? The answer exposed a useful boundary in TensorCircuit-NG. The framework is very good at the numerical work for which JAX was chosen. Some of the surrounding operator work has a different computational character, and that character deserves a different runtime.

Framework selection creates a performance profile

TensorCircuit-NG's high-performance path is closely connected to JAX. This brings major advantages and makes JAX's preferred workload shape visible in TensorCircuit workflows. Every runtime has such a shape, and performance depends on how closely a problem matches it.

JAX is strongest when a computation can be expressed as a regular array program. Dense linear algebra, large matrix and vector operations, batching, automatic differentiation, and accelerator execution are all natural targets. XLA can trace the program, optimize it, fuse operations, and produce a fast executable. For a dense matrix multiplication or another BLAS/LAPACK-class kernel, moving the operation into Rust usually changes very little. Rust will call the same optimized numerical libraries, while JAX may have additional opportunities for fusion, compilation, or execution on a GPU or TPU.

This gives the first design principle for TenCirPauli: dense numerical work should stay close to the TensorCircuit-NG backend, while irregular surrounding work can use a native systems language.

Where the JAX model becomes expensive

The first difficulty is dynamic shape. A Pauli propagation recurrence can create new words, merge equal words, cancel terms, and move contributions between weight sectors. Symmetry analysis, mappings, and grouping can likewise produce variable numbers of basis states, terms, transitions, groups, or constraints.

JAX can express these algorithms, yet the natural representation often conflicts with its compilation model. A dynamic algorithm consequently needs padding, masking, sorting, bounded buffers, static limits, or custom control-flow encoding. These techniques can be valuable for a carefully designed workload, while adding representation work and potentially changing the algorithm's semantics.

The second difficulty is compilation latency. JIT compilation can produce an extremely fast steady-state kernel, while the first call carries tracing, lowering, optimization, and executable creation. This is a good trade for long-running workloads with many repeated calls; it is less attractive for short jobs or frequently changing structures.

JAX can avoid this cost very effectively when the workflow has a stable shape. Hamiltonian coefficients, circuit angles, and other numerical inputs can live inside one parameterized compiled function, allowing broad scans to reuse the same executable. TensorCircuit-NG handles this style of work extremely well. The compilation boundary becomes important when term counts, Pauli supports, circuit control flow, sector dimensions, grouping results, or propagated-operator shapes change. Each new structure may require a new trace or a more elaborate static encoding, so separating setup, first execution, and steady execution helps identify where a native complementary path is useful.

The third difficulty is a workload dominated by bit strings and bit manipulation. Pauli words, occupation states, symmetry generators, basis indices, and transition keys can all be represented as packed integers. Their operations include XOR, parity, masks, shifts, comparisons, hash lookups, and small logical branches; the computation is controlled by the bits themselves more than by dense floating-point arithmetic.

JAX supports bitwise operations, loops, and integer arrays. A single XOR does not become faster simply because it is written in Rust. The opportunity appears in the complete workload: millions of small operations, changing output sizes, duplicate-key aggregation, branch-heavy recurrences, and data structures that do not map cleanly to a dense rectangular array. A Python fallback exposes interpreter overhead, while a tensor encoding can introduce padding, sorting, masking, recompilation, or extra preparation.

These cases reveal a specific type of gap. TensorCircuit-NG has a powerful numerical engine, while some operator workflows need a compact control-oriented engine for irregular discrete computation. That gap is where a Rust companion can create real value.

Why Rust is a useful complement

Rust's scientific-computing ecosystem is smaller than Python's, and its linear-algebra stack is less mature. That is acceptable for this design because dense matrix multiplication, eigensolvers, tensor contractions, and accelerator kernels already have mature homes in the Python and JAX ecosystems. TenCirPauli gains little by rebuilding those foundations.

Rust has a different set of advantages. It compiles ordinary loops and branches to native code, gives direct control over memory and integer representations, handles dynamic collections without Python object overhead, and makes packed-data algorithms natural to express. Hash maps, bit masks, transition tables, and variable-length work queues fit this runtime well. The core can release the Python GIL while processing a complete batch, so the Python boundary stays outside the hot loop.

The complement can be summarized as follows:

Workload characteristic	JAX / TensorCircuit-NG	Rust / TenCirPauli
Dense matrix and tensor arithmetic	Strong fit	Usually delegates to established numerical libraries
Regular batching and static array programs	Strong fit	Capable, with less ecosystem leverage
Automatic differentiation through numerical code	Strong fit	Explicit local derivative rules where needed
Dynamic term counts and variable shapes	Requires encoding for compilation	Natural control flow and dynamic storage
Hash-based aggregation and graph-like analysis	Possible, often awkward inside traced arrays	Direct and compact
Packed integers, bit strings, parity, masks	Expressible, with limited advantage from tensorization	Natural inner-loop representation
Long-running accelerator workloads	Strong fit	Usually the wrong execution target
Short or frequently changing workloads	Compilation cost can dominate	Native setup can remain small and predictable

This division of labor is the starting point for TenCirPauli. It also explains why the project is designed as a companion to TensorCircuit-NG. The two runtimes can cooperate on one scientific workflow, with each one handling the part of the program that matches its performance profile.

What this implies for Pauli computation

Pauli algebra is a particularly clear example of the boundary. A Hamiltonian may be written as

H = c₀ P₀ + c₁ P₁ + ··· + cₘ Pₘ,

and the eventual numerical task may be an expectation value or a gradient. Between those points, the program may combine equal words, track phases, compute commutation relations, construct measurement groups, discover symmetries, restrict a physical sector, map fermions, and propagate observables through circuits.

These operations are symbolic and discrete, dominated by compact keys, parity, support inspection, branching, aggregation, and variable-size results. The final state-vector or tensor-network calculation may still be dense and backend-friendly. Pauli-heavy workflows therefore benefit from native preparation and transformation followed by a regular TensorCircuit-NG or JAX numerical plan when appropriate.

That makes Pauli computation a natural Rust target. Packed X/Z data, phase bookkeeping, parity checks, aggregation, and variable-size collections all fit native integer loops and compact data structures. From this workload, the surrounding capabilities follow naturally: the same native machinery can support Pauli algebra, measurement grouping, symmetry analysis, compilation, and observable propagation.

The functionality follows from the runtime choice

The design of TenCirPauli's public API follows directly from this framework analysis. The matrix is one useful destination for a small system. Larger workflows need algebraic transformations, measurement plans, reduced bases, matrix-free actions, observable trajectories, or differentiable circuit objectives. The architecture preserves the operator across those stages.

The resulting workflow can be viewed as a sequence of transformations:

structured model → canonical operator → algebra and analysis → reduction or mapping → execution plan → measurement or gradient

Each arrow has a different computational profile: symbolic expansion, canonicalization, bit-packed keys, graph analysis, and integer indexing at the front; dense state tensors, backend autodiff, sparse linear algebra, or native CPU kernels at the end. The representation must cross this boundary without losing its meaning.

From physical models to canonical operators

Pauli operators are the central representation for qubit Hamiltonians, observables, and propagation. TenCirPauli extends the same native approach to fermionic, bosonic, qudit-Weyl, Majorana, and hybrid operators. Jordan–Wigner, parity, and Bravyi–Kitaev mappings transform structured terms into Pauli form, while optional chemistry adapters bring molecular Hamiltonians into the same pipeline. Canonical aggregation, explicit phase handling, deterministic ordering, and compact keys give every later capability one stable operator.

From operators to measurements and structural information

Measurement planning is an analysis stage. A qubit-wise commuting grouping uses Pauli supports and local bases, so its useful result contains more than a partition of term indices. It also describes the basis rotations and the reconstruction of Pauli eigenvalues from rotated computational-basis samples. The grouping result can therefore travel from symbolic preprocessing to experimental post-processing without a second interpretation layer.

Symmetry analysis follows the same pattern. Z₂ generators, tapering sectors, fixed-particle-number spaces, and general additive-charge restrictions use bit operations, constraint solving, basis indexing, and leakage checks. They can reduce the computational object before a circuit, sparse matrix, or matrix-free plan is executed. For a 60-qubit, two-particle system, the relevant sector contains choose(60, 2) = 1,770 basis states, compared with 2**60 states in the full computational space. This is a structural reduction that comes before numerical optimization.

From one operator to several execution targets

Compilation chooses the endpoint that matches the next consumer: dense, COO, CSR, SciPy linear operator, Rust-native matrix-vector product, or a pure-array TensorCircuit-NG/JAX backend plan. For large systems the useful result may be a reusable MVP plan that never materializes the full matrix; for a restricted sector it may be a compact transition plan over the physical basis. Rust prepares the fixed structure before backend tracing, and the public API keeps the target choice explicit.

From circuits to observable execution and gradients

The same boundary applies when the operator meets a circuit. A fixed-particle-number circuit can execute directly in a restricted basis. A Pauli observable can propagate backwards through a circuit using dynamic native storage, with terms expanded, merged, cancelled, and projected by weight. A stochastic Pauli-path estimator can use the same operator semantics with an explicit sampling contract. Native value-and-gradient paths use local derivative and vector-Jacobian rules for supported gates, while TensorCircuit-NG and JAX remain available when the objective belongs inside a backend-traced tensor program.

The user-facing interface remains entirely in Python. Users construct operators, pass them to grouping or compilation APIs, connect them to TensorCircuit-NG circuits and backends, and receive ordinary Python objects, NumPy arrays, or backend tensors. They do not need to write Rust, manage FFI handles, or choose native data layouts. The workflow should feel as fluent as TensorCircuit-NG itself; Rust stays behind the boundary and handles the work that scales with terms, gates, groups, transitions, or basis states through coarse-grained native calls.

What the Early Benchmarks Show

The first benchmark suite provides evidence for this division of labor. The headline result comes from a representative 60-qubit, two-particle U(1) VQE: TenCirPauli's first compiled value-and-gradient call was about 688× faster than the corresponding TensorCircuit/JAX call, and the steady native path was about 2.6× faster. In a matched stochastic Pauli-path value-and-gradient workload, the native path was about 6.5–7.6× faster at 12 qubits and about 12.4× faster at 16 qubits in the recorded steady-state comparisons.

These results show where the architecture creates leverage. The first-call improvement reflects the cost of tracing and compilation, while the steady-state improvement reflects the benefit of native handling for irregular Pauli structure. A JAX implementation can still be the best choice after a long compilation has been amortized, and a Rust implementation becomes attractive when the workload changes shape frequently, contains heavy bit manipulation, or spends most of its time in symbolic preparation. The measurements separate native setup, first execution, steady execution, memory, and numerical agreement so that these cases remain visible.

Later technical posts will open up these comparisons and individual workloads in more detail. Here the benchmarks support one framework-level conclusion: runtime choice should follow the shape of the computation.

The larger lesson

TensorCircuit-NG solved an important problem by making tensor-based circuit computation expressive, differentiable, and backend-aware. Its JAX-centered design is a major part of that success. The same design makes dynamic, branch-heavy, shape-changing, and bit-string-heavy tasks stand out as a separate class of workload.

TenCirPauli extends TensorCircuit-NG around that boundary. It gives irregular Pauli workloads a native path while preserving TensorCircuit-NG's strengths for dense numerical computation, parameterized execution, automatic differentiation, and accelerated backends. The result is a complementary architecture: JAX handles regular numerical programs, Rust handles irregular Pauli structure, and Python connects the two into one scientific workflow.

That is why I developed TenCirPauli. The project began with a framework-selection question, and the Pauli algebra, measurement planning, symmetry tools, restricted sectors, propagation engines, and backend plans followed from the answer.

From Parameter Tuning to Cross-Paradigm Exploration: Quantum Control Enters the Era of “Autopilot”

Shixin Zhang — Tue, 21 Jul 2026 06:37:46 +0000

If you have ever tried to drive a high-performance race car on ice, you may understand the frustration researchers face when controlling quantum systems today.

In the grand vision of quantum computing, Quantum Optimal Control (QOC) serves as the steering wheel that guides quantum systems toward desired states. Whether in adiabatic quantum computation, quantum annealing, or quantum simulation, the fundamental challenge remains the same: designing time-dependent control protocols that drive a quantum system from a simple initial state to a complex target state with high fidelity.

However, real-world quantum control faces two fundamental obstacles.

On the hardware side, quantum systems are extremely fragile. Short coherence times, limited control channels, hardware-specific constraints, and strict pulse boundaries severely restrict the available control space.

On the algorithmic side, many-body Hamiltonians associated with practical problems often exhibit complicated spectral structures, including small energy gaps and rugged optimization landscapes. Finding an efficient evolution path within a limited time window remains highly challenging.

For decades, designing quantum control protocols has largely remained a human-driven, handcrafted process. Experts repeatedly design, simulate, and tune protocols for specific physical systems and hardware platforms through extensive trial and error.

A recent work introduces a fundamentally different approach: QOC-Workbench, an LLM-driven, fully auditable framework for cross-paradigm quantum control design. Rather than acting as another black-box optimizer, it functions more like an autopilot system for quantum control—transforming how control protocols are discovered, validated, and improved.

Reference:
LLM-Driven Cross-Paradigm Design for Quantum Optimal Control
Yu-Qin Chen and Shi-Xin Zhang, arXiv:2607.17498

Beyond Closed Optimization Spaces: How QOC-Workbench Works

Traditional quantum optimal control methods usually operate inside a predefined design space.

Researchers first choose a control ansatz—a mathematical form for pulse schedules, interpolation functions, or auxiliary Hamiltonians. Classical optimization algorithms then search for optimal parameters within that fixed structure.

This approach is powerful, but fundamentally limited.

If the initial design space is incomplete, optimization can only find the best solution within existing assumptions. It cannot invent new functional forms, discover alternative control mechanisms, or challenge the original modeling choices.

QOC-Workbench changes this paradigm by integrating:

large language models with scientific reasoning capabilities,
structured knowledge extracted from quantum control literature,
historical simulation results,
hardware constraints,
and high-performance quantum simulation infrastructure.

The workflow forms a closed-loop scientific discovery system:

1. Human experts define the physical boundary

Researchers specify:

target Hamiltonians,
hardware limitations,
physical constraints,
evaluation objectives.

Humans provide the scientific context and ensure physical validity.

2. LLM performs cross-paradigm exploration

Instead of only optimizing parameters, the LLM can:

propose new control schedule families,
modify the structure of auxiliary Hamiltonians,
combine ideas from different control paradigms,
generate executable simulation code.

The search space itself becomes dynamic.

3. Physics solvers provide rigorous validation

Candidate protocols are evaluated through differentiable quantum many-body simulations powered by high-performance quantum software infrastructure such as TensorCircuit-NG.

The system does not rely on language-model judgment alone—the generated ideas must survive quantitative physical evaluation.

4. Memory engine turns experiments into reusable knowledge

Every successful or failed experiment is automatically recorded as structured knowledge.

Over time, the system accumulates reusable design principles, allowing previous discoveries to influence future exploration.

Through this process, AI evolves from a parameter fitting tool into a continuously improving scientific assistant.

Three Levels of Evolution: From Pulse Shaping to Neural Control Generators

To demonstrate the capability of QOC-Workbench, the authors tested it across three increasingly challenging physical scenarios.

These examples illustrate a gradual transition:

from optimizing existing protocols → modifying physical pathways → discovering new computational paradigms.

Case 1: Designing Hardware-Compatible Control Pulses

Rydberg Atom Arrays

The first challenge considers solving the Maximum Independent Set problem using Rydberg atom arrays.

Real quantum hardware imposes strict constraints on available control signals. Traditional approaches often rely on analytical counterdiabatic protocols derived from simplified models.

However, these idealized solutions may not fully capture the complexity of interacting many-body systems.

QOC-Workbench analyzed the limitations of existing approaches and explored a broader control space.

Instead of simply tuning parameters of known pulses, it discovered a new pulse structure:

the “smooth beta-bump” envelope.

The generated protocol:

satisfies realistic hardware constraints,
preserves smooth control behavior,
achieves higher ground-state fidelity than classical analytical baselines in many-body simulations.

This demonstrates that LLM-driven exploration can redesign control waveforms rather than merely optimize them.

Case 2: Redesigning Many-Body Evolution Paths

XXZ Spin Chains

The second example moves beyond pulse engineering.

For XXZ spin chains with complex spectral structures, QOC-Workbench explored the structure of the entire evolution trajectory.

The system introduced:

a target catalyst Hamiltonian that asymptotically vanishes at the endpoints,
jointly optimized approximate counterdiabatic corrections,
nonlinear time schedules combining polynomial and sinusoidal deformations.

The key insight was that optimal control is not only about adjusting individual parameters.

The geometry of the evolution path itself can be redesigned.

By jointly optimizing the Hamiltonian pathway and correction terms, the system discovered improved protocols that would be difficult to obtain through conventional parameter optimization alone.

Case 3: Breaking the Scaling Barrier with Neural Generators

2D Random-Field Ising Models

The third case reveals the most significant conceptual shift.

For disordered many-body systems, optimizing a control protocol separately for every instance quickly becomes computationally expensive.

QOC-Workbench identified this bottleneck and changed the problem formulation.

Instead of searching for an optimal protocol instance by instance, it designed and trained a graph neural network (GNN) generator.

The generator was trained only on small-scale graph instances but successfully generalized to larger unseen systems.

It could:

accurately predict control coefficients,
generate reasonable evolution paths,
bypass expensive per-instance variational optimization.

This represents a transition from:

“optimize every problem separately”

to:

“learn the underlying structure of the solution space.”

Conclusion: Let Physicists Return to Physics

QOC-Workbench is not designed to replace human scientific intuition.

Instead, it aims to amplify it.

In this emerging human-AI collaboration paradigm, researchers no longer need to spend most of their time on:

manual parameter tuning,
repetitive protocol benchmarking,
low-level implementation details.

Instead, they can focus on:

understanding fundamental physical mechanisms,
defining meaningful physical constraints,
interpreting machine-discovered protocols,
extracting new scientific principles.

Human insights then become new knowledge injected back into the system, creating a continuous feedback loop between human reasoning and machine exploration.

From manually crafting isolated interpolation curves to building a continuously evolving, auditable, and transferable knowledge system, quantum control is moving beyond fixed optimization frameworks.

The future of quantum control may not be about finding better parameters inside predefined spaces.

It may be about building intelligent systems capable of discovering entirely new control paradigms.

Quantum control is entering the era of autopilot.

Training a 1,000-Qubit, 40,000-Parameter Quantum Algorithm with Full Gradients Using TensorCircuit-NG

Shixin Zhang — Sat, 18 Jul 2026 02:47:36 +0000

Introduction

If you wanted to simulate 1,000 quantum qubits and compute exact full gradients for 40,000 parameters on a classical computer, how much compute power would you need?

For a 1,000-qubit, 10-layer circuit, calculating a single state amplitude might have a manageable computational overhead. However, when you attempt to solve the system's Variational Quantum Eigensolver (VQE) and compute all of its parameter gradients, the difficulty skyrockets. At first glance, this sounds like a job that strictly requires a supercomputing cluster.

The underlying reasons for this explosion in complexity are twofold:

The Introduction of the Hamiltonian: Computing the VQE expectation value requires evaluating $E(\boldsymbol\theta)=\langle\psi(\boldsymbol\theta)\vert H\vert\psi(\boldsymbol\theta)\rangle$. This transforms the tensor network from a single-sided state contraction into a "bra-MPO-ket" three-layer sandwich structure, immediately more than doubling the graph size.
The Memory Wall in Backpropagation: Deriving gradients for tens of thousands of parameters requires backpropagation. To compute these gradients in a contraction graph, the compiler has to keep massive amounts of intermediate results from the forward pass in VRAM. This is vastly more difficult—and puts far more pressure on memory—than a simple forward contraction or amplitude calculation.

In this technical blog, we'll demonstrate how we cut the per-step execution time of a 1,000-qubit VQE down to just 1 second on a single NVIDIA RTX 6000D GPU. We achieve this by exploring three different physics- and engineering-driven contraction strategies, all without sacrificing exact gradient precision.

Performance Comparison: Three Physical Perspectives

We use a 1D Transverse Field Ising Model (TFIM) with open boundary conditions as our benchmark. Each layer of the circuit applies diagonal entangling gates sequentially to adjacent pairs $(0,1),(1,2),\ldots,(n-2,n-1)$ along the qubit chain:

$$R_{ZZ}(\theta)=\exp(-i\theta Z\otimes Z/2)$$

Followed by single-qubit rotations. The TFIM Hamiltonian is:

$$H_{\rm TFIM}=\sum_{i=0}^{n-2}X_iX_{i+1}+\sum_{i=0}^{n-1}Z_i$$

We can also represent this Hamiltonian as an exact and compact Matrix Product Operator (MPO, with a Bond Dimension of 3).

The table below shows the benchmark results for three different contraction modes (using an NVIDIA RTX 6000D at complex64 precision):

Perspective (Algorithm Mode)	Initial Compilation	First Full Gradient	Steady-State Full Gradient	Peak VRAM	Applicability & Value
Global Contraction Tree	5 h 20 min	5.88 s	1.09 s	51.97 GB	Directly contracts the full bra-MPO-ket graph; useful for full-graph compute and cross-benchmarking.
Local Causal Sliding Window	10.79 s	148.68 s	148.36 s	8.86 GB	Relies on strict causal cones of fixed width for local terms; terms can be dispatched independently.
Local Window (8-GPU Parallel)	10.50–11.28 s / GPU	19.72–20.50 s	18.71 s	8.86 GB / GPU	Dispatches 125 local terms per GPU; yielded a measured 7.93× speedup.
Spatial Transfer Matrix (B3)	6.367 s	1.328 s	1.054 s	8.62 GB	Leverages repeating 1D spatial structures.
Spatial Transfer Matrix (B5)	7.375 s	1.320 s	1.133 s	5.44 GB	A lower-VRAM variant of the same exact STM algorithm.

These approaches complement one another:

The Global Tree delivers excellent steady-state execution time (1.09s) but suffers from a brutal 5+ hour cold compilation time and massive 52 GB peak VRAM usage.
The Local Window approach crushes compile time down to ~10 seconds, but redundantly computes the shared environments of adjacent local terms, making single-GPU execution sluggish.
The Spatial Transfer Matrix (STM) successfully decouples compilation costs from the system length by explicitly passing the repetitive 1D spatial structure to jax.lax.scan, perfectly balancing compilation and execution efficiency.

Contraction Path Metrics: FLOPs, Max Tensor, and Write

In tensor network contraction, path quality is defined by several resource metrics:

FLOPs (Floating Point Operations): The total number of scalar multiply-add operations required for the path. For example, log10 FLOPs = 12.0 means roughly $10^{12}$ scalar ops.
Max Tensor Size (Width $w$): The number of elements in the largest intermediate tensor generated during contraction. It directly dictates the instantaneous VRAM pressure during the forward pass. (If all indices have a dimension of 2, width $w$ corresponds to $2^w$ elements).
Total Write: The total number of elements written out across all intermediate tensors. During backpropagation, all of these written tensors must be retained in memory as residuals to compute gradients.

When calculating expectations and gradients simultaneously, you must keep an eye on all three metrics. Ultimately, however, empirical compile time, execution time, and peak GPU VRAM are the ground truth.

Perspective 1: Global Contraction Tree — Brute-Forcing the Entire Graph

By calling value_and_grad directly on the complete bra-MPO-ket network, we can quantify the true cost of naive global contraction.

To make this feasible, we first alter the network representation. It is critical to write each $R_{ZZ}$ gate in an exact Rank-2 decomposed form:

$$R_{ZZ}(\theta)=\cos(\theta/2)I\otimes I-i\sin(\theta/2)Z\otimes Z$$

Maintaining the original left-to-right "ladder" gate ordering is also crucial. If we reorder the commuting $R_{ZZ}$ gates into an alternating even/odd bond "brick-wall" structure, we destroy the elimination path. The tensor network width instantly spikes to 39.585. Keeping the ladder ordering keeps the width at a manageable 23.585.

Using the omeco path search on this massive graph, we found a global contraction path with log10 FLOPs = 12.0466 and log2 write = 32.5912.

On a single RTX 6000D, post-compilation gradient execution takes only 1.09s, peaking at 51 GB of VRAM. This proves that full-graph VQE gradients can technically be run on a single card, but the bottlenecks are purely the global HLO compilation time and the memory needed to store backward residuals.

omeco vs. cotengra: Two Path-Search Frameworks

Since the global graph's resource bottleneck lies heavily in contraction path search and compilation, how do top-tier tools fare? We compared two frameworks—omeco and cotengra—on this massive tensor network.

omeco (Rust-based) uses a TreeSA algorithm to perform intense simulated annealing in tree space. It is excellent for quickly finding high-quality un-sliced seed trees on large graphs.
cotengra offers richer interfaces for manipulating and fine-tuning contraction trees, such as reconfiguring subtrees based on existing paths or performing granular slice-index searches on a fixed tree.

We ran a controlled search comparison on a 100-qubit, 10-layer TFIM graph (6,460 tensors, 8,441 indices):

Search Method & Budget	Search Time	log10 FLOPs	log2 Max Tensor	log2 Total Write	Notes
`omeco` TreeSA (16 trials × 64 steps)	15.68 s	11.068	24.585	29.517	16 independent SA trials
`cotengra` CMA-ES (8 hyperparam candidates)	37.59 s	12.901	31.585	35.646	8 sets of search params
`cotengra` SA (12 steps × 12 reconfigs)	9.22 s	11.827	29.585	34.014	Low-budget SA
`cotengra` SA (24 steps × 24 reconfigs)	34.09 s	10.873	23.585	30.367	Higher-budget SA

The data shows that omeco TreeSA ran significantly more annealing steps in less time and returned lower-complexity trees, outperforming the alternatives for this un-sliced scenario. However, for scenarios requiring deep slicing, neither framework is currently ideal.

The Efficiency Limits of Slicing

When VRAM is tight, slicing the contraction tree is a necessary evil to keep memory footprints in check. But if you have enough VRAM for an un-sliced path, forcing a slice to distribute across multiple GPUs does not scale efficiency linearly.

Fundamentally, slicing a tensor network means forcibly delaying the contraction of selected indices to the very end of the path. In an optimal, un-sliced path, these indices are eliminated early on, preventing intermediate tensors from blowing up in size. Slicing disrupts this optimal elimination order. It forces every sub-task to redundantly compute intermediate results that could have been shared before the final summation.

When we force-sliced the 1,000-qubit global path into 8, 32, and 128 tasks, the log2 write per slice barely dropped—from 32.5912 to 32.5632, 32.5491, and 32.5365 respectively. Because it failed to meaningfully dismantle the primary memory structure of the backward pass, while heavily deviating from the optimal contraction order, redundant computation skyrocketed. Total log10 FLOPs jumped from 12.0466 to 12.9420, 13.5391, and 14.1355.

Takeaway: If it fits in VRAM, using an un-sliced path usually maximizes hardware utilization.

Perspective 2: Local Causal Sliding Window — Exploiting Local Physics

For a circuit depth of $L=10$, we can leverage the commutativity of 2-qubit gates to convert the ladder structure into a brick-wall equivalent. Consequently, every local TFIM term possesses an exact backward causal cone during backpropagation. Since the diagonal entangling gates commute, the width of this causal window is strictly $2L+2$, which is only 22 sites for $L=10$. The brick-wall structure, which was a liability for global tree search, becomes a massive advantage here.

By using lax.scan to iterate over the local Pauli terms of the Hamiltonian and wrapping single terms in jax.checkpoint, the compilation scale becomes solely dependent on window size and circuit depth, totally decoupled from the total number of system sites:

$$T_{\rm window}=O(n C_{\rm local}(L)),\qquad M_{\rm window}=O(M_{\rm local}(L))$$

This approach boasts rapid compile times (~10 seconds) and a lean VRAM footprint of 8.86 GB. If dispatched across 8 GPUs (125 local terms per GPU), the steady-state gradient time drops to 18.71s. However, the overlapping causal windows introduce massive computational redundancy.

Furthermore, this method heavily relies on the commutativity of diagonal gates. If we swap them for non-commuting 2-qubit gates, the causal cone under a ladder structure expands to $O(n)$, rendering this method useless.

Perspective 3: Spatial Transfer Matrix — Lossless Exact Scanning

The spatial transfer matrix strategy slices the system along the spatial qubit dimension into a left-end block, repeating middle blocks, and a right-end block. The middle block receives the complete boundary tensor from the left, contracts its internal bra-MPO-ket subnetwork, and outputs to the next block.

The recurrence relation is:

$$B_{k+1}=\mathcal{T}_k(\boldsymbol\theta_k)B_k$$

At depth $L=10$, the spatial cut crosses 10 ket bonds, 10 bra bonds, and 1 MPO bond (dimension 3). The exact boundary size is:

$$D_{\rm boundary}=3\times2^{2L}=3\times4^L = 3\times4^{10}$$

This amounts to roughly 24 MiB of memory traffic, which perfectly explains why this method can effortlessly perform linear scanning at the 1,000-qubit scale.

Using a 3-site block division, this mode requires just 6.367s for cold compilation, executes at 1.054s per step, and peaks at 8.62 GB of VRAM.

The spatial width of each scan step (the block size $b$) acts as a tunable time-space tradeoff:

Smaller blocks shrink the internal contraction graph, reducing compile pressure and the residuals saved for backprop, but increase the number of scan steps needed to pass the boundary tensor.
Larger blocks reduce scan steps but inflate maximum tensor size, total write, compile time, and peak VRAM.

In our tests, a 3-site block offered optimal throughput. A 5-site block reduced peak VRAM further to 5.44 GB, at the slight cost of increasing execution time to 1.133s.

Counterintuitive Acceleration: Trading Compute for Bandwidth

Fascinatingly, pairing the transfer matrix's middle block loop with jax.checkpoint (recomputation) dropped the peak VRAM from 42.24 GB down to 8.62 GB, while also slightly reducing steady-state execution time from 1.118s to 1.054s.

"Reducing memory traffic by recomputing intermediate residuals" actually speeding up execution highlights a hardware reality: on modern consumer GPUs, memory bandwidth is often a much harder bottleneck than raw single-precision FLOPs. Taking on a heavier compute burden to alleviate read/write strain yields net performance gains. This same logic applies when tuning the penalty ratio between time and space complexity during contraction tree searches.

Even more thought-provoking is the fact that this relatively simple spatial slicing and block-scanning strategy heavily outperformed the global tree—derived from intense simulated annealing—in execution time, compile time, and memory footprint. This implies that for truly massive tensor networks requiring backpropagation (where intermediate residuals and VRAM are paramount), existing contraction path algorithms still have significant blind spots and ample room for innovation.

Pitfalls to Avoid

Bypassing TF32 Precision Limitations

When doing complex matrix multiplications on NVIDIA GPUs, simply setting the highest precision in JAX is not enough to avoid automatic degradation to TF32. You must explicitly set this environment variable before runtime:

Bash

   export NVIDIA_TF32_OVERRIDE=0

If you don't, the state norm can slip to 0.98–0.996, causing noticeable deviations in energy calculations. This is a stark reminder of the differing precision tolerances between standard Machine Learning and Quantum Simulation.

Rayon Thread Pool Stack Overflows

When omeco searches ultra-deep trees (depth > 1000) and generates slicing code, the recursive traversal of the deep tree can trigger a Segmentation Fault in Rayon threads. You must explicitly bump up the stack size before initiating Python or the Rayon global pool:

Bash

   export RUST_MIN_STACK=67108864

Full 1,000-Qubit VQE: From Single-Step Gradients to End-to-End Optimization

To prove that this isn't just a parlor trick for a single energy/gradient calculation, we ran a complete, complex 1,000-qubit VQE optimization. Our circuit features 10 layers of nearest-neighbor $R_{ZZ}$ ladders, with each layer's single-qubit component consisting of sequential $R_X$, $R_Z$, and $R_X$ rotations:

$$\vert{}0\rangle^{\otimes 1000}\xrightarrow{H^{\otimes 1000}}\left[R_{ZZ}\text{ Ladder}\rightarrow R_X\rightarrow R_Z\rightarrow R_X\right]^{10}.$$

Before constructing the full bra-MPO-ket network, we exactly compressed each consecutive $R_X$–$R_Z$–$R_X$ sequence into a single $2\times2$ single-qubit tensor. We then utilized the exact same Spatial Transfer Matrix scheme (with zero approximation truncations) to compute the energy and the gradients for all 40,000 parameters. The entire optimization ran on a single NVIDIA RTX 6000D, completing 2,000 Adam updates.

For this 1,000-site critical open-boundary TFIM, the exact ground state energy can be derived directly from the free-fermion spectrum. After 2,000 updates, our VQE energy was $E_{\rm VQE}=-1268.4365$, resulting in a total energy error of $E_{\rm VQE}-E_0=4.440$. This equates to a relative error of about $3\times10^{-3}$.

Without any hyperparameter tuning, a 1,000-qubit VQE featuring complex gate sequences, full parameters, and exact full gradients hit a relative energy precision in the thousandths. This confirms that our tensor network representations, path searches, spatial scanning, autodiff, and GPU execution aren't isolated micro-optimizations—they form a cohesive, end-to-end technical pipeline capable of translating circuit definitions into actual, strictly-verified optimization convergence.

Conclusion

Our work on full-gradient simulation and optimization for a 1,000-qubit VQE demonstrates that by hybridizing low-rank gate decomposition, contraction path search, lossless spatial transfer matrices, JAX automatic differentiation, and compiler mechanics, we can do the impossible. We can compute the full gradient of a 1,000-qubit VQE rapidly on a single GPU, execute thousands of training steps within hours, and achieve ~0.3% relative energy error without systemic fine-tuning.

These results illustrate the immense potential of moving from single-shot simulations to massive end-to-end variational computation, leaving plenty of headroom for exploring better circuit structures, learning rate schedules, and higher precision.

Getting a 1,000-qubit VQE to run natively proves one thing: in the deep waters of quantum simulation, the mathematical elegance of algorithmic design must be deeply coupled with the underlying mechanics of compilers (XLA), automatic differentiation, and GPU hardware architectures. TensorCircuit-NG is more than just a simulator; it is a critical piece of infrastructure that bridges software and hardware, providing a complete technical pipeline from quantum algorithm definition to ultra-large-scale variational optimization.

Large-Scale TensorCircuit Contractions on GPUs: Disabling XLA GPU Autotuning

Shixin Zhang — Wed, 15 Jul 2026 03:41:23 +0000

When running large-scale tensor-network contractions with TensorCircuit-NG and the JAX GPU backend, the following runtime configuration is worth testing:

XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

Its main benefit is not speed, but lower persistent GPU memory usage from XLA GPU autotuning, which makes memory behavior during compilation and on the first visible GPU more predictable. In the TensorCircuit contraction workloads we tested, disabling autotuning also slightly improved steady-state runtime, but the memory savings were the more important result.

Key takeaway

XLA GPU autotuning evaluates alternative algorithms or workspace configurations for certain GPU kernels and custom calls, then selects an implementation. This can be valuable for convolutions, large GEMMs, and deep-learning workloads with fixed shapes. For large TensorCircuit contractions, however, the contraction path is already determined by OMECO or cotengra, leaving relatively little optimization freedom for autotuning while still potentially incurring substantial persistent memory overhead during compilation and tuning.

For TensorCircuit contractions, run this A/B test by default:

# Baseline
XLA_PYTHON_CLIENT_PREALLOCATE=false python your_script.py

# Test configuration
XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

Both environment variables must be set before the Python process starts and before JAX is imported. This recommendation primarily concerns GPUs; CPU backends do not exhibit the same GPU-kernel autotuning behavior.

Representative results

All results below use a fixed contraction path so that path-search randomness does not affect the comparison.

Workload	Autotuning	Post-compile memory	Peak memory	Steady-state runtime
100 qubits × 24 layers, amplitude	Default	8.7 GiB	8.7 GiB	0.37 s
100 qubits × 24 layers, amplitude	autotune=0	0.5 GiB	4.6 GiB	0.40 s
28 qubits × 12 layers, expectation gradient	Default	4.7 GiB	21.4 GiB	0.18 s
28 qubits × 12 layers, expectation gradient	autotune=0	0.5 GiB	17.2 GiB	0.15 s
28 qubits × 13 layers, expectation gradient	Default	10.9 GiB	43.8 GiB	0.46 s
28 qubits × 13 layers, expectation gradient	autotune=0	0.5 GiB	33.5 GiB	0.42 s
28 qubits × 14 layers, expectation gradient	Default	17.0 GiB	64.5 GiB	0.58 s
28 qubits × 14 layers, expectation gradient	autotune=0	0.5 GiB	64.5 GiB	0.58 s

The first three workload groups show the most common benefit: disabling autotuning reduces compilation-stage memory and the final peak. The 28 × 14 case appears different: post-compile memory falls from 17.0 GiB to 0.5 GiB, but the final peak is unchanged. This behavior is related to the JAX GPU allocator.

Why the final peak is unchanged for the 28 × 14 case

Even with XLA_PYTHON_CLIENT_PREALLOCATE=false, the default JAX GPU allocator tends to retain and reuse GPU memory that it has already allocated. The memory reported by nvidia-smi is therefore the amount held by the process, not the total size of tensors that are currently live.

In the 28 × 14 example, default autotuning did consume approximately 17 GiB of additional memory during compilation. During the first real backward contraction, however, the runtime buffers themselves also required a large allocation. The default allocator could reuse blocks allocated earlier, so the final peak was not simply the sum of runtime memory and autotuning memory.

Using XLA_PYTHON_CLIENT_ALLOCATOR=platform as a diagnostic exposes this difference:

Workload	Allocator	Autotuning	Post-compile memory	Peak memory
28 qubits × 14 layers, expectation gradient	Default	Default	17.0 GiB	64.5 GiB
28 qubits × 14 layers, expectation gradient	Default	autotune=0	0.5 GiB	64.5 GiB
28 qubits × 14 layers, expectation gradient	platform	Default	17.0 GiB	82.8 GiB
28 qubits × 14 layers, expectation gradient	platform	autotune=0	0.5 GiB	66.3 GiB

The platform allocator retains less reusable GPU memory, which makes it useful for diagnosing where allocations originate. Because it also reuses fewer large blocks allocated earlier, however, the runtime may request additional memory and produce a higher peak. Prefer the default allocator for normal execution; use platform mainly to confirm whether autotuning introduces extra memory usage.

Interpreting peak memory

Here, peak memory is the maximum per-process GPU memory observed by polling nvidia-smi, with snapshots recorded at stages such as after_compile and after_first_run. XLA's compiled.memory_analysis().peak_memory_in_bytes measures something different: it more closely reflects the computation graph's buffer assignment and is usually lower than the actual process memory reported by nvidia-smi.

Why the first GPU may use more memory in multi-GPU processes

In a JAX/XLA process that can see multiple GPUs, backend initialization, the default device, compilation services, autotuning caches, executable caches, or allocator state may be placed preferentially on the first GPU in the visible-device list. Consequently, the first GPU can hold an extra block of memory. Disabling xla_gpu_autotune_level often reduces this first-device memory tax.

For multiple independent single-GPU jobs, use CUDA_VISIBLE_DEVICES so that each process sees only its assigned GPU:

CUDA_VISIBLE_DEVICES=1 XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

For genuine multi-GPU parallel or distributed jobs, do not hide GPUs that must participate in the computation merely to avoid the first-device memory tax. Preserve the correct device set, then measure how disabling autotuning changes memory usage on each GPU.

Practical recommendations

For large TensorCircuit-NG contractions, use the following procedure:

Fix the contraction path instead of running a new stochastic path search for every benchmark.
Set XLA_PYTHON_CLIENT_PREALLOCATE=false to prevent JAX from reserving a large block of GPU memory at startup.
A/B test default autotuning against XLA_FLAGS=--xla_gpu_autotune_level=0.
Record compile time, first-run time, steady-state runtime, post-compile memory, and post-first-run memory separately.
Even if disabling autotuning does not improve steady-state runtime, prefer autotune=0, especially near the OOM limit or when scheduling multiple GPUs.

In short, disabling XLA GPU autotuning does not change the contraction path; it reduces an additional source of memory usage in the GPU compilation and execution layers. For large TensorCircuit contractions, this is usually a low-risk configuration well worth testing.

When Quantum Dynamics Doesn't Start from Zero: Completing the Missing Half of Entanglement Growth | PRL

Shixin Zhang — Fri, 10 Jul 2026 00:42:59 +0000

Entanglement dynamics lies at the heart of nonequilibrium quantum physics. For more than two decades, the standard approach has been remarkably consistent: start from an unentangled product state, let the system evolve unitarily, and study how the entanglement entropy grows over time.

This framework has led to many fundamental discoveries, including our understanding of quantum thermalization and many-body localization (MBL). It also shaped an implicit assumption shared across the field: whenever the half-chain entanglement entropy increases, the system must be creating new quantum entanglement.

Our recent paper, published in Physical Review Letters, argues that this picture is incomplete.

The central observation is surprisingly simple:

An increase in measured entanglement does not necessarily mean new entanglement has been created.

Instead, quantum dynamics possesses two fundamentally different capabilities that have long been mixed together.

Two ways to increase entanglement

A useful way to think about entanglement is to imagine the system as a connected network of water reservoirs.

There are two distinct mechanisms that can raise the water level observed at a particular cut.

Build: Creating new entanglement

The first mechanism genuinely generates new quantum correlations.

This is analogous to pumping fresh water into the entire reservoir system. The total amount of entanglement increases.

Move: Transporting existing entanglement

The second mechanism creates no new entanglement at all.

Instead, quantum evolution simply redistributes the entanglement that already exists inside the system. Water is flowing internally, but no new water enters the reservoirs. Although the total amount remains unchanged, the water level measured at one particular location may still rise.

Exactly the same phenomenon can happen for half-chain entanglement entropy.

This distinction turns out to be much more important than previously appreciated.

The intuitive expectation

Once these two mechanisms are separated, an intuitive principle emerges.

If a system already starts with a large amount of entanglement, there is less room left to generate additional entanglement later.

Indeed, this is exactly what happens in familiar systems such as

quantum chaotic (thermalizing) systems,
free-fermion systems,
random quantum circuits with strong scrambling.

As the initial entanglement increases, the additional entanglement generated during evolution decreases monotonically.

This is precisely what one would expect if entanglement growth were primarily driven by building new entanglement.

MBL breaks the rule

Many-body localized systems tell a completely different story.

Instead of decreasing monotonically, the entanglement growth exhibits a striking bell-shaped dependence on the initial entanglement.

Starting from nearly product states, the growth is very small.
Starting from nearly maximally entangled states, the growth is again very small.
The largest increase occurs at intermediate initial entanglement.

This behavior is difficult to explain if entanglement growth comes solely from generating new entanglement.

Something else must be happening.

A "pure transport" experiment

To isolate the missing ingredient, we designed a particularly simple reference model.

Instead of using an interacting Hamiltonian, we considered a random circuit composed only of SWAP gates.

This circuit has a remarkable property:

it cannot create any entanglement, and
it only exchanges the locations of quantum states.

In other words, it performs pure entanglement transport.

Surprisingly, the entanglement-growth curve produced by this SWAP-only circuit closely matches the behavior observed in MBL systems, both qualitatively and even quantitatively.

This comparison reveals the underlying physics.

MBL is not particularly good at generating new entanglement.

Instead, it excels at moving around the entanglement that already exists.

When the system begins with almost no entanglement, there is simply nothing to transport.

When it begins nearly saturated, there is no remaining room for rearrangement.

Only at intermediate entanglement do both ingredients coexist, allowing transport to produce the largest observable increase.

Looking beyond a single bipartition

Most previous studies monitor only one quantity: the entanglement across the middle cut of the system.

While extremely useful, this provides only a partial view of the system's entanglement structure.

In our work, we introduce a more global perspective by considering the Bipartition-Averaged Entanglement Entropy (BAEE), which averages entanglement over all possible bipartitions.

The simulations reveal an interesting phenomenon.

Even in ordinary thermalizing systems, BAEE grows much faster than the half-chain entanglement during the early stages of evolution.

The difference between these two quantities represents a hidden reservoir of entanglement that has already been generated locally but has not yet reached the particular cut being measured.

Returning to our water analogy, thermalization rapidly fills many local reservoirs throughout the system.

Later dynamics can transport this stored entanglement across different partitions.

This picture naturally explains why transport-dominated systems like MBL exhibit their largest observable entanglement growth at intermediate initial entanglement.

A new perspective on entanglement dynamics

The broader message is that entanglement dynamics is not just about creating quantum information.

It is equally about processing, redistributing, and transporting the quantum information that already exists.

The traditional "start from product states" paradigm has taught us a great deal, but it captures only one half of the story.

Distinguishing between entanglement generation and entanglement transport provides a more complete framework for understanding quantum dynamics across thermalizing systems, free fermions, many-body localization, and quantum circuits.

Beyond offering a conceptual picture, this framework makes concrete predictions that can be tested on today's quantum simulation platforms, providing new experimental probes of nonequilibrium quantum dynamics.

Reference

Entanglement growth from entangled states: A unified perspective on entanglement generation and transport

Chun-Yue Zhang, Zi-Xiang Li, and Shi-Xin Zhang

Physical Review Letters 137, 020404 (2026)

DEV Community: Shixin Zhang

From “Shifting Gears” to “Borrowing”: Entanglement Spectra Are Becoming a Language for Nonequilibrium Dynamics

From “Where Is the Entanglement?” to “What Can It Do?”

Why Can a Conserved Charge Act as an Entanglement Account?

Entropy Has Already Arrived. Diffusion Is Still Catching Up.

A New Phase of Research Measured in Days

References

Chasing Quantum States Through Time: A Tour of Time-Evolution Methods in TensorCircuit-NG

Solve Everything at Once: Exact Diagonalization

Split Time into Pieces: Trotter, TEBD, and ODE Solvers

No Matrix Required: Krylov, Chebyshev, and expm-multiply

TenCirPauli: Extending the MVP Interface

TDVP: Let Parameters Move Instead of the Full State

A Quick Comparison

There Are More Ways to Evolve a Quantum State

Free-fermion dynamics

Neural quantum states

PEPS

The Algorithm Is Only Half the Story

JIT compilation

GPU and vmap

Automatic differentiation

So Which Method Should You Use?

Examples and References

The Origin of Quantum Architecture Search

Where the name came from

From a name to a research direction

A useful historical distinction

How far has the term traveled?

Entanglement Doesn’t Just Grow. It Can Also Shift Gears: Four Clocks in Quantum Dynamics

Opening Up a Number into a Spectrum

Thermalization and MBL: Two Routes Through the Entanglement Spectrum

One Spectrum, Four Clocks

Why Does the Shift Clock Ring Last?

What Changes Is Not Just the Quantity We Measure, but the Question We Ask

Goodbye to Manual Code Review: The Vibe Coding Experiment Behind TenCirPauli

TensorCircuit-NG Still Uses the “Old-School” Approach

The Development Workflow

The Spec Is Where Human–AI Collaboration Matters Most

Mature Libraries Provide the Coordinates

Tests, Benchmarks, and Global Repository Inspections

Will AI Make Mistakes?

The User Is an Agent

Maintainability Can Also Be Agent-Driven

Conclusion

When High-Level Abstractions Become the Bottleneck: Quantum Scientific Computing in the AI Era

A framework is a theory of scientific work

Quantum–AI scientific computing as one infrastructure

Performance reveals the architecture

The organization encoded in the stack

The default for advanced projects

References

Tensor Networks Do Not Mean Approximate Simulation: The Right Way to Understand TensorCircuit-NG

Tensor Networks Are Not an Approximation Algorithm

Circuit in TensorCircuit-NG: Exact Contraction of Complete Circuits

Compared with State-Vector Simulators, Where Does the Speedup Come From?

DMCircuit: Complete Density-Matrix Simulation Based on Tensor Networks

MPS Is One Special Form of Tensor Network

Beyond the Three Main Modes: More Native Simulators

Why I Developed TenCirPauli

Framework selection creates a performance profile

Where the JAX model becomes expensive

Why Rust is a useful complement

What this implies for Pauli computation

The functionality follows from the runtime choice

From physical models to canonical operators

From operators to measurements and structural information

From one operator to several execution targets

From circuits to observable execution and gradients

What the Early Benchmarks Show

The larger lesson

From Parameter Tuning to Cross-Paradigm Exploration: Quantum Control Enters the Era of “Autopilot”

Beyond Closed Optimization Spaces: How QOC-Workbench Works

1. Human experts define the physical boundary

2. LLM performs cross-paradigm exploration

3. Physics solvers provide rigorous validation

4. Memory engine turns experiments into reusable knowledge

Three Levels of Evolution: From Pulse Shaping to Neural Control Generators

Case 1: Designing Hardware-Compatible Control Pulses

Rydberg Atom Arrays

No Matrix Required: Krylov, Chebyshev, and `expm-multiply`

GPU and `vmap`

`Circuit` in TensorCircuit-NG: Exact Contraction of Complete Circuits

`DMCircuit`: Complete Density-Matrix Simulation Based on Tensor Networks