Skip to content
New issue

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

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

Already on GitHub? # to your account

MeasurementCriteria for readout error to target measurement operations #973

Open
yitchen-tim opened this issue May 9, 2024 · 1 comment
Labels
good first issue Good for newcomers

Comments

@yitchen-tim
Copy link
Contributor

Describe the feature you'd like
Currently, the readout error in noise model only can targets observables result types through ObservableCriteria. This issue proposes to add MeasurementCriteria for applying readout error to circuits without observables result types.

How would this feature be used? Please describe.

noise_model = NoiseModel()
noise_model.add_noise(BitFlip(0.1), MeasurementCriteria(qubits=[0,1,2]))

Describe alternatives you've considered
Simply add the readout noise to the end of the circuit. When there are observables, this implementation will add noise before the basis rotation gates, not truly at the end of the circuit.

@rmshaffer rmshaffer added the good first issue Good for newcomers label May 14, 2024
@blolt
Copy link

blolt commented Jan 5, 2025

Would be happy to pick this up. It looks like the key thing will be defining a new MeasurementCriteria class that extends ResultTypeCriteria and implement the abstract result_type_matches method with signature,

def result_type_matches(self, result_type: ResultType) -> bool:

For the ObservableCriteria, there is a defined ObservableResultType and several classes that extend this type. There are five result types that do not extend the ObservableResultType:

  1. StateVector
  2. DensityMatrix
  3. AdjointGradient
  4. Amplitude, and
  5. Probability

Am I correct in understanding that we are defining MeasurementCriteria for those circuits which have these result types, but not any of the observable result types? If so, defining the new MeasurementCriteria class and implementing result_type_matches is straightforward, but I am not sure what additional work may be necessary from there. I am also not certain this is the exact issue we are concerned with.

I'd appreciate some clarification on the original issue and some feedback on whether the approach I have described makes sense. To me, it feels like there are some gaps that may require some larger refactorings.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants