In pyGSTi in order to construct Randomized Benchmarking circuits, we first need to define a pspec object that contains information about the number of qubits, basis gates and gate availability.*

In the tutorial notebooks (https://github.com/pyGSTio/pyGSTi/blob/master/jupyter_notebooks/Tutorials/algorithms/RB-DirectRB.ipynb), they use a predefined gate dictionary for this, where each gate is called by a certain key (string) and it's value corresponds to the numpy array for the matrix representation of the gate. This does not seem to allow parametrized gates but if we want to characterize for example an ibmq device, then we would need a dictionary for continuously parametrized gates.

I would be really happy, if someone knows how to define a pspec object so that it corresponds to the device, I want run the experiments later on.

*(Interestingly the qubit topology doesn't play a role here, but the sampling algorithms for direct and mirror randomized benchmarking need to work with the topology of the device in order to achieve the desired sampling process of single- and two-qubit gate layers...)


1 Answer 1


This is a totally reasonable question and request, but unfortunately as of November 2021, pyGSTi doesn't support continuously parameterized gates in any useful way. It's something we (the Sandia QPL team behind pyGSTi) are working on, because we want to characterize continuously parameterized gates too! But at this point in time, there aren't really any protocols in the literature for performing QCVV on continously parameterized gates. Even RB -- which is conceptually a lot easier to generalize to continously parameterized gates than, e.g., GST -- is tricky because you need to derive or choose-and-justify some distribution over the rotation angles that appear in the circuits. (Obviously you could just pick one... but that's the problem. You could pick many distributions, and they would give different results. Which one is "right"?). This constitutes basically a whole new variant of RB, with all the concomitant theory. So fundamentally the obstacle isn't about implementation in pyGSTi; it's about the underlying research.

There's a really straightforward workaround, though, which is to just pick a discrete set of gates and work with those. Any set of gates that generates the Cliffords is sufficient for RB. Users (including us) do this reasonably frequently with IBM processors. AFAIK that's how IBM compile their own RB routines used to report device metrics.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.