Fiducial selection for prep fiducials generates wrong qubit labels

[pcwysoc]

Describe the bug
During fiducial selection prep fiducials get incomplete qubit labels

To Reproduce
Steps to reproduce the behavior:

1. Create a 2Q target model with qubit labels ('Q0', 'Q1')
2. Do fiducial selection using:
   prepFiducials, measFiducials = fidsel.find_fiducials(target_model, algorithm='greedy',candidate_fid_counts=3)
3. Look at the prepfiducials
4. See error

Expected behavior
Prep fiducials should all have qubit labels @('Q0', 'Q1')

Environment (please complete the following information):

• pyGSTi version feature-qiskit-mcm
• python version 3.10
• OS Ventura 13.6.4

[coreyostrove]

Hey @pcwysoc, thanks for the report. Question for you, when encountering this behavior did you subsequently encounter any related errors caused by this? Or what this simply unexpected behavior?

I ask because this is something that was on our radar due to some errors that we have previously run into in the context of GST on systems with native parity readout. In that context an error arises because the action of measuring a single qubit is not defined. I ask mostly to see if there are other ways this interacts with the codebase we might not be aware of, but should be cognizant of when addressing it.

That leaves open the question on the right way to address this, which I’d be open to feedback on. The easy ‘fix’ would be to simply have the edesign code always include line-labels for every qubit in all circuits. This feels suboptimal in certain contexts though, particularly for many-qubit circuits. I imagine part of the motivation for the current (though computational basis centric) behavior is that it quickly gets unruly to list 100+ line labels for a single-qubit circuit. Introspecting the modelmembers and inferring this seems tricky though.

Spitballing ideas here, but one thing we are (to my knowledge) currently lacking is a way to specify availability for POVMs and instruments. Perhaps we could use this to implicitly specify line-labeling requirements? Or otherwise enable a cleaner inference of what is required? (Independent of the line-labeling issue patching this missing part of processor specs is probably something to prioritize regardless given the increasing use of instruments in general, though I think this listed in the instrument omnibus issue already).

[pcwysoc]

I encountered this bug while running an experiment on IBM where I'd performed fiducial selection to generate 2Q fiducials. It meant that I did not receive 2 outcomes for several circuits and could not run the complete GST experiment as a result. I also ran into additional problems regarding a POVM not being specified in the target model for those circuits.

[coreyostrove]

Was this an experiment involving a parity instrument? If so I suspect the latter of these two errors is the one we previously encountered.

[pcwysoc]

Yes, it did include a quantum instrument. However, the circuits where this error came up did not include the instrument (since two-qubit instrument-containing circuits would be forced to have the correct qubit labels).

[coreyostrove]

Ok, in that case can you send a code snippet with a minimal working example? I think this is something new.

[pcwysoc]

Here's a minimal working example. Not sure how helpful it will be though. Mostly it comes down to some circuits in the edesign inherit the incorrect qubit labels from the prep fiducials which then causes a various issues.
FidSelectionBug.ipynb.zip

[sserita]

Closing as this is fixed with #418 merged.

[pcwysoc]

I found an edge case of this fix not working. The idle germ still generates without the correct qubit labels. It has qubit labels (*).

[pcwysoc]

@coreyostrove It looks like germ selection has the same issue.