Make PulseSequence modular by subclassing
Opened this issue · 1 comments
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
PulseSequencescould be implemented in analog toRepetitionPTso 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
MappingPTandAtomicMultiChannelPT. - 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).