Pulser
Pulser copied to clipboard
pasqal-io
Changing the device of a Sequence
It might be useful to switch the device of an already constructed sequence.
Off the top of my head, I can think of two main features here:
- Compatibility with the new device of each element in the sequence's schedule. This would be easier if the validation methods currently residing in
Sequencewere moved to theDeviceclass, where the constraints reside. - A systematic matching between the channels of different devices.
The construction of the Sequence class has since changed to store every relevant call that is made in its construction. As such, a device switch can instead be achieved by simply attempting to rebuild the sequence on the new device. This process will subject the creation to all checks that are normally in place.
Nonetheless, it is still necessary to design a systematic matching between hardware channels across different devices, because it should not be expected that they have the same name or exactly the same characteristics.
Hi @HGSilveri after reviewing the pulser sequence class, in order to switch devices, I finally decided to use all the different calls used while building the former sequence (stored in sequence._calls) then try to follow them with the target device and return only if there are no errors. What do you think about? Because modifying directly the former sequence will require more time because the validation methods are entangled in the sequence class.
Hi @Varda-star , that's I would go about it too, I agree with this approach. Still, don't forget that there is no requirement on the channels of the device having the same name, so you will need to develop some clever way of matching the channels between two devices by comparing the specs of each one.
With the two existing devices, channels have the same but the parameters are different actually.
With the two existing devices, channels have the same but the parameters are different actually.
Yes, there is no requirement associated with the name given to the channels, so that is not a valid criterium for comparison.
Yes, I just take into account the channel_id. From a given channel, I check if the channel_id is available on the target device, if so I declare the channel on the target device otherwise I stop the process.
Yes, I just take into account the channel_id. From a given channel, I check if the channel_id is available on the target device, if so I declare the channel on the target device otherwise I stop the process.
That's too restrictive, actually. Even if two channels don't have exactly the same specs, they can still be interchangeable in some cases.
By the way, when I was mentioning "channel names" before, I actually meant the IDs. There is no information or rule for the name given to the channel IDs, so it's not a valid comparison criteria. I could make a new device with a channel with exactly the same specs as rydberg_global on Chadoq2 and call it foo.
I got your point. In this case, I must find how it is possible to interchange two channels given their specs
Let's assume I replace channel A with channel B, channel A respecting a given criteria allowing this switch. To make the new sequence realising quite the same task as the former one, I will probably have to modify pulses too.
Let's assume I replace channel A with channel B, channel A respecting a given criteria allowing this switch. To make the new sequence realising quite the same task as the former one, I will probably have to modify pulses too.
Indeed, that might happen if e.g. the clock period is different between the channels, but it doesn't necessarily mean the results will be changed significantly. I think the way to handle this is to add a keyword argument to the conversion method, like strict=False, where if you set it to True it is more strict on the channel requirements.
Yes, I just take into account the channel_id. From a given channel, I check if the channel_id is available on the target device, if so I declare the channel on the target device otherwise I stop the process.
That's too restrictive, actually. Even if two channels don't have exactly the same specs, they can still be interchangeable in some cases. By the way, when I was mentioning "channel names" before, I actually meant the IDs. There is no information or rule for the name given to the channel IDs, so it's not a valid comparison criteria. I could make a new device with a channel with exactly the same specs as
rydberg_globalonChadoq2and call itfoo.
We can then make our decision on the pulser.channels classes, check whether it's Rydberg Global/local, Raman...
Yes, I just take into account the channel_id. From a given channel, I check if the channel_id is available on the target device, if so I declare the channel on the target device otherwise I stop the process.
That's too restrictive, actually. Even if two channels don't have exactly the same specs, they can still be interchangeable in some cases. By the way, when I was mentioning "channel names" before, I actually meant the IDs. There is no information or rule for the name given to the channel IDs, so it's not a valid comparison criteria. I could make a new device with a channel with exactly the same specs as
rydberg_globalonChadoq2and call itfoo.We can then make our decision on the pulser.channels classes, check whether it's Rydberg Global/local, Raman...
The addressing (global/local) and the basis (Rydberg, Raman, ...) are necessary criteria for two channels to match, there can't be any flexibility there. But I think we can allow some flexibility on the other parameters
There are three main points to verify:
- The Register
- Channels
- Pulses
- Register:
Shall I strictly end everything if there is one flaw e.g. one atom more than the target device capacity/ if some atom distance valid for the former register is no more valid for the target register... Shall I reconfigure the register? It might bring more issues than solutions...
There migth be cases where the structure is important, if we reconfigure we must preserve the structure. In case of a random configuration we must rescale the register