As pointed out in #353 , the handling of the qutip Qobj type by DYNAMICS_NUMPY.asarray was broken with the release of qutip 5.0.0. In the past, qutip Qobj instances always contained customized csr_matrix instances, so we would always consume them by explicitly converting them to a csr_matrix. Qutip 5.0.0 adds a "data layer" abstraction, allowing Qobj instances to store different underlying array types (e.g. dense np.ndarray). This data layer has been written to be extensible, and hence moving forward we have no guarantees on the type of array data within a Qobj.
As a result of this, I've changed DYNAMICS_NUMPY.asarray(qobj) to return qobj.full(), which returns a dense np.ndarray. This works regardless of underlying array type, so seems like a safe future-proof way of solving this issue.
Details and comments
I've also added an upgrade note outlining this change.
Summary
As pointed out in #353 , the handling of the qutip
Qobjtype byDYNAMICS_NUMPY.asarraywas broken with the release of qutip 5.0.0. In the past, qutipQobjinstances always contained customizedcsr_matrixinstances, so we would always consume them by explicitly converting them to acsr_matrix. Qutip 5.0.0 adds a "data layer" abstraction, allowingQobjinstances to store different underlying array types (e.g. densenp.ndarray). This data layer has been written to be extensible, and hence moving forward we have no guarantees on the type of array data within aQobj.As a result of this, I've changed
DYNAMICS_NUMPY.asarray(qobj)to returnqobj.full(), which returns a densenp.ndarray. This works regardless of underlying array type, so seems like a safe future-proof way of solving this issue.Details and comments
I've also added an upgrade note outlining this change.