Open jpmoutinho opened 10 months ago
@Roland-djee I came back to this issue and played around with the related MR. I am unsure if it should be pursued. It's a huge amount of work to do the complete refactoring, and I think we already have the necessary knowledge on how to properly design a similar feature in the new block system that will avoid all the spaghetti in the current analog blocks.
@Roland-djee I came back to this issue and played around with the related MR. I am unsure if it should be pursued. It's a huge amount of work to do the complete refactoring, and I think we already have the necessary knowledge on how to properly design a similar feature in the new block system that will avoid all the spaghetti in the current analog blocks.
Hey, indeed. I would focus on something currently more pressing if this is going to be solved in the new block system.
Currently there are a lot of definitions in the internal structure of the analog blocks.
The most user facing are defined as python functions that return an instance of a class:
AnalogRX
,AnalogRY
,AnalogRZ
for a specific axis rotationAnalogRot
which is the general version of the above with control over all Hamiltonian parametersAnalogInteraction
which free-evolves the intercation termThe functions above return an instance of:
ConstantAnalogRotation
InteractionBlock
And then these classes have an actual implementation in the backends, where for pyqtorch they get converted into an instane of
HamEvo
, and for Pulser they get translated into a pulse sequence.To simplify, we could simply have the user-facing operations themselves be defined as classes and possibly get rid of the "intermediate" blocks.
Relevant issues to keep in mind:
AnalogRX
,AnalogRY
,AnalogRZ
(and "global" qubit support), but would be harder to implement.ConstantAnalogRotation
andInteractionBlock
(partially because these accept a "global" qubit support).