Errors in routines sweeping pulse durations

[aorgazf]

Hi, Several routines that sweep qubit drive pulse duration do not adjust the start of the readout pulse.

• [ ] rabi_length_msr
• [ ] rabi_length
• [ ] t2
• [ ] t2_msr

Example from rabi_length_msr:

def _acquisition(
    params: RabiLengthVoltParameters, platform: Platform, qubits: Qubits
) -> RabiLengthVoltData:
    r"""
    Data acquisition for RabiLength Experiment.
    In the Rabi experiment we apply a pulse at the frequency of the qubit and scan the drive pulse length
    to find the drive pulse length that creates a rotation of a desired angle.
    """

    # create a sequence of pulses for the experiment
    sequence = PulseSequence()
    qd_pulses = {}
    ro_pulses = {}
    amplitudes = {}
    for qubit in qubits:
        # TODO: made duration optional for qd pulse?
        qd_pulses[qubit] = platform.create_qubit_drive_pulse(
            qubit, start=0, duration=params.pulse_duration_start
        )
        if params.pulse_amplitude is not None:
            qd_pulses[qubit].amplitude = params.pulse_amplitude
        amplitudes[qubit] = qd_pulses[qubit].amplitude

        ro_pulses[qubit] = platform.create_qubit_readout_pulse(
            qubit, start=qd_pulses[qubit].finish
        )
        sequence.add(qd_pulses[qubit])
        sequence.add(ro_pulses[qubit])

    # define the parameter to sweep and its range:
    # qubit drive pulse duration time
    qd_pulse_duration_range = np.arange(
        params.pulse_duration_start,
        params.pulse_duration_end,
        params.pulse_duration_step,
    )

    sweeper = Sweeper(
        Parameter.duration,
        qd_pulse_duration_range,
        [qd_pulses[qubit] for qubit in qubits],
        type=SweeperType.ABSOLUTE,
    )

[andrea-pasquale]

This is mostly a qibolab related issue. For some electronics these protocols are already working I believe. Any ideas on how to fix it @stavros11?

[stavros11]

We need a better interface for the Sweeper to address these issues, that's why I opened qiboteam/qibolab#650.

Indeed currently these routines are working with some drivers because we are automatically pushing the readout when sweeping the duration/start time of the drive before it. But we need a way to let the user select if this happens or no, because there are routines such as the cryoscope where we are sweeping duration but the readout starts at a fixed time in the end (and is not pushed).

I would say the actions are the following:

• propose a better sweeper interface to capture pulse relations,
• update the drivers to comply with it,
• update qibocal to comply with the new interface.

I agree it is a qibolab issue, small updates may be required on qibocal depending on the interface and default behavior.

[aorgazf]

An alternative solution that would not require to capture relations between pulses is to enhance Sweeper class so that more than one thing can be swept simultaneously. If you opt for implementing pulse relations, I would do it in the Pulse PulseSequence library, not in the Sweeper class.

[andrea-pasquale]

Closing this as already present in the first bullet point of https://github.com/qiboteam/qibolab/issues/650. Please open issues similar to those in qibolab and when providing an example to reproduce the error refer to qibocal.

[aorgazf]

Hi Andrea, I hope you do not mind me reopening this issue, as it was raised in Nov 2023 and as of today the matter is not resolved, neither in qibocal nor in qibolab. There are ways in which the routines in qibocal could be modified to temporarily resolve the problems until qibolab supports more advanced sweepers. You can have a look at how those issues were fixed in my qibocal branch alvaro/latest_20231215.

[alecandido]

Hi @aorgazf, in the meanwhile I reraised the issue, unaware of this one #891.

As it is described there, there is no proper way for Qibocal to unambiguously specify the readout start when a duration sweeper is used. This is something that is planned to be fixed with Qibolab 0.2 (I'd have liked to fix it immediately in 0.1, but that has always been part of 0.2, as a breaking change).