[CP2K-user] [CP2K:22258] Calcite crystal RPBE force convergence

['Kit Joll' via cp2k]

Dear Thomas, 

Thank you very much for fixing this issue so quickly. I'm recompiling now 
and then will attempt to reproduce your findings. I've also seen you've 
updated the APT tests, so I am presuming you don't need a minimal regtest 
example anymore? If you do, please let me know and I'll create something. 

Once again, thank you for your quick replies and help. 

All the best,
Kit

On Wednesday, May 27, 2026 at 11:27:48 PM UTC+1 Thomas Kühne wrote:

> Dear Kit,
>
> thank you for the additional finite-field checks. Your observation was 
> exactly the useful diagnostic: the 
> residual is odd in the applied field, proportional to the field strength, 
> and parallel to the field direction. 
> This points to the periodic Berry-phase electric-field force contribution 
> rather than to the GAPW_XC 
> grid issue.
>
> I have prepared a CP2K patch that enforces the acoustic sum rule on the 
> isolated periodic electric-field 
> force contribution for neutral periodic cells. With your +1.25e-4 a.u. 
> calcite case, the force sum changes 
> from
>
>   (-6.11e-9, 7.87e-9, 1.02476e-4) Ha/Bohr
>
> to
>
>   (-6.11e-9, 7.87e-9, -3.02e-9) Ha/Bohr,
>
> with the total force sum reduced to about 1.0e-8 Ha/Bohr.
>
> The energy is unchanged within numerical noise. This confirms that the 
> remaining finite-field force-sum 
> residual was a center-of-mass component of the periodic electric-field 
> force, distinct from the original 
> XC/grid force issue.
>
> A smaller reproducer would still be useful for adding a lightweight 
> regression test, since the full calcite case 
> is too expensive for the regular CP2K test suite.
>
> Best,
> Thomas
>
> Am 27.05.2026 um 14:10 schrieb 'Kit Joll' via cp2k <cp... at googlegroups.com
> >:
>
> Dear Thomas,
>
> Thank you again for the helpful suggestions. I have now repeated the 
> finite-field calculation with both signs of the field and with the field 
> magnitude halved.
>
> All four calculations used the same input settings, cell, coordinates, 
> GAPW_XC / GAPW_ACCURATE_XCINT setup, XC grid settings, basis sets and 
> pseudopotentials. The only changes were the PERIODIC_EFIELD INTENSITY and 
> POLARISATION. The effective field is along z, with E_z = INTENSITY * 
> POLARISATION_z. I have attached the four corresponding input/output pairs. 
> The attachment filenames indicate the actual field values (the PROJECT_NAME 
> inside the input files is just a leftover label).
>
> The resulting force sums are:
>
> E_z / a.u.        Sum F_x          Sum F_y          Sum F_z          (Sum 
> F_z) / E_z
> -2.5e-4          -6.1085e-09      7.8702e-09     -2.04936242e-04   
> 0.819744968
> -1.25e-4         -6.1090e-09      7.8708e-09     -1.02473941e-04   
> 0.819791528
> +1.25e-4         -6.1100e-09      7.8720e-09      1.02475947e-04   
> 0.819807576
> +2.5e-4          -6.1104e-09      7.8725e-09      2.04962359e-04   
> 0.819849436
>
> So the absolute z-component of the force-sum residual approximately halves 
> when the field is halved, while the ratio Sum F_z / E_z remains essentially 
> constant at about 0.8198. The residual also changes sign when the field 
> direction is reversed. The transverse components remain at the zero-field 
> level, around 1e-8 Ha/Bohr.
>
> The central finite-difference slopes are very similar for the two field 
> magnitudes:
>
> [ F_z(+1.25e-4) - F_z(-1.25e-4) ] / [2 * 1.25e-4] = 0.819799552
>
> [ F_z(+2.5e-4) - F_z(-2.5e-4) ] / [2 * 2.5e-4] = 0.819797202
>
> This seems to confirm your suggested diagnostic: the remaining force-sum 
> residual is odd in the field, proportional to the applied field, and 
> parallel to the field direction. It therefore looks distinct from the 
> original XC/grid force issue.
>
> Would you recommend any further diagnostic at this point, or would it be 
> useful for me to prepare a more minimal test case for the 
> periodic-electric-field force contribution?
>
> All the best,
> Kit
>
> On Tuesday, May 26, 2026 at 7:15:40 PM UTC+1 Thomas Kühne wrote:
>
>> Dear Kit,
>>
>> I agree with your interpretation. The important point is that the 
>> residual is now almost entirely parallel to the applied periodic field. In 
>> your z-field calculation,
>>
>> FORCES| Sum -6.11045615E-09 7.87254948E-09 2.04962359E-04
>>
>> the x and y components remain at the zero-field accuracy, whereas the z 
>> component is of the order of the applied field strength. This strongly 
>> suggests that 
>> we are no longer looking at the same XC/grid egg-box issue that was cured 
>> by GAPW_XC + GAPW_ACCURATE_XCINT. Rather, the remaining term seems 
>> to originate from the finite-field/Berry-phase force contribution itself.
>>
>> For a neutral periodic system I would still expect the total force to 
>> vanish, also in a homogeneous Berry-phase electric field, up to numerical 
>> noise. The 
>> residual is also not simply a physical net-charge force. The system is 
>> neutral in terms of the GTH valence charges, and the residual is 
>> approximately 0.82 
>> times the field strength rather than an obvious integer-charge 
>> contribution.
>>
>> I do not think there is a Wannier-localization setting that should fix 
>> this. The PERIODIC_EFIELD implementation uses the Berry-phase formulation 
>> directly; 
>> the printed Wannier/localization controls are not convergence parameters 
>> for this force term. Likewise, increasing the XC fine grid should only 
>> affect the 
>> ordinary XC/grid part. Since the transverse components are already small, 
>> and the residual tracks the field direction, I would not expect 
>> FINE_GRID_FACTOR 
>> alone to remove it completely.
>>
>> Could you please do two quick checks, if convenient?
>>
>> 1. Repeat the same calculation with the field reversed, i.e. INTENSITY 
>> -2.5e-4 or POLARISATION 0 0 -1.
>> 2. Repeat with half the field strength, e.g. 1.25e-4 a.u.
>>
>> If the force-sum residual changes sign with the field and scales linearly 
>> with its magnitude, that would be very strong evidence that the issue is in 
>> the periodic 
>> electric-field force contribution rather than in the GAPW/XC integration.
>>
>> At first sight, finite-field force code path looks like a missing or 
>> imperfect cancellation between the ionic and electronic Berry-phase force 
>> terms under a uniform 
>> translation. In other words, it may be a real CP2K bug or at least a 
>> limitation of the present PERIODIC_EFIELD force implementation, rather than 
>> an 
>> input-convergence issue.
>>
>> As a practical workaround for testing internal forces, subtracting the 
>> average force from all atoms would remove the spurious center-of-mass 
>> acceleration, but 
>> I would not present that as a formally clean solution until we understand 
>> the origin of the term.
>>
>> Best wishes,
>> Thomas
>>
>> Am 26.05.2026 um 16:35 schrieb 'Kit Joll' via cp2k <
>> cp... at googlegroups.com>:
>>
>> Dear Thomas,
>>
>> Thank you again for your help. I was able to reproduce your zero-field 
>> results to approximately the same accuracy with a master version cloned on 
>> Friday 22nd May. I presume the remaining small differences are due to 
>> build/library differences.
>>
>> However, while the zero-field force sum is now well converged, I am not 
>> seeing the same behaviour once a finite periodic electric field is applied.
>>
>> For example, using
>>
>> METHOD GAPW_XC
>> GAPW_ACCURATE_XCINT
>> USE_FINER_GRID T
>> FINE_GRID_FACTOR 2.0
>>
>> together with a periodic Berry-phase electric field of intensity 2.5e-4 
>> a.u. along z, the force sum becomes
>>
>> FORCES| Sum -6.11045615E-09 7.87254948E-09 2.04962359E-04
>> FORCES| Total atomic force 2.04962360E-04
>>
>> So the transverse components remain well converged, but the component 
>> along the applied field direction returns to the order of 1e-4 Ha/Bohr. I 
>> see similar behaviour when applying the field along other directions. The 
>> issue also persists when increasing FINE_GRID_FACTOR from 2 to 8: the 
>> force-sum error remains orders of magnitude larger along the field axis 
>> (however, all components sum do decrease by ~1 order of magnitude relative 
>> to FINE_GRID_FACTOR 2). 
>>
>> Do you know whether there are additional grid, Berry-phase, or 
>> Wannier-related settings that need to be converged for finite-field force 
>> calculations? Or is there another setting that should be used together with 
>> GAPW_XC and GAPW_ACCURATE_XCINT in the presence of a periodic electric 
>> field?
>>
>> Please find attached a minimal input (start.inp) /output (output.out) 
>> pair that reproduces the issue.
>>
>> Thank you again for your help and advice.
>>
>> All the best,
>> Kit
>> On Thursday, May 21, 2026 at 10:48:00 AM UTC+1 Kit Joll wrote:
>>
>>> Dear Thomas,
>>>
>>> Many thanks for the very quick and detailed reply! This is extremely 
>>> helpful, and your diagnosis makes a lot of sense given the behaviour we 
>>> were seeing.
>>>
>>> I will try compiling the current CP2K master using the new make_cp2k.sh 
>>> workflow, run the relevant regression tests, and then first reproduce your 
>>> zero-field force-sum results on the same calcite frame. After that, I will 
>>> check whether the same settings also resolve the sensitivity we observe in 
>>> the finite-field response tensors.
>>>
>>> Thank you also for pointing out the PRINT_LEVEL LOW workaround and the 
>>> relevant GAPW_XC / GAPW_ACCURATE_XCINT settings. I will report back once I 
>>> have tested these on our side.
>>>
>>> Best wishes,
>>> Kit
>>>
>>> On Wednesday, May 20, 2026 at 9:00:47 PM UTC+1 Thomas Kühne wrote:
>>>
>>>> Dear Kit,
>>>> Thank you for the detailed report and for the input/output files. I was 
>>>> able to
>>>> reproduce the force-sum residual for the provided calcite frame:
>>>> GPW baseline: Sum F = ( 3.48675295E-05, 1.12518883E-04, 
>>>> -5.39277596E-05 ) Ha/Bohr |Sum F| = 1.29554803E-04 Ha/Bohr
>>>> The behavior originate from the XC/grid treatment:
>>>> GPW + USE_FINER_GRID T, FINE_GRID_FACTOR 2.0: |Sum F| = 2.26659720E-05 
>>>> Ha/Bohr GPW + finer/smoothed XC grid: |Sum F| = 1.10078684E-06 Ha/Bohr 
>>>> GAPW_XC: |Sum F| = 4.20880179E-05 Ha/Bohr GAPW_XC + 
>>>> GAPW_ACCURATE_XCINT: |Sum F| = 1.68750841E-07 Ha/Bohr GAPW + 
>>>> GAPW_ACCURATE_XCINT + USE_FINER_GRID T, FINE_GRID_FACTOR 2.0: |Sum F| 
>>>> = 3.85198029E-08 Ha/Bohr GAPW_XC + GAPW_ACCURATE_XCINT + 
>>>> USE_FINER_GRID T, FINE_GRID_FACTOR 2.0: |Sum F| = 1.04105369E-08 
>>>> Ha/Bohr
>>>> This strongly suggests that the residual is dominated by an 
>>>> egg-box/grid-coupling
>>>> effect in the XC/grid integration rather than by pseudopotentials, 
>>>> basis sets, or
>>>> SCF noise.
>>>> For this system, the best tested setting was:
>>>> &QS EPS_DEFAULT 1.0E-18 METHOD GAPW_XC GAPW_ACCURATE_XCINT &END QS &XC DENSITY_CUTOFF 
>>>> 1.0E-10 GRADIENT_CUTOFF 1.0E-10 TAU_CUTOFF 1.0E-10 &XC_GRID FINE_GRID_FACTOR 
>>>> 2.0 USE_FINER_GRID T &END XC_GRID &XC_FUNCTIONAL NO_SHORTCUT &GGA_C_PBE &END 
>>>> GGA_C_PBE &GGA_X_RPBE &END GGA_X_RPBE &END XC_FUNCTIONAL &END XC
>>>> METHOD GAPW with the same GAPW_ACCURATE_XCINT and fine XC grid also 
>>>> performs
>>>> very well, but in this test GAPW_XC was slightly better and should be 
>>>> the less
>>>> intrusive change relative to the original GPW calculation.
>>>> One practical note: GAPW_ACCURATE_XCINT has been improved recently, so 
>>>> I would
>>>> recommend testing with a recent CP2K master or a release that includes 
>>>> those
>>>> changes. Also, for this calcite input current master hit a post-SCF 
>>>> output crash
>>>> with PRINT_LEVEL MEDIUM; using PRINT_LEVEL LOW while keeping explicit
>>>> &FORCES ON avoided that and still printed the force block.
>>>> Best wishes,
>>>> Thomas
>>>>
>>>
>> -- 
>> 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/5caec0c1-cdad-455b-815f-dd7f993d0230n%40googlegroups.com 
>> <https://groups.google.com/d/msgid/cp2k/5caec0c1-cdad-455b-815f-dd7f993d0230n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> <output.out><start.inp>
>>
>>
>>
> -- 
> 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/224ff211-1c76-42c2-bafb-57bf10f8a8ebn%40googlegroups.com 
> <https://groups.google.com/d/msgid/cp2k/224ff211-1c76-42c2-bafb-57bf10f8a8ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> <Ez_m2p5e-4_output.out><Ez_m1p25e-4_output.out><Ez_p1p25e-4_start.inp>
> <Ez_m1p25e-4_start.inp><Ez_p1p25e-4_output.out><Ez_p2p5e-4_start.inp>
> <Ez_p2p5e-4_output.out><Ez_m2p5e-4_start.inp>
>
>
>

-- 
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/39358354-e573-4e67-a51c-867467d39a20n%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20260528/deb83149/attachment-0001.htm>