Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fiducial selection for prep fiducials generates wrong qubit labels #396

Closed
pcwysoc opened this issue Feb 2, 2024 · 8 comments
Closed

Fiducial selection for prep fiducials generates wrong qubit labels #396

pcwysoc opened this issue Feb 2, 2024 · 8 comments
Assignees
Labels
bug A bug or regression
Milestone

Comments

@pcwysoc
Copy link

pcwysoc commented Feb 2, 2024

Describe the bug
During fiducial selection prep fiducials get incomplete qubit labels
Screenshot 2024-02-01 at 7 23 27 PM

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
@pcwysoc pcwysoc added the bug A bug or regression label Feb 2, 2024
@coreyostrove coreyostrove added this to the 0.9.13 milestone Feb 13, 2024
@coreyostrove
Copy link
Contributor

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
Copy link
Author

pcwysoc commented Feb 20, 2024

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
Copy link
Contributor

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
Copy link
Author

pcwysoc commented Feb 20, 2024

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
Copy link
Contributor

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

@pcwysoc
Copy link
Author

pcwysoc commented Feb 20, 2024

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 sserita modified the milestones: 0.9.13, 0.9.12.2 Mar 26, 2024
@sserita sserita added the fixed-but-not-in-release-yet Bug has been fixed, but isn't in an official release yet (just exists on a development branch) label Apr 15, 2024
@sserita
Copy link
Contributor

sserita commented Apr 15, 2024

Closing as this is fixed with #418 merged.

@sserita sserita closed this as completed Apr 15, 2024
@sserita sserita removed the fixed-but-not-in-release-yet Bug has been fixed, but isn't in an official release yet (just exists on a development branch) label Apr 17, 2024
@pcwysoc
Copy link
Author

pcwysoc commented Jun 28, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug or regression
Projects
None yet
Development

No branches or pull requests

3 participants