Bug in envelope_waveform_q method for Drag pulse

[jykhoo1987]

There is a bug with the envelope_waveform_q method of the Drag pulse. Its values are suppressed by the inverse of the sampling rate. The bug can be reproduced as follows:

from qibolab.pulses import Drag, DrivePulse
import matplotlib.pyplot as plt
import numpy as np

pulse1 = DrivePulse(start=0, duration=80, amplitude=1, frequency=5e9, relative_phase=0, shape=Drag(4,4))

for sampling_rate in [1,10]:
    t = np.linspace(0,80,80*sampling_rate)
    plt.plot(t, pulse1.envelope_waveform_i(sampling_rate).data, c='b')
    plt.plot(t, pulse1.envelope_waveform_q(sampling_rate).data*sampling_rate, c='k', linestyle='--', )
    plt.plot(t, pulse1.envelope_waveform_q(sampling_rate).data, c='r')

In this case we see that envelope_waveform_i (blue) is behaving properly for different values of sampling_rate but envelope_waveform_q (red) in the sampling_rate=10 case is much smaller. To fix this, the output of envelope_waveform_q needs to be multiplied by the sampling_rate (black dashed).

[alecandido]

Ok, the problem may be a bit indirect.

So, you're currently spotting the problem because you're attempting to keep the shape constant, while changing the sampling rate.
The sampling rate does not appear explicitly anywhere in the envelope. However, it is relevant through the duration, since that is effectively expressed as the number of samples, and not nanoseconds.
You don't see the problem in the I component because the width is also expressed in terms of samples, so the two things compensate each other. But when you change the sampling rate, you're actually also changing the duration in nanoseconds.

The result is apparent on Q, but, at this point, that's expected, since the derivative is done in actual time, not in samples. Thus, you're picking up a factor from the derivative because of the change of variables (which is actually the sampling rate), and that's what you see in your plot.

In 0.2, all the variables are expressed relative to the interval duration. However, the duration is expressed in nanoseconds, and the number of samples is dependent on the sampling rate. So, you should not see this "problem".

I'm not even sure if I would classify as an actual issue. Maybe the parametrization is not optimal (and it's already different in the new version), but it's possibly subjective...