Bug Description
I updated some old code from v4.7 to v5 this week and found some examples of brmesolve which were substantially slower... going from 30 seconds to 15+ minutes. Fiddling around a little I narrowed it down to at least one issue (though there may be others). This is particularly tricky because I also have examples which are substantially faster in v5.
The one issue I found was that bloch_redfield_tensor() always returns a dense bloch-redfield tensor, even if you set br_type to sparse. It does return a sparse one if fock_basis=false, which points at the issue being
|
return self.H.from_eigbasis(t, BR_eig) |
so this call to from_eigbasis() in _brtools always returning a dense object
|
cpdef Data from_eigbasis(self, double t, Data eig): |
if i manually convert the tensor back to sparse again, and use it, it speeds up these hard cases by a factor of 5 or 6. Not sure if it resolves my original 30seconds -> 15 minutes problem completely, will check a bit more.
In some sense this relates to the old issue of how broadly default_dtype should be applied, but here it seems more specific in that one requests a sparse tensor and gets a dense one.
Code to Reproduce the Bug
R = bloch_redfield_tensor(H, [[Q, Lor]], fock_basis=True, sparse_eigensolver=True, br_dtype='sparse')
print(R.dtype)
Code Output
<class 'qutip.core.data.dense.Dense'>
Expected Behaviour
Sparse tensor and fast brmesolve!
Your Environment
QuTiP Version: 5.1.0.dev0+8efc188
Numpy Version: 2.0.1
Scipy Version: 1.14.0
Cython Version: 3.0.11
Matplotlib Version: 3.9.1.post1
Python Version: 3.10.12
Number of CPUs: 28
BLAS Info: Generic
INTEL MKL Ext: False
Platform Info: Linux (x86_64)
Additional Context
No response
Bug Description
I updated some old code from v4.7 to v5 this week and found some examples of brmesolve which were substantially slower... going from 30 seconds to 15+ minutes. Fiddling around a little I narrowed it down to at least one issue (though there may be others). This is particularly tricky because I also have examples which are substantially faster in v5.
The one issue I found was that bloch_redfield_tensor() always returns a dense bloch-redfield tensor, even if you set br_type to sparse. It does return a sparse one if fock_basis=false, which points at the issue being
qutip/qutip/core/_brtensor.pyx
Line 281 in 0b4260e
so this call to from_eigbasis() in _brtools always returning a dense object
qutip/qutip/core/_brtools.pyx
Line 290 in 0b4260e
if i manually convert the tensor back to sparse again, and use it, it speeds up these hard cases by a factor of 5 or 6. Not sure if it resolves my original 30seconds -> 15 minutes problem completely, will check a bit more.
In some sense this relates to the old issue of how broadly default_dtype should be applied, but here it seems more specific in that one requests a sparse tensor and gets a dense one.
Code to Reproduce the Bug
R = bloch_redfield_tensor(H, [[Q, Lor]], fock_basis=True, sparse_eigensolver=True, br_dtype='sparse') print(R.dtype)Code Output
Expected Behaviour
Sparse tensor and fast brmesolve!
Your Environment
Additional Context
No response