During EOM mode, though the Rabi frequency and the detuning_on are chosen by the user, the detuning_off is not, and there should be an easy way to find out what the chosen value was, which can then be used to correct for incurred phase changes with a phase shift, for example.
The way to implement this is straightforward for a non-parametrized sequence (simply access the chosen value and return it), but what if the sequence is parametrized? There are two scenarios here:
amp_on and detuning_on are not parametrized: In this case, we could still calculate the EOM parameters, with a method like calculate_eom_parameters(). This is more flexible that just accessing the chosen values because when the sequence becomes parametrized they stop being calculated.
amp_on and/or detuning_on are parametrized: Here, we would have to somehow suspend the call to calculate_eom_parameters(), returning a parametrized object instead. Although possible, it sounds overly complex. I propose we leave this for later, in case it is requested.
Built-in phase correction
The usecase I currently have in mind could also be incorporated in add_eom_pulse() and it would be available under any scenario. I'm thinking we could call it correct_phase: bool = False. At build-time, it would have all the information it needs for the correction.
During EOM mode, though the Rabi frequency and the
detuning_onare chosen by the user, thedetuning_offis not, and there should be an easy way to find out what the chosen value was, which can then be used to correct for incurred phase changes with a phase shift, for example.The way to implement this is straightforward for a non-parametrized sequence (simply access the chosen value and return it), but what if the sequence is parametrized? There are two scenarios here:
amp_onanddetuning_onare not parametrized: In this case, we could still calculate the EOM parameters, with a method likecalculate_eom_parameters(). This is more flexible that just accessing the chosen values because when the sequence becomes parametrized they stop being calculated.amp_onand/ordetuning_onare parametrized: Here, we would have to somehow suspend the call tocalculate_eom_parameters(), returning a parametrized object instead. Although possible, it sounds overly complex. I propose we leave this for later, in case it is requested.Built-in phase correction
The usecase I currently have in mind could also be incorporated in
add_eom_pulse()and it would be available under any scenario. I'm thinking we could call itcorrect_phase: bool = False. At build-time, it would have all the information it needs for the correction.