[CP2K-user] [CP2K:22448] GAPW_XC + r2SCAN: analytic forces and stress disagree with finite differences (CP2K 2026.2)

[liu wei]

Dear Prof. Thomas Kühne,

Thank you for the quick and clear explanation of the GAPW_XC issue. The 
inconsistency between the tau potential
(integrated with the original orbital products) and the kinetic-energy 
density (built from the soft orbitals) fits
what we saw: the total energies agree with GAPW, and only the analytic 
forces and stress are off, and only with a
meta-GGA. I see that PR #5749 was merged in mid-August, after the 2026.2 
release. Since there is no newer tagged
release yet, I will stop to use GAPW_XC with meta-GGA functionals for now. 
And temporarily use the PBE functional.

I am also very grateful for the additional Al tests on the basis sets and 
numerical settings. I had not realised
that EPS_DEFAULT 5E-11 still leaves EPS_PGF_ORB at about 7E-6. In all of 
our inputs EPS_PGF_ORB was set only
through EPS_DEFAULT, so it seem I also need to test this parameters in the 
future....

Thank you again for the time you have put into both questions.

Best regards,
Wei LIU

在2026年10月17日星期六 UTC+9 21:20:01<Thomas Kühne> 写道：

> Dear Wei,
>
> in the July revision c92cc08 you used, the GAPW_XC meta-GGA tau
> potential was integrated with the original orbital products, whereas the 
> XC kinetic-energy density was constructed from the soft orbitals. This 
> makes the operator and analytic derivatives inconsistentwith the XC 
> energy. The correction is already included in PR #5749: 
> https://github.com/cp2k/cp2k/pull/5749 Please use a build containing 
> this PR.
>
> Since our last Al exchange, I have also extended the basis and 
> numerical controls. An important finding is that EPS_DEFAULT 5E-11
> still gives a derived EPS_PGF_ORB of about 7E-6. I found appreciable
> primitive-screening sensitivity in equivalent representations
> of the enlarged Al basis. With explicit EPS_PGF_ORB 1E-8, these
> representations differ by about 0.12 meV/A in Al force-vector RMS.
> Tightening from 1E-8 to 1E-10 gives an Al force-vector RMS change
> below 0.003 meV/A in the matched PBE-potential controls. 
>
> For Al, raising the PP cutoff from 800 to 1200 Ry changes the forces by
> only 0.05 meV/A RMS. Refining the AE quadrature from 110/100 to 194/160
> gives 0.10 meV/A, whereas enlarging the AE basis from 70 to 159 functions
> gives 8.3 meV/A. However, the 159-function basis is an extension, not an 
> optimized production basis. At EPS_PGF_ORB 1E-8, the last PP basis
> step from 113 to 154 functions still changes the Al forces by 6.0 meV/A.
>
> The Al-potential trend remains clear. With r2SCAN as the
> functional throughout, the enlarged PP basis and the same expanded
> Al-only AE reference, PBE-GTH-q3 gives an Al force-vector RMS
> difference of about 172 meV/A, compared with about 282 meV/A
> for the earlier SCAN-GTH-q3 baseline on the initial 302-atom
> geometry. O, P and Zn are unchanged. I.e., PBE-GTH-q3 performs
> better in this comparison, despite not being fitted for r2SCAN.
>
> The roughly 0.17 eV/A residual with PBE remains after the
> tighter screening. Therefore, a potential-transferability or frozen-core
> contribution remains plausible ...
>
> Best regards,
> Thomas
>
> Am 17.10.2026 um 11:39 schrieb liu wei <whispe... at gmail.com>:
>
> Dear CP2K developers and users,
>
> While testing METHOD GAPW_XC with r2SCAN in CP2K 2026.2 (git:c92cc08), I 
> found that the analytic forces and stress
> do not agree with RUN_TYPE DEBUG finite differences, whereas GAPW, and 
> GAPW_XC with PBE, pass the same check. I may
> be missing something in my setup, so I would be grateful if you could take 
> a look. All inputs and outputs, a short
> analysis script (numpy only) and a README with the full tables are 
> attached (cp2k_GAPW_XC_mGGA_report.zip).
>
> **Setup**
>
> 302-atom ZnO–P2O5–Al2O3 glass (cubic, a = 16.06 Å, Γ point), 
> TZVP-MOLOPT-SCAN-GTH + GTH-SCAN for all elements,
> `MGGA_X_R2SCAN` + `MGGA_C_R2SCAN` (libxc) + D3(BJ), CUTOFF 1100 / 
> REL_CUTOFF 60, EPS_SCF 1e-7, analytical stress.
> RUN_TYPE DEBUG checks one Al, O, P and Zn atom and the stress tensor. 
> Between the inputs, only METHOD,
> GAPW_ACCURATE_XCINT, FORCE_PAW or the functional changes. Without 
> FORCE_PAW, O and Zn are PAW kinds and Al and P are
> treated by GPW.
>
> **Results** (analytic − finite difference; force: max over x, y, z, meV/Å; 
> stress: GPa)
>
> | functional | METHOD | ACCURATE_XCINT | Al | O | P | Zn | ΔS diagonal | 
> ΔS off-diagonal |
> |---|---|---|---|---|---|---|---|---|
> | r2SCAN | GAPW | T | 0.02 | 0.03 | 0.23 | 0.03 | 0.004 | 0.001 |
> | r2SCAN | GAPW | F | 0.02 | 0.03 | 0.23 | 0.04 | 0.004 | 0.001 |
> | r2SCAN | **GAPW_XC** | T | 11.5 | 91.5 | 23.3 | **410** | **+23.7** | 
> 0.008 |
> | r2SCAN | **GAPW_XC** | F | 18.2 | 261 | 37.6 | **458** | **+28.8** | 
> 0.004 |
> | PBE | GAPW_XC | T | 0.03 | 0.01 | 0.23 | 0.00 | 0.005 | 0.001 |
> | PBE | GAPW_XC | F | 0.02 | 0.01 | 0.23 | 0.00 | 0.004 | 0.001 |
>
> - The checked forces are 2000–3600 meV/Å, so the Zn error is about 20 %. 
> The stress error is an isotropic shift
>   of the diagonal; the off-diagonal components agree.
> - The *finite-difference* forces of GAPW_XC and GAPW agree to within 2.6 
> meV/Å (with and without
>   ACCURATE_XCINT), so the GAPW_XC energy itself looks fine; only the 
> analytic derivatives seem to be affected.
> - The largest errors are on the PAW kinds (Zn, then O). Adding `FORCE_PAW` 
> (so Al and P also become PAW atoms)
>   does not change the numbers.
> - So the problem seems specific to the combination GAPW_XC + meta-GGA, and 
> does not depend on
>   GAPW_ACCURATE_XCINT.
>
> In the v2026.2 regtests, the GAPW_XC finite-difference checks 
> (`regtest-acc-1/h2o-gapw_xc-force-1.inp`,
> `h2o-gapw_xc-stress-debug-1.inp`) use PBE, and the meta-GGA (TPSS) checks 
> use GAPW with USE_FINER_GRID, so I could
> not find a test that covers this combination. I have not tested the 
> current master, other meta-GGAs or a smaller
> system.
>
> My questions:
>
> 1. Is this a known issue, or is GAPW_XC not meant to be used with meta-GGA 
> forces and stress?
> 2. If it is a bug, would a small reproducer help (for example H2O with 
> TPSS, based on `h2o-gapw_xc-force-1.inp`)?
>    I would be happy to prepare one, or to open a GitHub issue.
>
> For now I use GAPW (or GPW with USE_FINER_GRID), which pass the same 
> checks.
>
> Thank you very much for your time and for CP2K.
>
> Best regards,
> Wei LIU
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cp2k+uns... at googlegroups.com.
> To view this discussion visit 
> https://groups.google.com/d/msgid/cp2k/c6c055e8-358f-426b-b287-dd02f4d2399an%40googlegroups.com 
> <https://groups.google.com/d/msgid/cp2k/c6c055e8-358f-426b-b287-dd02f4d2399an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> <cp2k_GAPW_XC_mGGA_report.zip>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+unsubscribe at googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cp2k/05e58415-15d2-4e56-b108-f4d62b39b9ben%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20261017/ad3d16af/attachment.htm>