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