Fix compiler adding phases to flux pulses

[stavros11]

Current compiler adds the virtual-z phases to flux pulses in addition to the drive ones. This should not have any effect since flux pulses are DC, but it is probably better to remove to be on the safe side.

@igres26 I have not tested on hardware, but this should remove the frame rotations of the flux channel from the qua script.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.88%. Comparing base (49b6572) to head (a678413).

Additional details and impacted files

@@           Coverage Diff           @@
##              0.1    #1099   +/-   ##
=======================================
  Coverage   69.88%   69.88%           
=======================================
  Files          64       64           
  Lines        6880     6880           
=======================================
  Hits         4808     4808           
  Misses       2072     2072           

Flag	Coverage Δ
unittests	69.88% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alecandido]

Even fine. But as you said, they are DC pulses, so there is no modulation process involved, and no I and Q components. Being just a real number, the phase can only be ignored...

[stavros11]

Even fine. But as you said, they are DC pulses, so there is no modulation process involved, and no I and Q components. Being just a real number, the phase can only be ignored...

Regarding QM in particular, the issue is that when the driver sees relative_phase != 0 in the pulse, it adds the corresponding frame_rotation commands in the QUA program, regardless of the pulse type. I would expect these to have no effect for DC pulses, but as usual, I am not sure how the instrument behaves in this case, so the safest approach is to just drop these commands. Note that this PR doesn't really fix this issue, it only fixes it for circuit execution, which is where @igres26 discovered it. Users are still able to define FluxPulses with phases and these will cause the frame_rotation, but in that case I would say it is the user's responsibility.

The open question is whether we actually want to enforce zero-phases for DC or leave it up to the user. Worrying more about 0.2 (since 0.1 will soon be deprecated), I would probably leave it up to the user, because neither pulse types nor frequencies are in the Pulse, so the Pulse object itself has no information if its a DC or no (it depends on the channel it will play.

I would still make sure that the 0.2 compiler is correct in that regard, so basically just port this PR (if still needed).

Another option is to fix this internally in the QM driver (ignore .relative_phase for pulses playing on DC channels), however I am not a big fan of this approach because it is like quietly enforcing this and then we would also have to make sure that other drivers do the same.