lazyoracle
commented
3 years ago QuTiP has active projects for implementing GPU and TensorFlow backends to their Qobj. The QuTiP API is mature, extensible and widely used. It is feature-rich with introduction of the pulse level circuit simulation recently. I, for one, feel that there is strong incentive in increasingly porting our code to this style, essentially allowing any backends - a QuTiP backend, our own TensorFlow based simulator, a real hardware stack. That is the right direction that would enable we get to do all the nice C3 stuff while keeping it decoupled from the developments of the simulator/control stack etc.
shaimach
In many places in the code we need to pass information between classes and functions in libraries. The information we pass is (not comprehensive list): the dimension of the subspaces of the hilbert subspace, their order, the states computationally relevant, the representation (superoper/oper, state/density matrix/density vector). For example when doing propagation the experiment class asks the model class if lindblad is true, in which case the assumption is that we are using the superoper + density vector formalism, and hence different types of propagation and population calls are made.
Qutip solves some of these issues by having some of this information in the Qobj class and then you can just make the relevant calls, like population or fidelity calls, on the object and the underlying implementation will change based on the information the object itself provides. https://qutip.org/docs/latest/guide/guide-basics.html#the-quantum-object-class
I think this is the right way to move forward to allow the code to stay modular.
In general with the expansion of the propagation library and the recent improvements made on qutip to have noise (https://arxiv.org/abs/2105.09902) do we want to try for more compatability with QuTip?