Open alecandido opened 3 months ago
Instead of a platform, we could make a Qibocal backend wrapper.
This object will contain the Qibo backend for simulation, and execute circuits, rejecting pulses (but implementing the interface), while for Qibolab will contain (platform, compiler, transpiler)
, and it will execute pulses (just passing the call to the platform) and circuits (by transpiling, compiling, and eventually passing the call to the platform).
At least, there will be a single object around. And, hopefully, we won't need to access the platform that often (in the future, now need)
Current routines are tuned to work with a
Platform
, that is ending up in many places.There is no doubt that Qibolab is the main target of Qibocal, and to move faster I'd accept to support only that for a while. That's why I imposed the existence of a
Platform
in #909.However, running circuits routines in simulation, especially with a specified noise model (but sometimes even noiseless, for debugging) could be very useful. The proposed way to recover this feature is to wrap a Qibo backend in a
qibocal.SimulationBackend
, which will hold aqibocal.Platform
in the same way as theqibolab.QibolabBackend
(and it will respect theqibolab.Platform
interface - at least the part used within Qibocal, which we could define somewhere).This will allow applying all the routines on a simulation backend, and fail if and only if pulses are received.