Skip to content
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

Use diagonalization instead of scipy.expm in the cases where it's faster (matrix dim <~ 1600) #83

Open
miamico opened this issue Feb 10, 2022 · 0 comments
Labels
Changelog: New Feature Include in the "Added" section of the changelog enhancement New feature or request

Comments

@miamico
Copy link

miamico commented Feb 10, 2022

What is the expected behavior?

When taking the matrix exponential of an Hermitean matrix $M$ (for example to compute the time evolution operator from the Hamiltonian of a closed system) it is sometimes faster to first diagonalize the matrix $M = V D V^{dagger}$ and then exponentiate the diagonal matrix $D$ (which is given by exponentiating the diagonal elements) instead of using the built-in method in scipy expm directly on the matrix $M$.

Since fixed-step solvers are meant to work for arbitrary generators (even ones that cannot be diagonalized) but this method is faster for diagonalizable generators (in particular anti-hermitian), then it would be worth adding this implementation as an option for the user and to choose this option automatically in some higher level interfaces (e.g. when using a Solver instance that only has Hamiltonian information).

Possible implementation details:
Add the option to the core solver method, and add a check in the solve_lmde interface that if what's being simulated is a HamiltonianModel object, and the dim of the initial state is below some heuristically-set level, then it automatically uses the diagonalization method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: New Feature Include in the "Added" section of the changelog enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants