Better qubit and measurement lo interface

What is the expected enhancement?

I find the current lo interface confusing to use. I think it is a combination of naming and functionality. My main complaint is that:

• qubit_lo_freq and meas_lo_freq seem to serve the same purpose as schedule_los

This can be confusing for users. I think it may be better to replace qubit_lo_freq and meas_lo_freq by qubit_freq_est and meas_freq_est and then have the default behaviour to be too use these to create and pad schedule_los if not supplied. This way there is only one explicit behaviour to set the los for assembly (schedule_los).

Thoughts @nkanazawa1989 and @itoko?

[taalexander]

In general, this problem would be overcome if for each pulse channel we could specify the frame and sideband with which it should be applied. Then we could track these frames and sidebands separately (as we do already internally).

[nkanazawa1989]

I understand your point. I agree. We need to simplify the configuration of los. qubit_lo_freq and meas_lo_freq can be used to set los which is common in all experiments, while schedule_los is used to set los depending on experiment.

As far as I understand,

• (1) nothing this will set backend default qubit_lo_freq and meas_lo_freq as common configuration.

• (2) qubit_lo_freq and meas_lo_freq, without schedule_los this will set custom qubit_lo_freq and meas_lo_freq as common configuration.

• (3) single schedule_los, without qubit_lo_freq and meas_lo_freq this will set custom schedule_los as common configuration - just same as (2).

• (4) n schedule_los of the same frequencies, without qubit_lo_freq and meas_lo_freq this will set qubit_lo_freq and meas_lo_freq for each experiment configuration, but this will give the same configuration as above (just increasing the size of qobj).

• (5) qubit_lo_freq and meas_lo_freq, with n schedule_los this will overwrite backend default qubit_lo_freq and meas_lo_freq, and overwrite them by schedule_los in each experiment configuration.

now we have too many options to set lo configuration, and we should simplify this. As (3) can cover (2), we might be able to deprecate qubit_lo_freq and meas_lo_freq from arguments.

And I don’t like the name qubit_lo_freq because this can be intentionally detuned from qubit frequency and “qubit” doesn’t have a local oscillator (LO is bound to AWG). drive_freq and meas_freq sounds more natural to me.