Give access to all EOM block parameters and allow for phase drift correction #566
Conversation
There was a problem hiding this comment.
@HGSilveri thank you so much for working on this so quickly.
I just had a quick look without working out all the logic here since there is a lot of new code.
If I understand correctly, there is now a new option, off by default, to automatically correct the phase drift acquired by delays before new pulses when in EOM mode, so that the user get an effective pulse that has the intended effect.
The workaround we have with Lucas at the moment is to find the off detuning value of the sequence in EOM mode by some means, add a delay of known duration between pulses, and do the phase correction on the user side.
We have to make the delay long enough so that the phase can ramp up.
Is the ramp up for the correction of the phase taken into account when scheduling the pulses?
Hey @lvignoli , thanks for the quick review! I just wanted to let you know about this feature to make sure it suits your needs, don't worry about reviewing everything in detail.
That is correct, yes.
Yes, whenever you modify the phase the so called "phase jump time" is enforced and this is no exception. In fact, if the delay causing the phase drift you're trying to correct for is too short to change the phase, it is extend by the necessary amount and then the phase drift correction takes into account the full delay, not just the original one. |
…nto hs/eom-params
|
Okay it makes things clear on my side. Also I am glad to know the phase ramp up I always taken into account (Pulser is doing so much behind the scenes during pulse scheduling, it's sometimes hard to know what is guaranteed and what is not). |
|
|
It's because of the parametrized sequences, since you can't know before the sequence is built what the correction factor will be. |
|
Ah this makes sense indeed. So for non-parametrized sequences, do we directly apply the correction and serialize it or do we let the backend apply the correction ? |
We let the backend apply the correction |
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
|
I am ready to approve, everything looks good to me. There seems to be an issue with the build of the docs, I wonder if it was not just a bug with the imports. |
Yes, this seems to be a general issue, I don't think it's related to these changes. I'll look into it |
Main changes: e0943d9 Override `optimal_detuning_off` on stored calls (#588) 3e40319 Deprecate legacy serializer + Improve error messages (#585) 9e05982 Adding register_is_from_calibrated_layout and is_calibrated_layout to Device (#586) c08dfa8 Adding dmm config and modulation to sequence (#564) 5270944 Clarify the Conventions in Pulser (#573) 2315989 Give access to all EOM block parameters and allow for phase drift correction (#566) d5ac020 Adding DetuningMap, DMM (#539) f56a19f Remove expired deprecations in pulser-pasqal
detuning_offvalue throughRydbergEOM.calculate_detuning_off()correct_phase_drift: booloption to EOM operations to correct for the phase drift that occurs during detuned delaysFixes #562 .