You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The present situation is fragmented, both at the Platform level (frontend) and Instrument level (backend), because of the historical way the hardware optimization landed in Qibolab.
Platform
The Platform implements the support for sequence unrolling, by differentiating:
(also notice how **kwargs enter the first two, and not the latter - but they are always unused, so we could well drop them).
We could reconcile the frontend by having a single Platform.execute(), doing both sweeps and unrolling, possibly at the same time.
The interface would be simply:
and the current three alternatives are obtained by passing a 1-element list for sequences, or no sweepers object, or both (I also wonder whether, for symmetry, we should have a list[Sweeper] - but that's a detail).
This will require some logic for the missing case of simultaneous sweep and unrolling. In particular, if a sequence containing sweepers is to be unrolled, we should definitely give the user the option to tell that is the same sweeper in all sequences, otherwise a nested loop will be attempted, as nested as the number of swept pulses fitting in the batch.
To make it possible, #692 will be needed.
For the time being, if multiple sequences will be passed, the potential sweepers should be unrolled (generating even more lists), which is simpler to implement, and does not require any change in the user code (on the contrary, the mark for sweepers identity will have to be explicitly inserted by the user).
Controller
At the backend level, we have the Controller.play() and Controller.sweep() methods. But they are already collapsed somewhere, e.g.
a suitable implementation of sweepers (with a proper recursion) for the other drivers will remove the necessity for the separation. At that point, we will just keep the Controller.play() with the strictly more general .sweep() interface.
The text was updated successfully, but these errors were encountered:
The present situation is fragmented, both at the
Platform
level (frontend) andInstrument
level (backend), because of the historical way the hardware optimization landed in Qibolab.Platform
The
Platform
implements the support for sequence unrolling, by differentiating:qibolab/src/qibolab/platform.py
Lines 193 to 195 in 47d1d55
qibolab/src/qibolab/platform.py
Lines 229 to 231 in 47d1d55
even if they are reconvened later on in
Platform._execute()
. Moreover, sweepers require the usage of a separate method:qibolab/src/qibolab/platform.py
Lines 269 to 271 in 47d1d55
(also notice how
**kwargs
enter the first two, and not the latter - but they are always unused, so we could well drop them).We could reconcile the frontend by having a single
Platform.execute()
, doing both sweeps and unrolling, possibly at the same time.The interface would be simply:
and the current three alternatives are obtained by passing a 1-element list for
sequences
, or nosweepers
object, or both (I also wonder whether, for symmetry, we should have alist[Sweeper]
- but that's a detail).This will require some logic for the missing case of simultaneous sweep and unrolling. In particular, if a sequence containing sweepers is to be unrolled, we should definitely give the user the option to tell that is the same sweeper in all sequences, otherwise a nested loop will be attempted, as nested as the number of swept pulses fitting in the batch.
To make it possible, #692 will be needed.
For the time being, if multiple sequences will be passed, the potential
sweepers
should be unrolled (generating even more lists), which is simpler to implement, and does not require any change in the user code (on the contrary, the mark for sweepers identity will have to be explicitly inserted by the user).Controller
At the backend level, we have the
Controller.play()
andController.sweep()
methods. But they are already collapsed somewhere, e.g.qibolab/src/qibolab/instruments/qm/driver.py
Lines 111 to 112 in 47d1d55
a suitable implementation of sweepers (with a proper recursion) for the other drivers will remove the necessity for the separation. At that point, we will just keep the
Controller.play()
with the strictly more general.sweep()
interface.The text was updated successfully, but these errors were encountered: