Fix dispersive shift updated frequency

[andrea-pasquale]

Closes #430.

I've also renamed Frequency Shift to Chi by dividing the shift by two (hopefully it is correct).

Checklist:

• Reviewers confirm new code works as expected.
• Tests are passing.
• Coverage does not decrease.
• Documentation is updated.

[codecov]

Codecov Report

Merging #432 (ac8ac55) into fix_backend (5d4e2c5) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

@@             Coverage Diff              @@
##           fix_backend     #432   +/-   ##
============================================
  Coverage        96.77%   96.77%           
============================================
  Files               48       48           
  Lines             3129     3129           
============================================
  Hits              3028     3028           
  Misses             101      101           

Flag	Coverage Δ
unittests	96.77% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...cal/protocols/characterization/dispersive_shift.py	100.00% <100.00%> (ø)

[rodolfocarobene]

Tests seems to be failing for unrelated reasons, but the routine now works (and improves the fidelity!)

[andrea-pasquale]

Tests seems to be failing for unrelated reasons, but the routine now works (and improves the fidelity!)

I'll have a look at tests now, thanks for the feedback.

[rodolfocarobene]

I approved, but obviously this should be merged after the tests pass.
Also, for a future change, I think would be nice to have in the characterization section "readout frequency" AND "resonator frequency"

[andrea-pasquale]

Also, for a future change, I think would be nice to have in the characterization section "readout frequency" AND "resonator frequency"

In theory we already have the information about the readout frequency in the readout pulse.
We should be more careful when updating the runcard. For this particular case I would say that the dispersive shift should only update the frequency of the readout pulse without touching the resonator frequency.
What do you think?

[rodolfocarobene]

It makes sense, but then I would change the naming in the characterization section that is now called "readout frequency" to "resonator frequency".
Obviously doesn't change much, but now it's a bit misleading and we "loose" some information

[andrea-pasquale]

It makes sense, but then I would change the naming in the characterization section that is now called "readout frequency" to "resonator frequency". Obviously doesn't change much, but now it's a bit misleading and we "loose" some information

I agree. We already have bare resonator frequency even if we are not using it in the runcards I think.
At this point we could have bare resonator frequency and dressed resonator frequency in the characterization section and we keep the readout freq in the pulse.

[Jacfomg]

Also, for a future change, I think would be nice to have in the characterization section "readout frequency" AND "resonator frequency"

In theory we already have the information about the readout frequency in the readout pulse. We should be more careful when updating the runcard. For this particular case I would say that the dispersive shift should only update the frequency of the readout pulse without touching the resonator frequency. What do you think?

I think we only care about the readout frequency, we may only store the resonator frequency if we were interested on doing some simulation, right ?

Haloa

Sure rodolfo

[andrea-pasquale]

I think we only care about the readout frequency, we may only store the resonator frequency if we were interested on doing some simulation, right ?

To run things yes we need only the readout frequency. I would say that there is some value in also storing the resonator frequency.