You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just found two serious bugs in passing virial back to gromacs.
When not computing energies, plumed virial is actually not felt by gromacs.
More precisely, an input such as
v: VOLUME
RESTRAINT ARG=v AT=0.0 SLOPE=xxx
gives always the same trajectory independently of xxx
I guess this problem was introduced due to the optimization of gromacs load balancing with plumed (with patch in plumed 2.0.2). Notice that if ENERGY CV is used the optimization is removed and the problem is different (see point 2 below). It is very difficult to track these problems without regtests on patched codes. Moreover, the effect of bias on virial is tiny is many practical cases (e.g. a few torsion biased) and becomes relevant mostly when using VOLUME CV, which is certainly not common for people using gromacs+plumed for biomolecular systems.
When computing energies, plumed virial felt by gromacs seems wrong by a factor 2
More precisely, an input such as
v: VOLUME
e: ENERGY
RESTRAINT ARG=v AT=0.0 SLOPE=xxx
PRINT FILE=e ARG=e # this is just to force plumed to ask energy to gromacs at every step
should be usable to compensate a change in pressure in gromacs barostat. Indeed, an increase in barostat pressure by 1000 bar should be exactly compensated by a SLOPE=-66.02. Actually, it is compensated with a SLOPE=-33.01, indicating that gromacs assumes the virial to be half of what plumed computes. Also notice that the two trajectories (press=1bar+SLOPE=0 and press=1001bar+SLOPE=-33.01) are not exactly identical. I do not understand this, but there might be some small issue with unit conversions.
Both these bugs (no plumed virial in case 1, doubled plumed virial in case 2) are expected to affect results of MD at constant pressure when using VOLUME or CELL CVs or, likely, when biasing a huge number of variables (e.g. coordination of solvent with solvent). I would expect errors to be extremely small in all other cases.
I think this should be fixed inside gromacs patch, since fixing it from plumed would affect other codes.
Moreover, this calls for more tests including virial contribution when plumed is combined with other MD codes.
The text was updated successfully, but these errors were encountered:
I just found two serious bugs in passing virial back to gromacs.
More precisely, an input such as
v: VOLUME
RESTRAINT ARG=v AT=0.0 SLOPE=xxx
gives always the same trajectory independently of xxx
I guess this problem was introduced due to the optimization of gromacs load balancing with plumed (with patch in plumed 2.0.2). Notice that if ENERGY CV is used the optimization is removed and the problem is different (see point 2 below). It is very difficult to track these problems without regtests on patched codes. Moreover, the effect of bias on virial is tiny is many practical cases (e.g. a few torsion biased) and becomes relevant mostly when using VOLUME CV, which is certainly not common for people using gromacs+plumed for biomolecular systems.
More precisely, an input such as
v: VOLUME
e: ENERGY
RESTRAINT ARG=v AT=0.0 SLOPE=xxx
PRINT FILE=e ARG=e # this is just to force plumed to ask energy to gromacs at every step
should be usable to compensate a change in pressure in gromacs barostat. Indeed, an increase in barostat pressure by 1000 bar should be exactly compensated by a SLOPE=-66.02. Actually, it is compensated with a SLOPE=-33.01, indicating that gromacs assumes the virial to be half of what plumed computes. Also notice that the two trajectories (press=1bar+SLOPE=0 and press=1001bar+SLOPE=-33.01) are not exactly identical. I do not understand this, but there might be some small issue with unit conversions.
Both these bugs (no plumed virial in case 1, doubled plumed virial in case 2) are expected to affect results of MD at constant pressure when using VOLUME or CELL CVs or, likely, when biasing a huge number of variables (e.g. coordination of solvent with solvent). I would expect errors to be extremely small in all other cases.
I think this should be fixed inside gromacs patch, since fixing it from plumed would affect other codes.
Moreover, this calls for more tests including virial contribution when plumed is combined with other MD codes.
The text was updated successfully, but these errors were encountered: