Skip to content

GPU-accelerate time-dependent propagation (propagate/propagate_step) - #33

Draft
JackWetherell wants to merge 1 commit into
iDEA-org:masterfrom
JackWetherell:claude/gpu-accelerate-propagation-79imw
Draft

GPU-accelerate time-dependent propagation (propagate/propagate_step)#33
JackWetherell wants to merge 1 commit into
iDEA-org:masterfrom
JackWetherell:claude/gpu-accelerate-propagation-79imw

Conversation

@JackWetherell

Copy link
Copy Markdown
Member

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

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 JackWetherell self-assigned this Mar 22, 2026
@JackWetherell JackWetherell added enhancement New feature or request Claude Written using Claude Code labels Mar 22, 2026
@JackWetherell
JackWetherell marked this pull request as draft March 22, 2026 08:03
@JackWetherell

Copy link
Copy Markdown
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!

@DrMattHodgson

Copy link
Copy Markdown
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.

@JackWetherell

Copy link
Copy Markdown
Member Author

@DrMattHodgson Ok great! I will run some benchmarks locally!

@JackWetherell

Copy link
Copy Markdown
Member Author

@JackWetherell to resolve conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Claude Written using Claude Code enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants