search

plumed / plumed2

Development version of plumed 2
https://www.plumed.org
GNU Lesser General Public License v3.0
359 stars 286 forks source link

Results differ between plumed 2.7.3 and 2.8.0 #826

Closed aradi closed 2 years ago

aradi commented 2 years ago

Description

Using the attached minimal working example, I get different results in step 2, when I use version 2.7.3 and 2.8.0 of plumed2. Note, the example is in Fortran, but it uses directly the C-interface of plumed. (I was just to lazy to transfer it to a C code, it took me long enough to isolate it from DFTB+, where I discovered the deviance.)

As it was flagged up by our regression test system, I am wondering, which of the two results is the correct one?

How to reproduce

Compile and install the official release as distributed via GitHub, then:

LD_LIBRARY_PATH=$HOME/opt/plumed/2.7.3/lib gfortran test_plumed.f90 $HOME/opt/plumed/2.7.3/lib/libplumed.so
LD_LIBRARY_PATH=$HOME/opt/plumed/2.7.3/lib ./a.out > output.2.7.3
LD_LIBRARY_PATH=$HOME/opt/plumed/2.8.0/lib gfortran test_plumed.f90 $HOME/opt/plumed/2.8.0/lib/libplumed.so
LD_LIBRARY_PATH=$HOME/opt/plumed/2.8.0/lib ./a.out > output.2.8.0
diff output.2.7.3 output.2.8.0

This results in

< PLUMED: Version: 2.7.3 (git: Unknown) compiled on May 20 2022 at 12:53:36
---
> PLUMED: Version: 2.8.0 (git: Unknown) compiled on May 20 2022 at 13:06:31
5,6c5,6
< PLUMED: Root: /home/aradi/opt/plumed/2.7.3/lib/plumed
< PLUMED: For installed feature, see /home/aradi/opt/plumed/2.7.3/lib/plumed/src/config/config.txt
---
> PLUMED: Root: /home/aradi/opt/plumed/2.8.0/lib/plumed
> PLUMED: For installed feature, see /home/aradi/opt/plumed/2.8.0/lib/plumed/src/config/config.txt
34d33
< PLUMED:   added component to this action:  @3.work 
63,65c62,64
<  -0.6505235048875452E-01 -0.1469225111112824E+00 -0.1534122952359242E-02
<   0.1500620120888526E-01  0.1410975250296990E-02  0.1140237616464491E-03
<   0.5004614927986927E-01  0.1455115358609854E+00  0.1420099190712793E-02
---
>  -0.6505264177236378E-01 -0.1469226593805776E+00 -0.1534126058012925E-02
>   0.1500620023905696E-01  0.1411220252532981E-02  0.1140255643004433E-03
>   0.5004644153330682E-01  0.1455114391280446E+00  0.1420100493712482E-02

The differences in the forces are around 1e-7, roughly at the edge of single precision, but that may be just by accident. Unfortunately, during an MD this quickly adds then up and causes significant differences.

System

> gfortran --version
GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
...
> g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

> uname -a                                                                                                
Linux noys 5.13.0-41-generic #46~20.04.1-Ubuntu SMP Wed Apr 20 13:16:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I've tested, I get the same difference with the Conda packages as well.

plumed.dat.txt test_plumed.f90.txt

GiovanniBussi commented 2 years ago

@aradi thanks for reporting! Could it be because we implemented stretched (continuous) Gaussians #755 ?

Can you try to run 2.8.0 after setting export PLUMED_DP2CUTOFF_NOSTRETCH=yes? If this reproduces the 2.7 calculation, then it is expected.

aradi commented 2 years ago

@GiovanniBussi Thanks for the super quick answer!

It seems, that if set that variable, it reproduces the old behavior. I have 3 quick questions/comments:

Thanks in advance!

GiovanniBussi commented 2 years ago

@GiovanniBussi Thanks for the super quick answer!

It seems, that if set that variable, it reproduces the old behavior. I have 3 quick questions/comments:

  • It does not matter, what I set for this variable (I've also tried no), it seems to reproduce the old behavior if the variable is set.

Yes, it's expected, there's a simple getenv in the code. This env var is not even documented anywhere, we might remove it, I just used it during the transition for debugging.

  • Which behavior is the recommended one? Is the new default behavior the correct one? In this case, we would recalculate our test suites accordingly.

2.8 is doing right. The Gaussians now are truncated and stretched. Before they were just truncated, with a small discontinuity. Technically it is a bug fix, but since it breaks reproducibility we preferred to only apply it to 2.8.

  • Is this documented somewhere in the public space? I'd then add a link to it in our documentation, just in case users wonder, why they results are not reproducable with DFTB+ any more.

It's the first point in this changelog. In that document it is just mentioned as a breaking change, more details can be found by following the link to the GitHub issue.

Thanks in advance!

GiovanniBussi commented 2 years ago

See also these links that I just found: https://github.com/PHOTOX/ABIN/pull/102 https://github.com/PHOTOX/ABIN/issues/83

Other people noticed it already

aradi commented 2 years ago

Thanks once more for the quick response!