Skip to content

RB analysis can not work beyond 10,000 Cliffords #1594

@wshanks

Description

@wshanks

Informations

  • Qiskit Experiments version: 0.12.0
  • Python version: 3.13
  • Operating system: Fedora Linux 42

What is the current behavior?

When using StandardRB, the analysis will fail if more than 10,000 Cliffords are used in the experiment.

Steps to reproduce the problem

from qiskit_aer import AerSimulator
from qiskit_aer.noise import NoiseModel, depolarizing_error

from qiskit_experiments.library import StandardRB

noise_model = NoiseModel()
noise_model.add_all_qubit_quantum_error(depolarizing_error(5e-3, 1), ["sx", "x"])
noise_model.add_all_qubit_quantum_error(depolarizing_error(0, 1), ["rz"])
backend = AerSimulator(noise_model=noise_model)

expt = StandardRB((0,), lengths=[1, 100, 10_001], backend=backend, num_samples=1, seed=1010)
expdata = expt.run().block_for_results()

This produces a figure like this:

Image

expdata.analysis_errors() is an empty string and no messages are written to stdout or stderr.

What is the expected behavior?

The analysis should succeed and produce a fit on the plot and associated analysis results. Besides that, if the analysis does fail, the failure should be reported to the user.

Suggested solutions

Digging into the code, I find that the analysis failure comes from RuntimeError: Invalid exponent, max exponent is 10000 issued by asteval.astutils.safe_pow. That limit was added long ago to asteval in lmfit/asteval#17 with little explanation. I believe the motivation of the limit is that asteval could be operating on Python ints which are unbounded and so could grow exponentially in memory footprint. When working numpy, numeric types have fixed memory sizes and so there is no danger of using too much memory. The maximum exponent is set here and has not changed since it was added 10 years ago.

Possible solutions:

  1. Monkey patch asteval.astutils.MAX_EXPONENT = max_cliff + 1 in RBAnalysis._initialize. To be polite, we should set the value back to what it was but there isn't a good place to do that (we might need to override _run_analysis and call super()._run_analysis() in a try/except to make sure it always set back. Maybe we should not worry about it and just leave it at the higher value. If going with this approach, we could perhaps ask upstream asteval if there could be a more official way to change MAX_EXPONENT.
  2. Change the fit model expression. I think changing the model to (alpha ** (x / 10)) ** 10 would avoid the problem. Does the model expression get used in documentation anywhere that would make this awkward? From a quick check, it looks like we just recreate the expression in TeX syntax for the documentation any way.
  3. Do something else to break out of the lmfit/asteval limitation?

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions