Sorry, I'm resending this because apparently things got moved off the list. In brief, I was sent files from Prof Song which could be used to reproduce the issue. This was my response. --
Thanks. I ran some tests on my system with 4 cores and imin=5 and it worked as expected; however, when I tried your system, sander and sander.MPI (with more than 1 core) disagree in the manner you've described. The main difference was: my system was at constant volume whereas your trajectory and initial restart file use different unit cells (like it was from a constant pressure simulation). As a test, I created a new restart file by extracting the first frame of your trajectory file and tried the tests again. When I use the extracted restart file, sander and sander.MPI agree for the first frame.
In other words, when using imin=5, it appears that the unit cell information is initialized from the input restart file, and then the sanderrank=0 process updates its unit cell information when reading the trajectory, but it is not updated on the other ranks.
If you are willing to switch to ambertools24 rather than 22, you could instead use imin=6 which is almost the same thing as imin=5. Rather than sending each from of the trajectory through the minimizer, it sends each frame to the MD code (if you want a single point of each frame, you'd set imin=6 and nstlim=0). I verified that sander and sander.MPI produce the same results when using imin=6 even when the unit cell changes. The minimizer code will need to be updated or it should at least stop with an error message if the unit cell changes while being performed on more than 1 core. I'd have to review the code in a bit more detail to see if this is a limitation of the parallelization strategy used by the minimization driver.
-Tim
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Aug 23 2024 - 08:30:02 PDT
