Currently, Qibocal is defining acquisition in an imperative way, by doing as many calls as needed to .execute_pulse_sequence()/.execute_pulse_sequences()/.sweep() as needed.
However, experiment should be reproducible, even independently of the code that generated them.
For this reason, it would be nice to declare everything that could affect an experiment result.
Other than pulses, the only thing affecting the results are instruments parameters, and they could be changed in two different ways:
at the beginning of the time
between two subsequent sequences/experiments
The first kind is accounted for by the Platform serialization, but the second one has no other (declarative) option than producing multiple Platforms and running multiple experiments.
This could be inconvenient to define a single acquisition in Qibocal, and thus the only way left is to change parameters imperatively.
If updating parameters in a single acquisition becomes useful, I'd propose to create some Update events to be added to a Sequence (or a wrapper of multiple sequences, like the list[Sequence] that will be passed to .execute()), with a clear timing with respect to the Pulses played.
The added benefit is that routines' acquisitions will be fully serializable, and the execution will be applied by the Qibocal Executor, and not by the individual routines (which instead you could query for the experiment, and in principle even draw...).
Currently, Qibocal is defining acquisition in an imperative way, by doing as many calls as needed to
.execute_pulse_sequence()
/.execute_pulse_sequences()
/.sweep()
as needed.However, experiment should be reproducible, even independently of the code that generated them.
For this reason, it would be nice to declare everything that could affect an experiment result. Other than pulses, the only thing affecting the results are instruments parameters, and they could be changed in two different ways:
The first kind is accounted for by the
Platform
serialization, but the second one has no other (declarative) option than producing multiplePlatform
s and running multiple experiments. This could be inconvenient to define a single acquisition in Qibocal, and thus the only way left is to change parameters imperatively.If updating parameters in a single acquisition becomes useful, I'd propose to create some
Update
events to be added to aSequence
(or a wrapper of multiple sequences, like thelist[Sequence]
that will be passed to.execute()
), with a clear timing with respect to thePulse
s played.The added benefit is that routines' acquisitions will be fully serializable, and the execution will be applied by the Qibocal
Executor
, and not by the individual routines (which instead you could query for the experiment, and in principle even draw...).