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
Right now, when concatenating, remapping or extending PulseSequences, information about the constituent instances is not retained in the resulting PulseSequence. This has several drawbacks:
It is impossible to retroactively compute the pulse correlation filter function of a composite pulse after the concatenation has been carried out as the control matrices of the concatenated pulses are not copied over to the new pulse.
Similarly, the user has to decide at the moment of concatenation if they want to efficiently compute the filter function. Exploiting the concatenation property of the filter functions is not possible after the fact.
Periodic concatenation of a pulse stores all time steps and coefficients explicitly in the new PulseSequence. This can take up a significant amount of memory for basically redundant information.
Extending the current structure by subclassing PulseSequence would address these issues on top of being more readable and transparent. Additionally, this would enable interfacing with qupulse in a very straightforward manner by mirroring its class structure:
Concatenating periodic PulseSequences could be implemented in analog to RepetitionPT so that only the atomic pulse needs to be stored.
Remapping and extending pulses to different qubits as well as joining different instances to a single one could be implemented in analog to MappingPT and AtomicMultiChannelPT.
Regular concatenation could be implemented in analog to SequencePT.
This structure would also allow for a PulseSequence instance (or rather subclass thereof) to intelligently parse its composition and decide the most efficient way of calculating the filter function (from scratch, by concatenation, etc). Accordingly, it should be possible without too much effort to derive a PulseSequence from a PulseTemplate and connect it to a virtual_awg, enabling live introspection of pulses designed with qupulse (including for example AWG transfer functions).
The text was updated successfully, but these errors were encountered:
Right now, when concatenating, remapping or extending
PulseSequence
s, information about the constituent instances is not retained in the resultingPulseSequence
. This has several drawbacks:PulseSequence
. This can take up a significant amount of memory for basically redundant information.Extending the current structure by subclassing
PulseSequence
would address these issues on top of being more readable and transparent. Additionally, this would enable interfacing withqupulse
in a very straightforward manner by mirroring its class structure:PulseSequences
could be implemented in analog toRepetitionPT
so that only the atomic pulse needs to be stored.MappingPT
andAtomicMultiChannelPT
.SequencePT
.This structure would also allow for a
PulseSequence
instance (or rather subclass thereof) to intelligently parse its composition and decide the most efficient way of calculating the filter function (from scratch, by concatenation, etc). Accordingly, it should be possible without too much effort to derive aPulseSequence
from aPulseTemplate
and connect it to avirtual_awg
, enabling live introspection of pulses designed withqupulse
(including for example AWG transfer functions).The text was updated successfully, but these errors were encountered: