Project

General

Profile

Bug #767

electrostatic forces with PME and DD

Added by Florian Dommert about 8 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Hello,

over the weekend I realized that the electrostatic forces calculated in parallel with DD and PME vary drastically from run to run ( in the order 10^6 - 10^10 ). For PD the results were always the same. The test case is a water box of about 4000 molecules and I just calculated the forces and do not integrate ( which means nsteps=0 ). I tried different versions and platforms, shared and static builds, but the result is always the same. For some runs with DD the forces correspond to the ones obtained with PD, while other runs give much larger forces and this just for some particles and not for all. Finally I realized that actually the chosen system was not well equilibrated, because if I tried to integrate and set the timestep to a value != 0 then I got a warning message and the variation of forces just occurs, if the water molecules can not be settled. So perhaps a grompp warning can be inserted to inform the user that setting the time step to zero can introduce artefacts, because during mdrun you won't get a warning due to a failure of settling waters, but the corresponding pseudo-force is written to the trajectory file, isn't it ? A test case is appended. If you generate a tpr and run mdrun with DD and calculate the average force with g_traj -af -fp on the same tpr you will never get a warning message due to settle problems. If the time step is changed to a value >0 then a warning during mdrun arises if large forces occur otherwise not. However at the end I would like to point out that this behaviour just occurs with DD and a number of processes > 1. In case other PD is used or just one process the electrostatic forces of this configuration are written into the trajectory file.

/Flo

water.tgz (228 KB) water.tgz Florian Dommert, 06/27/2011 06:31 PM

History

#1 Updated by Mark Abraham almost 8 years ago

Reposted so that the description is more readable.

over the weekend I realized that the electrostatic forces calculated in parallel with DD and PME vary drastically from run to run ( in the order 10^6 - 10^10 ). For PD the results were always the same. The test case is a water box of about 4000 molecules and I just calculated the forces and do not integrate ( which means nsteps=0 ). I tried different versions and platforms, shared and static builds, but the result is always the same. For some runs with DD the forces correspond to the ones obtained with PD, while other runs give much larger forces and this just for some particles and not for all. Finally I realized that actually the chosen system was not well equilibrated, because if I tried to integrate and set the timestep to a value != 0 then I got a warning message and the variation of forces just occurs, if the water molecules can not be settled. So perhaps a grompp warning can be inserted to inform the user that setting the time step to zero can introduce artefacts, because during mdrun you won't get a warning due to a failure of settling waters, but the corresponding pseudo-force is written to the trajectory file, isn't it ? A test case is appended. If you generate a tpr and run mdrun with DD and calculate the average force with g_traj -af -fp on the same tpr you will never get a warning message due to settle problems. If the time step is changed to a value >0 then a warning during mdrun arises if large forces occur otherwise not. However at the end I would like to point out that this behaviour just occurs with DD and a number of processes > 1. In case other PD is used or just one process the electrostatic forces of this configuration are written into the trajectory file.

#2 Updated by Berk Hess almost 8 years ago

  • Assignee set to Berk Hess

Could you check what happens when you remove or comment out the if(xshake(... line from csettle.c?
That what I did for version 4.6.

#3 Updated by Florian Dommert almost 8 years ago

Should we comment out just the if statement, or also the following line assigning the error pointer.

#4 Updated by Rossen Apostolov over 7 years ago

Was that patched in 4.6? Because csettle.c is the same in both release-4-6 and release-4-5-patches

Berk Hess wrote:

Could you check what happens when you remove or comment out the if(xshake(... line from csettle.c?
That what I did for version 4.6.

#5 Updated by Berk Hess over 7 years ago

  • Status changed from New to In Progress

This has been fixed in the nbnxn_hybrid_acc branch, which we soon have to merge into 4.6.

#6 Updated by Teemu Murtola over 6 years ago

  • Category set to mdrun
  • Status changed from In Progress to Closed
  • Target version set to 4.6

From the discussion, it seems that it is fixed in 4.6. Please reopen if it is necessary to fix also for 4.5.6 (and that has not yet been done).

Also available in: Atom PDF