-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore support for simulation #913
Comments
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 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.
The text was updated successfully, but these errors were encountered: