[CleverPhysician]

rVV10 nonlocal correlation through libvdwxc

dft_functional rvv10 selects rPW86 exchange, PBE correlation and the rVV10 nonlocal correlation (Sabatini, Gorni and de Gironcoli, PRB 87, 041108(R) (2013); b = 6.3, C = 0.0093). The kernel and convolution come from libvdwxc (rVV10 API from merge request !32, commit 94410eb).

Implementation

• XC_Functional::set_xc_type maps the short name RVV10 to {XC_GGA_X_RPW86, XC_GGA_C_PBE} and the nonlocal parameters nlc_b, nlc_c (named after libxc's fields), reset on every call and saved by ScopedType.
• XC_Functional::v_xc adds the nonlocal term after v_xc_libxc when nlc_b > 0. Existing callers of v_xc, including PotXC and the NLCC force code, receive the same nonlocal correction. No source_estate changes remain relative to develop 8e20175.
• vdw::add_rvv10 (source_hamilt/module_vdw/nonlocal_xc.{h,cpp}, compiled into the XC library when ENABLE_LIBVDWXC is on) forms the total density and its plane-wave gradient, collects the grid on the pool root with Parallel_Common send/recv, calls the serial libvdwxc API with a per-call handle, and adds energy, potential and vtxc in Ry. Left-handed cells are inverted before the call because libvdwxc integrates with the signed volume.
• Not supported, rejected when INPUT is read: stress (cell relaxation, NPT), DFPT and LR-TDDFT forces. Runtime checks in stress_gga and init_dfpt back this up.
• INPUT behavior: dft_functional rvv10 replaces the earlier xc_nonlocal parameter; no new INPUT key is added. The dft_functional metadata is updated in its existing registration.

Build

ENABLE_LIBVDWXC is a cmake_dependent_option on ENABLE_LIBXC; find_package(libvdwxc CONFIG REQUIRED) needs libvdwxc's CMake build. Same pattern as DFT-D4: compile definition, build info, --info line, docs/advanced/install.md, docs/CITATIONS.md. The legacy Makefile does not build the feature.

Tests

Recorded cluster validation for the source changes in 256d216 used GCC 11.5.0, OpenMPI 4.1.1, Libxc 6.2.2, standalone FFTW 3.3.11 and libvdwxc 94410eb:

• PW with libvdwxc enabled: build passed; CTest 14/14, comprising MODULE_HAMILT_nonlocal_xcTest at 1 and 2 ranks, the existing vdW test and 11 selected XC CTest entries.
• PW with libvdwxc disabled: build passed; CTest 12/12; dft_functional rvv10 was rejected with the intended build-support diagnostic; semilocal SCF passed.
• LCAO with libvdwxc enabled: build passed; the additional CTest selection passed 5/6. MODULE_LR_pot_hxc_lrtd stopped because the loaded Libxc did not provide KXC for Slater exchange.
• The new adapter tests cover short-name selection and ScopedType restoration, parity with direct libvdwxc calls, spin channels, distributed vs complete grids (an uneven 5+4 z split at two ranks), finite-difference potential, oblique and left-handed cells, and v_xc for RVV10 vs the semilocal result plus the nonlocal term.
• Added MODULE_IO_read_input_serial.Rvv10RejectsStressDfptAndLrForces; this reader regression is not part of the archived CTest selections above. Separate runtime cases confirmed early rejection of stress, cell relaxation and DFPT.
• In the Si energy comparisons at scf_thr=1e-10, PW energies differ by at most 1.4e-11 eV across 1, 2 and 4 ranks, and by 4.1e-11 eV across nspin=1,2,4 for nonmagnetic Si at two ranks. The tested LCAO 1/2-rank and nspin=1,2 cases agree within 1.3e-11 eV. These are separate comparisons, not a complete rank-by-spin matrix.
• Right- and left-handed listings of the same Si cell agree within 1e-13 eV. For the tested Si NLCC force component, the finite-difference errors are 1.2e-4 eV/angstrom (PW) and 1.1e-3 eV/angstrom (LCAO), comparable to the semilocal controls (1.4e-4 and 1.4e-3 eV/angstrom, respectively).

Checks not run in this validation: GPU builds, ELPA-based LCAO solvers, USPP with rVV10, and an independent material SCF reference comparison. Hosted CI does not enable the optional libvdwxc backend; results for the previous head do not certify 256d216.

Open points for the maintainers

• Depends on an unreleased libvdwxc revision until MR !32 is released.
• Follow-ups: stress (libvdwxc MR !32 provides vdwxc_stress), and libxc's own *_RVV10 functionals through xc_nlc_coef.
• The adapter header includes <tuple> for the result-tuple declaration; Charge and ModuleBase::matrix are forward-declared.

🤖 Generated with Claude Code

[CleverPhysician]

Update after the hosted checks completed:

• The standard upstream workflow is green: 18/18 checks passed on head f3d41ad55ed53abb18ec8953d64df805d926dedd.
• The serial intern004 validation remains green: the libvdwxc adapter test passed 1/1 and the minimal CPU/PW/nspin=1 Si SCF converged with the recorded energy and density checks.
• This revision addresses the main concerns from feat: add restricted rVV10 plane-wave support #8031: semilocal and nonlocal XC are separate inputs, the host side uses a generic additive component, and rVV10-specific numerical work is kept behind the thin libvdwxc adapter rather than duplicated in the generic XC evaluator.
• Following the pattern of merged Add optional DFT-D4 support #7380, the PR now includes explicit dependency/build commands, user-facing INPUT documentation, citations, unit coverage, and an honest statement of checks not run.

The PR remains Draft while the maintainer confirms the staged CPU/serial/nspin=1 scope and while the QE same-density reference comparison (including gradient/divergence sign and normalization) is completed. libvdwxc MR !32 is still a Draft dependency, so I am not presenting it as a stable release.

[Growl1234]

The pinned libvdwxc Draft branch's own rvv10.serial test is not fully green: 7/8 CTest groups passed and 69 finite-difference/strain checks fail at roughly 1e-6--1e-5. This is reported as a dependency-side Draft issue, not hidden.

Could you provide the detailed information?

Another side note: libvdwxc currently requires FFTW-MPI wrapper when MPI is enabled, so be careful with MKL; for now you can consider adding a USE_FFTW3_WITH_MKL that use MKL Blas/lapack/scalapack but standalone FFTW library, but I'm in progress of refactoring its FFT backend and dropping the direct FFTW-MPI dependency, so hopefully in the future everything will be better.

[ABACUS-PR-BOT]

Static review of 32e12de74c07d2307a90c695dac6f8e452f592e5, independently cross-checked against the pinned libvdwxc implementation. Two geometry issues and one nonblocking timer-label cleanup are noted inline. No builds or runtime tests were run.

[CleverPhysician]

Follow-up on head 32e12de:

• The parser now rejects para.sys.double_grid explicitly, so unsupported double-density-grid inputs fail during input validation with a clear single-density-grid diagnostic.
• The host component now enforces the declared first-PR nspin=1 scope instead of retaining an untested nspin=2 path.
• The updated Python contract test is 7/7. On intern004, the real libvdwxc adapter CTest is 1/1, the abacus_pw_ser target relinks successfully, the two-atom Si CPU/PW/nspin=1 SCF converges with E_xc=-4.2517234318 Ry, E_total=-208.0135469216 eV, and the double-grid and nspin=2 negative-input checks both fail at the intended parser diagnostic.

The PR remains Draft while the new head's hosted checks are queued and the QE same-density reference is discussed.

[CleverPhysician]

Addressed the ABACUS-PR-BOT static review on head e65e07c:

• The libvdwxc cell adapter now passes ABACUS lattice rows as the C API's C00,C10,C20 vector groups. The oblique-cell test constructs the direct reference with the same documented row convention, so a transpose mismatch is now detected.
• The adapter rejects non-positive latvec.Det() before constructing the backend. A left-handed-cell regression test covers this case.
• The PotNonlocalXC timer labels now use cal_v_eff consistently.

The intern004 adapter CTest is 1/1 after these changes, and the Si CPU/PW/nspin=1 SCF remains numerically unchanged. The PR stays Draft pending the hosted checks for the new head and maintainer review.

[Growl1234]

That shouldn't be needed as libvdwxc's CMake config will definitely have libvdwxc::vdwxc target. Previously I did this in abacus for RapidJSON due to its embarrassing release status, but with it replaced by nlohmann-json there's no longer the case. If abacus can deal with items like dftd4 and pexsi well then the same for libvdwxc (its cmake is cleaner). If you really encountered issues please report them.

[CleverPhysician]

Agreed. c23f000 removes the if(NOT TARGET libvdwxc::vdwxc) check; ABACUS now relies on find_package(libvdwxc CONFIG REQUIRED) and links the exported libvdwxc::vdwxc target through _abacus_feature_libs, alongside Libxc::xc.

[Growl1234]

Looks like you add a lot of lines simply for detecting rVV10 API? For the time it might be okay, but we should drop it at some time in the future.

[CleverPhysician]

Dropped in c23f000: CMake no longer probes include directories, calls find_path(vdwxc.h), reads the header or matches rVV10 symbols with regexes. docs/advanced/install.md points to the libvdwxc MR !32 rVV10 branch instead.

[Growl1234]

Just a side note: PFFT dependency might be dropped in the future. Actually I'm proposing a minimal dependency policy upstream, but anyways PFFT will be the first lucky one.

[CleverPhysician]

Noted, thanks. This page was removed in c23f000; the adapter calls vdwxc_init_serial, and ABACUS does not directly discover or link PFFT.

[CleverPhysician]

Thanks for asking. I reran the unchanged libvdwxc revision 91ef4820f3270e22b35fddc2ab4cab8efa4b6d79 in two fresh build directories. My earlier wording was too broad: these were 69 failed comparisons within one CTest, rather than 69 failed tests or evidence that all libvdwxc algorithms fail.

Both builds used GCC 11.2.1, Release (-O3 -DNDEBUG; the tests also use -UNDEBUG), shared libraries, and MPI disabled. The MKL imported target additionally supplies -m64:

-DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_COMPILER=/opt/rh/devtoolset-11/root/usr/bin/cc
-DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=ON -DVDWXC_ENABLE_MPI=OFF

With -DVDWXC_FFT_PROVIDER=MKL -DMKL_INTERFACE=lp64 -DMKL_THREADING=sequential -DMKL_LINK=dynamic and MKL 2022.2.1, 7/8 CTests pass. rvv10.serial reports:

• 50 density-derivative finite-difference mismatches: maximum absolute discrepancy 2.34733549e-6; tolerance 3e-8 × (1 + |expected|).
• 16 sigma-derivative mismatches: maximum absolute discrepancy 5.68711029e-6; tolerance 3e-7 × (1 + |expected|).
• 3 full-strain derivative mismatches: maximum absolute discrepancy 9.01266900e-6; tolerance 3e-7 × (1 + |expected|).

The original MKL executable reproduces exactly the same values under a clean environment with no LD_LIBRARY_PATH:

env -i PATH=/usr/bin:/bin LANG=C LC_ALL=C OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 \
  /tmp/libvdwxc-mr32-audit/build-audit/libvdwxc_rvv10_test

Selecting -DVDWXC_FFT_PROVIDER=FFTW3 with standalone FFTW 3.3.11 and the same common settings gives 8/8 CTests passing, and the same rvv10.serial test reports 0 failures, also under env -i.

Both configurations pass the separate CP2K-table reference comparisons in that test: energy, density/sigma derivatives, and explicit stress on a 3 × 3 × 5 oblique grid, for both default and custom parameters. Those fixtures were generated independently using CP2K's kernel table, NumPy FFT, and SciPy splines; this is a table-level reference, not a CP2K SCF or QE comparison.

The current evidence therefore isolates the discrepancy to this MKL backend configuration. The underlying cause has not been established.

Updated head c23f000 now builds ABACUS with OpenBLAS and the same standalone FFTW as libvdwxc, avoiding mixed fftw_* implementations. The full serial PW executable builds, the adapter/Makefile CTests pass 2/2 (six C++ numerical/error cases), and the Si SCF converges with E_total=-208.0135469216242 eV. I corrected the PR description accordingly. MPI is not yet implemented, so I have not tested the FFTW-MPI wrapper or added a new MKL/FFTW mixing option.

This update also removes the manual CMake target/header/API checks and uses libvdwxc::vdwxc directly as suggested. The redundant developer page has been removed, and the adapter does not encode a PFFT dependency. It uses ABACUS's standard error diagnostics and adds an independent oblique/orthogonal-cell geometry test: deliberately restoring the wrong transpose makes that test fail. The PR stays Draft pending the scope decision and independent QE comparison.

[Growl1234]

Ah OK, I can now reproduce the failure with oneMKL 2026.1.0. I will have a look into it.

[Growl1234]

Ah OK, I can now reproduce the failure with oneMKL 2026.1.0. I will have a look into it.

@CleverPhysician This should be fixed on libvdwxc side, please check

[CleverPhysician]

Follow-up on c3dedfb:

• The adapter now forbids copying its owned libvdwxc handle. A type-contract
  regression failed on the original implicit copy constructor/assignment and
  passes with the two deleted operations.
• Added one focused host test using real Charge, UnitCell, and the backend.
  It checks valence-plus-core density construction, additive energy/vtxc/potential,
  preservation of existing XC values and unchanged density arrays. The separately
  tested adapter supplies the correction reference; this is host bookkeeping
  coverage, not an independent physical reference.
• Mutation checks confirm it catches missing core density (3.33e-5 Ry energy
  discrepancy) and replacing += by =. Production source was restored and
  checksum-matched before final verification.
• The full serial PW executable builds and all three libvdwxc-related CTests
  pass (seven adapter cases, one host case, one build-report test). The Si SCF
  and unsupported-input checks were rerun. Scope is unchanged.

The earlier 18 successful hosted checks apply to c23f000, not this new head;
new CI still needs to finish. The PR remains Draft pending scope approval and
independent QE validation. I found preserved raw QE density/output fixtures for
that next comparison, but have not counted the old native-backend results as
validation of this adapter.

[CleverPhysician]

Thanks, checked the fix at 94410ebdf3dc9615a40f40c3a5b59dbe20a433d2.
With GCC 11.2.1, both standalone FFTW 3.3.11 and MKL 2022.2.1
(lp64/sequential/dynamic) now pass all 8 library CTests, including
fft.weights and rvv10.serial. The seven ABACUS adapter tests and the real
host bookkeeping test also pass with the new standalone-FFTW library.
These runs were on a scheduled compute node (Slurm 555743), with the two
FFT providers kept separate. I updated the documented pin; no ABACUS
implementation change was needed for this fix.

The new adapter has now also been compared against the immutable original-QE
directional fixtures: seven cases, 960 points each, nine steps each.
Maximum energy difference is 3.50e-13 Ry, and its own-energy directional
residual is at most 1.25e-10 Ry at h=1e-4 (L1-direction normalized).
I have not called the pointwise potential comparison a pass: low-q and
small-sigma conventions differ, and the kernel convolution G sets are not
identical even when the host PW gradient cutoff is the same. Those differences
are recorded separately in the PR description; material/vacuum reference
validation and staged-scope agreement are still pending. Keeping this Draft.

[mohanchen]

Please answer directly to each comment.

[CleverPhysician]

Could you provide the detailed information?

At libvdwxc 91ef4820 with MKL 2022.2.1, the 69 failures were finite-difference comparisons within one CTest, rvv10.serial; standalone FFTW 3.3.11 with the same settings passed all 8 CTests (details in my earlier comment).

for now you can consider adding a USE_FFTW3_WITH_MKL that use MKL Blas/lapack/scalapack but standalone FFTW library

Not in this PR: the documented build uses standalone FFTW with ENABLE_MPI=OFF, and CMake warns when ENABLE_LIBVDWXC is combined with MKL (815deae).

[CleverPhysician]

I can now reproduce the failure with oneMKL 2026.1.0.

Thanks for reproducing it.

[CleverPhysician]

This should be fixed on libvdwxc side, please check

Checked, thanks for the fix. At libvdwxc 94410eb, all 8 library CTests pass with standalone FFTW 3.3.11 and, separately, with MKL 2022.2.1. The 7 ABACUS adapter tests and the host test also pass with the standalone-FFTW build, and docs/advanced/install.md references that commit.

[CleverPhysician]

Please answer directly to each comment.

Done. Each inline and conversation comment from ABACUS-PR-BOT and Growl1234 now has a direct reply. Since your comment, I merged develop (8e20175) into the branch and revised it; the current head is a682b56, and the PR description is updated to match.

Two points need your decision:

1. Is it acceptable to limit this first PR to CPU, a single process, nspin=1 and SCF, with MPI and collinear spin as follow-ups?
2. Is it acceptable to depend on the unreleased libvdwxc MR !32 revision for now?

[Growl1234]

Please give us a little more time. Discussions on the related series of PRs are already underway and should be wrapped up soon. Once the rVV10 PR is merged, a new release will come.

Also, to be honest, I'm not happy with the code itself and restriction here; IMHO it makes many things unnecessarily complicated. Perhaps I could ping @askhl to help take a look at this integration attempt.

[CleverPhysician]

In 256d216, I simplified the implementation by reusing existing ABACUS modules and removing redundant code paths to reduce integration risk and improve compatibility with other modules.