pyGSTi
pyGSTi copied to clipboard
Modernize Modelpacks
There have been a significant number of improvements to our experiment design capabilities in pygsti over the past year-or-two, but so far none of these have trickled down in any significant way to the modelpacks (the recent addition of MS-gate modelpacks by @enielse being a possible exception). Moreover, certain design choices for the modelpacks made sense in the original context in which they were made, but are less ideal presently. Examples:
- Prep and measurement fiducial sets in the modelpacks for multi-qubit gate sets are designed use only single qubit gates. Using two-qubit gates for measurement fiducials often significantly reduces the number of fiducials required, sometimes by a factor of 2 or more (which translates directly into reductions of the same magnitude in experiment designs overall). Recent empirical findings also suggest that including two-qubit gates in measurement fiducials also improves the performance of per-germ FPR when applied.
- Most modelpacks include the option for returning FPRed experiment designs, but these are generally out of sync with the current state of the art and should ideally be brought up to date with our current implementations.
- For certain single-qubit modelpacks the decision was made to use a full state 2-design for the preparation and measurement fiducials. This decision has a good enough justification, but also requires significantly more circuits than is required by a minimally-informationally complete set and if nothing else warrants a brief explanation in the relevant docstrings.
To bring things up to date I suggest the following:
- Add preparation and measurement fiducial sets to the modelpacks including two-qubit gates. Add a flag to the corresponding modelpack functions for toggling between this and fiducial sets containing only single-qubit gates. Debate welcome about whether including two-qubit gates should be the default going forward or not.
- Replace the FPRed experiment designs in the modelpacks with versions generated with the latest experiment design code (perhaps keeping the older ones accessible with an appropriate flag for backwards compatibility). Debatable as to whether we should include just one design, or options for designs from both per-germ classic and the new per-germ global FPR schemes.
- For single qubit gate sets where we are using state 2-designs for the fiducials include an option for toggling between this and a MIC set. Not certain which should be the default going forward.
Some last thoughts:
A reasonable objection to some of the above might be that we risk bloating the modelpack interface too much by adding these additional experiment design options directly to them as opposed to pushing folks interested in more refined designs to use the experiment design generation code directly. While I am sympathetic to this perspective, so far as I can tell the vast majority of pygsti users rely nearly entirely on modelpacks for experiment designs and only a small number of power users ever actually touch the experiment design generation code. In other words, if we want people to actually use the cool new tech we've been developing in this area we'd be well-served to meet them where they currently are, which is in the modelpacks. End rant.
Thoughts?
As part of modernization we should evaluate whether there are any modelpacks that would be convenient that we are currently missing. The two that come to mind are the single-qubit XZI gateset and the two-qubit XZCPHASE gateset. Anyone have any other suggestions?
Perhaps we should also consider adding in 3-qubit variants for some gate sets now that we have the experiment design capabilities. The germ selection for these 3-qubit gate sets is still a multi-day workstation computation even with the recent algorithmic improvements, so including some of these would vastly reduce the barrier to entry for these experiments.
This is an excellent point. There are several additional model packs I can think of (all include idle but we should also probably include the idle-less variants as well):
- 2Q XYIMS (Molmer-Sorensen: Exp(-i pi/4 XX). Native two-qubit gate for most/all ion trap platforms.)
- 2Q XYICR (Cross-resonance: Exp(-i pi/4 ZX). Native two-qubit gate for many transmon platforms.)
- 1Q HSI (Hadamard and Phase)
- 1Q HSTI (Hadamard, Phase, and T)
With respect to Z rotations, given that it's a native (essentially free) operation on many platforms it may be worth making XZ variants of all XY-containing model packs.
FYI: Corey and I have discussed this and have a game plan for creating a utility function to transition the current modelpacks and create new modelpacks based on an existing model and fidsel/germsel arguments. We will be working on this feature-modernize-modelpacks branch.
@kmrudin when this utility is done, we may tap you to create models for the above modelpacks we should include :)
@sserita @coreyostrove I second @kmrudin's point that it might be worth developing modelpacks that include the CR gate. It appears that IBM may be replacing CNOT as the directly accessible entangling gate with CR on all of their 100+ qubit devices. I'm happy to help with this, as I'm hoping to run some two qubit GST experiments on these newer devices in the near future.
Hey @pcwysoc, thanks for the heads-up and feedback. We can definitely prioritize inclusion of CR-gate based modelpacks with the modernization updates. Thanks for the offer to help with this, and we’ll keep this offer in mind. If all goes to plan, however, we’ll have the process of building the new modelpacks heavily automated, so the upfront cost of the metaprogramming will take some effort, but the marginal effort of adding any particular modelpack once that script is set-up should be fairly low.