do_stdpractice_gst() only runs single-2QUR for Target mode

[dnadlinger]

I am using do_stdpractice_gst() on two-qubit GST data, and with default parameters, the single-2QUR gauge optimisation is only run on the Target model data, not on the results of the TP/CPTP modes.

Only the "-- Performing 'single' gauge optimization" message is printed for the TP/CPTP steps, and indeed the generated report is missing the single-2QUR data for all but the Target model.

Environment (please complete the following information):

• pyGSTi version: master (v0.9.8.2, f143ca1)
• python version: 3.5, 3.7
• OS: macOS, Linux

(This sounds like a trivial bug that would be easier to fix for me than to write up, but then, you couldn't accept a PR from me unless the legal situation has changed in the meantime.)

[robpkelly]

You're correct that we still can't accept PRs -- sorry about that!

[dnadlinger]

Apologies, this might just be user error/a documentation problem: I hadn't realised that gaugeopt_suite_to_dictionary hard-codes a list of two-qubit gate names rather than inspecting the target model. In the if isinstance(gg, _objs.TrivialGaugeGroup): branch, the optimisation is added unconditionally – that's why it is executed for the target model.

[dnadlinger]

(A warning if no gate in unreliableOps is found would help make this more discoverable.)

[enielse]

I've just added a fix for this in 15e8f45. It should avoid having 'single-2QUR' present for just the target mode ('single-2QUR' should either be there for all or none of the modes) and, as was suggested, a warning is now generated when no gate in unreliableOps is found.

As an aside, the reason why it's difficult to perform this discovery automatically is that within PyGSTi all of the gates in a 2-qubit model are seen as 2-qubit gates, and represented by 16x16 matrices. We could test whether a gate is entangling, and choose only those gates as the default unreliableOps in the future, but we haven't done this yet.

Finally, note that this fix is only on the beta branch, and not on master (or available via pip). Because this doesn't seem like a critical issue to fix immediately, my preference would be to just wait until our normal develop cycle produces a new release and then this fix will be included on the master branch. Please feel free to argue this point. Let's leave this issue open until the fix reaches a release.

[dnadlinger]

Great, thanks, this is perfect – feel free to close this whenever most convenient for you. Automatic detection probably isn't worth it, I was just taken by surprise by the fact that it did seem to auto-detect it for Target (when in actuality the entire option was just added since the last version I had used).