You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace get_v3, get_odd_straight and gradient Fortran calls with numpy matrix products
Profiling the PdH 4x4x4 example showed these three SCHAModules
routines spending their time in serial loops that are really
matrix products:
- get_v3: 13.8 s -> 0.9 s (averaged one chunk of configurations at
a time to bound memory; the per-element error the Fortran routine
computed was never returned to the callers and is skipped)
- get_odd_straight: 22.9 s -> 1.4 s
- get_gradient_supercell_new: 0.47 s -> 0.16 s at N = 1000 (its
OpenMP pragmas are commented out upstream)
The helpers reuse the Fortran get_emat, get_g and
get_upsilon_matrix for the small input matrices. All outputs match
the old implementation to 1e-14 on the PdH ensemble. The include_v4
and fast_grad branches are unchanged, and the replaced Fortran
routines are left in place.
The speedups do not depend on numpy's threaded BLAS. On a 120-atom
test cell forced to a single thread (like a one-core cluster job):
get_v3 102 s -> 2.6 s (the Fortran OpenMP also drops to one core),
get_odd_straight 13.0 s -> 2.3 s, gradient 0.35 s -> 0.07 s.
With the matching CellConstructor change the PdH hessian example
goes from 224 s to 24 s (peak memory 1.5 -> 3.4 GB).
Signed-off-by: Patrick Avery <patrick.avery@kitware.com>
0 commit comments