Single shot acquisition mode

[alecandido]

The single shot averaging mode is alternative to the cyclic and sequential, but it is actually playing on a different dimension.
Specifically, the two averaging modes are specifying the position of the shots loop (as innermost or outermost), while the single shot mode is just telling not to average - but it says nothing about the loop position.

I'm assuming that AveragingMode.SINGLESHOT is actually equivalent to "no average + cyclic", placing the loop outermost in the Qblox driver (since looping the shots as the last iteration should be almost always advisable).
However, in principle, even the "no average + sequential" may be an available alternative. I assume there is no interest in that, and that we don't want to implement it. But we may want to document the exact meaning of the existing option (to avoid ambiguities).

(mainly for @stavros11, to sync the drivers - but opinions are welcome also from the Qibocal crowd, i.e. @andrea-pasquale @Edoardo-Pedicillo - and whoever in general)

[stavros11]

I'm assuming that AveragingMode.SINGLESHOT is actually equivalent to "no average + cyclic", placing the loop outermost in the Qblox driver (since looping the shots as the last iteration should be almost always advisable).

I confirm that this is the case for the QM driver too. I agree with documenting the meaning.

Other than, I also agree with pretty much everything in your comment. It is possible to implement the "no average + sequential" case in QM, but I am also not sure if there is interest in that and if it is possible on all other instruments. I should probably add that even the "sequential" (with average) is currently not implemented in QM, in fact it never was even for 0.1. Again, this should be possible to do, I guess I just didn't because I assumed there is no interest.

I don't fully remember why we have the AveragingMode.SEQUENTIAL in the first place. I think it was because there was a particular routine that ZI could not do with CYCLIC but I may be wrong.

In any case, there are multiple options: we could add "no average + sequential" and also properly implement "sequential" everywhere (if that is possible), however I wouldn't go for this as it could complicate (even a little) all drivers without being particularly useful. Alternatively, we could drop "sequential" completely, however this would be breaking, even though strictly speaking it's already broken as QM (the only driver) does not support it. Or leave as it is and plan (open issue) to implement it everywhere.

EDIT: It would even make sense to postpone these stuff for 0.3, if we are planning to expose loops in the interface in a more native way. Using weird keywords (sequential, cyclic) to specify loop order is not very intuitive from a user point of view.

[alecandido]

I should probably add that even the "sequential" (with average) is currently not implemented in QM, in fact it never was even for 0.1. Again, this should be possible to do, I guess I just didn't because I assumed there is no interest.

Ah, good to know. But a bit too late...

I thought I had to support all the existing modes, and I already implemented them in Qblox #1119
Anyhow: worst case, I already trained for 0.3 (since I had to do some gymnastics to make it general).

[stavros11]

Anyhow: worst case, I already trained for 0.3 (since I had to do some gymnastics to make it general).

Yes, this was exactly what I wanted to avoid, unless there is really interest in it.

[Edoardo-Pedicillo]

I have always found quite unintuitive how Qibolab handles the averaging modes, since as you point out the SINGLESHOT is acting differently from the others. So any attempts to make it clearer are welcome from my side.

Regarding "no average + sequential", at the moment I don't see any particular applications. But I think it could be more useful when conditionals will be integrated into Qibolab.

[alecandido]

So any attempts to make it clearer are welcome from my side.

I will open an issue for that. But it would be a breaking change (I see no other way round, unless we support a legacy averaging_mode and alternative specification as well). So, it's most likely postponed anyhow to 0.3.

[alecandido]

#1121