Skip to content
This repository has been archived by the owner on Jun 12, 2023. It is now read-only.

t2star_circuits does not add phase oscillations for fixed delay time #510

Open
aeddins-ibm opened this issue Oct 9, 2020 · 0 comments
Open
Labels
bug Something isn't working

Comments

@aeddins-ibm
Copy link

aeddins-ibm commented Oct 9, 2020

Informations

  • Qiskit Ignis version: 0.4.0
  • Python version: 3.7.x
  • Operating system: mac

TLDR:

Add a kwarg step_phase_vs_time=True or something. At the default value of True, the existing behavior in t2star_circuits will happen, where the phase is stepped w.r.t. the time delays provided. Advanced users can choose to set it to False, in which case the phase is stepped over the list of circuits returned, independent of delay times, permitting e.g. stepping phase at fixed delay. In this case the induced oscillation frequency could be returned as None.

What is the current behavior?

t2star_circuits (in ignis.characterization) takes the kwarg nosc indicating the number of phase oscillations to be added by varying the phase of the second pi/2 pulse. Since the kwarg is the number of oscillations as opposed to the frequency of the oscillations, I would expect that the max number of oscillations added will be independent of the delay times between the pi/2 pulses in the schedules. (It is ambiguous from the docs how the phase wrapping would be applied to a list of unevenly-spaced delay times, i.e. whether the "linear phase" depends linearly on the delay times, or in the index of the circuit in the list of circuits). However, if the delay times are all the same, no phase oscillations are added.

The ability to generate Ramsey sequences with a fixed delay time but variable phase-shift is broadly useful. One may argue that this edge case should not be included in the jurisdiction of "t2star circuits"; but for example if you assume full coherence at delay time t=0, a list of circuits with fixed delay time t != 0 and stepped phase can be used to estimate T2star, so I think it would be better to support this case.

Steps to reproduce the problem

The image below shows the phase shifts (arguments of U1) are all the same, even though nosc is nonzero.

image

What is the expected behavior?

Since the user specifies nosc, it's expected that the phase should be stepped across each circuit s.t. nosc oscillations are added.

Suggested solutions

There are tradeoffs, not sure what's best here. I would tentatively suggest Option 3 below.

Option 1: Apply the phase stepping specified by nosc completely independent of the delay times provided (this is what I implicitly suggest above). This has the (big) downsides that the "induced oscillation frequency" currently returned by t2star_circuits is not in general well defined so cannot be returned to the user, and will likely lead to confusion in the case of unevenly spaced delay times.

Option 2: Replace the nosc kwarg with phase_stepping_freq or similar. This can then be multiplied by the delay times provided (basically the same as is currently done?) and the user's expectation will be in line with the results. This has the (big) downside that the phase cannot be stepped while holding the delay time fixed.

Option 3: Keep nosc, but have an additional kwarg step_phase_vs_time=True or something. At the default value of True, the existing behavior in t2star_circuits will happen, where the phase is stepped w.r.t. the time delays provided. Advanced users can choose to set it to False, in which case the phase is stepped over the list of circuits returned, independent of delay times, permitting e.g. stepping phase at fixed delay. In this case the induced oscillation frequency could be returned as None.

@aeddins-ibm aeddins-ibm added the bug Something isn't working label Oct 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant