GPU-accelerate time-dependent propagation (propagate/propagate_step) - #33
Draft
JackWetherell wants to merge 1 commit into
Draft
Conversation
Add GPU=False parameter to propagate() and propagate_step() across all methods, mirroring the existing GPU flag pattern used in the interacting solver (hamiltonian/solve). interacting.py: - Add _gpu_expm_action(): Arnoldi/Krylov iteration that approximates exp(c·A)@v using GPU sparse matrix-vector products (CuPy CSR) and a small dense Hessenberg expm computed on CPU via scipy. - propagate_step(GPU=False): when GPU=True, builds the many-body Vptrb operator with cupyx.scipy.sparse, assembles Hp on GPU, then evolves the wavefunction with _gpu_expm_action instead of expm_multiply. - propagate(GPU=False): passes GPU flag to hamiltonian() so H is constructed on GPU, creates a CuPy sparse identity for the Kronecker product helpers, and prints the GPU device name. non_interacting.py: - propagate_step(GPU=False): when GPU=True, transfers the N×N Hamiltonian to CuPy, performs a single eigh() diagonalisation per spin channel, then applies exp(-i dt e) analytically to every orbital (exact for Hermitian H, avoids repeated expm_multiply calls). - propagate(GPU=False): prints GPU device name and forwards GPU flag to propagate_step. Wrapper methods (hartree, hartree_fock, lda, hybrid, kssce): - Add GPU=False parameter and forward it to non_interacting.propagate. https://claude.ai/code/session_01TiMh7h9Hdmsdtv8S7TrUtT
JackWetherell
marked this pull request as draft
March 22, 2026 08:03
Member
Author
|
@DrMattHodgson I will test this change for GPU performance on the time-dependent code, but do the TD unit tests cover things sufficiently that if they pass I assume it has not changed the result? Cheers! |
Contributor
|
@JackWetherell I would think so. The test compares the one-electron wavefunction from the many-body code to the analytic solution at each time step. So, it doesn't test the interaction at all, and it's limited to the harmonic oscillator with a uniform perturbation, but if your GPU acceleration introduces a bug, I think it would affect all systems and, hence, be caught. |
Member
Author
|
@DrMattHodgson Ok great! I will run some benchmarks locally! |
Member
Author
|
@JackWetherell to resolve conflicts. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add GPU=False parameter to propagate() and propagate_step() across all methods, mirroring the existing GPU flag pattern used in the interacting solver (hamiltonian/solve).
interacting.py:
non_interacting.py:
Wrapper methods (hartree, hartree_fock, lda, hybrid, kssce):
https://claude.ai/code/session_01TiMh7h9Hdmsdtv8S7TrUtT