Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/qutip/qutip/issues/2530 below:

Slow brmesolve() for certain problems & bloch-redfield tensor always returned Dense · Issue #2530 · qutip/qutip · GitHub

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

so this call to from_eigbasis() in _brtools always returning a dense object

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.

R = bloch_redfield_tensor(H, [[Q, Lor]], fock_basis=True, sparse_eigensolver=True, br_dtype='sparse')
print(R.dtype)

<class 'qutip.core.data.dense.Dense'>

Sparse tensor and fast brmesolve!

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)

No response

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4