Skip to content

Fix stale install dirs of fetched dependencies; split the Gaussian-nucleus quadrature at the nuclear scale - #357

Merged
susilehtola merged 2 commits into
masterfrom
fetch-cache-and-nucleus-quadrature
Oct 5, 2026
Merged

susilehtola merged 2 commits into
masterfrom
fetch-cache-and-nucleus-quadrature

Conversation

@susilehtola

Copy link
Copy Markdown
Owner

Two independent fixes, one commit each.

1. Fetched dependencies' install locations are no longer frozen by an old build tree

A build tree first configured before the private dependency layout (#354) kept installing OpenOrbitalOptimizer's package config to lib64/cmake/OpenOrbitalOptimizer. helfemConfig.cmake only looks under lib/helfem-deps, so find_package(helfem) failed for every consumer of the install.

The cause: OpenOrbitalOptimizer computes OpenOrbitalOptimizer_INSTALL_CMAKEDIR from CMAKE_INSTALL_LIBDIR once, caches it, and from then on reads the cached value back. Eigen does the same with INCLUDE_INSTALL_DIR, CMAKEPACKAGE_INSTALL_DIR and PKGCONFIG_INSTALL_DIR. Those are generic names, so they also landed in an including project's cache. libxc does the same with FORTRAN_MODULE_INSTALL_DIR. helfem_fetch_privately now takes these variables after an INSTALL_DIRS keyword and clears them both before and after the fetch.

To verify, I seeded the stale values on the command line and hid the system Eigen, wignernj and libxc, so all five dependencies were fetched:

  • master still uses lib64/cmake/... and keeps all four variables cached;
  • with this change, every package config installs under lib/helfem-deps and nothing installs outside the expected directories;
  • two consumers of the install build and run.

2. Gaussian nucleus: the quadrature is split at the nuclear scale

-Z erf(μr)/r turns over at r ~ 1/μ, about 1e-4 bohr, which is a thousand times smaller than the first element. The order refinement only resolved that by brute force. For Ne with the Visscher-Dyall Rrms (20-node LIP, 6 elements) it hit the order cap (n=512, relative change still 2.1e-12).

GaussianNucleusT now reports breakpoints at 2^k/μ, doubling until erfc(2^k) < eps(T). Beyond the last one the integrand is polynomial again. The same calculation now prints no warning and converges to the same energy, -128.5470607586 Eh. The spherical and hollow nuclei already split at their radius.

ctest -L unit passes (11/11).

🤖 Generated with Claude Code

susilehtola and others added 2 commits October 5, 2026 15:37
A build tree configured before the private dependency layout (da6b491)
kept installing OpenOrbitalOptimizer's package config to
lib64/cmake/OpenOrbitalOptimizer, outside lib/helfem-deps where
helfemConfig.cmake looks for it, so find_package(helfem) failed for every
consumer of the install.

OpenOrbitalOptimizer derives OpenOrbitalOptimizer_INSTALL_CMAKEDIR from
CMAKE_INSTALL_LIBDIR once and caches it; every later configure reads the
cached value back, so pointing CMAKE_INSTALL_LIBDIR at the private tree
during the fetch does nothing to a tree that cached it earlier. Eigen
does the same with INCLUDE_INSTALL_DIR, CMAKEPACKAGE_INSTALL_DIR and
PKGCONFIG_INSTALL_DIR -- generic names that also sat in an including
project's cache -- and libxc with FORTRAN_MODULE_INSTALL_DIR. wignernj
and OpenTrustRegion cache none.

helfem_fetch_privately now takes these after an INSTALL_DIRS keyword and
clears them before the fetch, so they are derived from the private layout
every time, and after it, so they never persist.

Verified with the stale values seeded on the command line and the system
Eigen, wignernj and libxc hidden, so all five dependencies are fetched:
master still reports lib64/cmake/OpenOrbitalOptimizer and keeps all four
variables cached; with this change the configure reports
lib/helfem-deps/lib/cmake/OpenOrbitalOptimizer, none of the four remains
in the cache, every package config installs under lib/helfem-deps,
nothing installs outside include/helfem, lib/helfem-deps, lib/cmake/helfem,
bin and the top-level archives, and two consumers of the install (one
through helfem::fem, one through helfem::helfem-common and libxc) build
and run.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A Gaussian nucleus made the first element's potential matrix hit the
quadrature order cap. Ne with the Visscher-Dyall Rrms (5.37e-5 bohr),
LIP with 20 nodes, 6 elements:

  Warning: FiniteElementBasis::matrix_element (element 0, r in
  [0, 0.108663], reference panel [-1, 1]) hit the quadrature order cap
  (n=512) without converging to eps; using the best estimate.
    block magnitude 1.672e+01, relative change still 2.144e-12

-Z erf(mu r)/r has no kink, but it turns from constant to Coulomb around
r ~ 1/mu, about 1e-4 bohr -- a thousand times smaller than the element --
and order refinement over the whole element resolves that only by brute
order. RadialBasis' comment counted the Gaussian among the models that
converge by refinement alone; that holds for smoothness, not for scale.

GaussianNucleusT now reports breakpoints at 2^k/mu, doubling until
erfc(2^k) < eps(T): {1, 2, 4, 8}/mu in double, and one step further in
quad precision. Beyond the last one V = -Z/r to working precision, so the
integrand is polynomial there again. The spherical and hollow nuclei
already split at their radius.

The same Ne calculation now prints no warning and converges to the same
energy as before, -128.5470607586 (point nucleus: -128.5470981094).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@susilehtola
susilehtola merged commit 728e8d1 into master Oct 5, 2026
1 check passed
@susilehtola
susilehtola deleted the fetch-cache-and-nucleus-quadrature branch October 5, 2026 14:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant