[gmx-users] Higher that usual salt bridge occupancies in Amber99sb*-ildn forcefield despite adding nonbonded corrections
jalemkul at vt.edu
Thu Apr 20 20:43:14 CEST 2017
On 4/20/17 2:30 PM, Priyesh Mohanty wrote:
> I have performed multiple simulations for various systems over the course of
> the last three months or so which are more than 200 ns. As I have stated
> earlier, this problem only arose some time this January simultaneously across
> multiple machines. My occupancies were as expected from these corrections
> from August to December 2016. The forcefield modifications have been
> extensively validated by the Aksementiev group (JCTC, 2016) against
> experimental data on both Gromacs and NAMD, although they were performed on
> the CPU version of Gromacs from version 4.6 to 5.1 (personal communication).
So I presume that you got all of your input files from those authors, including
.mdp files for the runs?
> What I don't quite understand is how the same .tpr which gave low
> occupancies initially can now produce trajectories with stronger salt bridges
> ? CPU only runs also show higher occupancies. In fact when I switched to a
If the results are the same on CPU and GPU, this is pretty clear indication that
it's not simply a problem with mdrun magically doing something different. It's
actually pretty good evidence that what you're seeing is real behavior.
> new machine, the first trajectory actually gave a low occupancy as seen in my
> older ubiquitin trajectories. However, the next few trajectories once again
> produced higher occupancies as seen in other machines. The simulations show
> no apparent sign of instability (temperature, pressure) and I haven't changed
> any thing in my forcefield files since the time I added these modifications
> last year in August. There are no differences between the .tpr being
> generated now and the older ones. -Priyesh
If you can't reproduce what others have published, go back and do exactly what
they did. The paper you reference used GROMACS 4.5.5 so you should do a sanity
check simulation with the exact same version and setup. Then, if something is
amiss afterwards (e.g. 4.5.5 reproduces the paper, but 4.6 and newer do not)
then it is possible that there is a bug somewhere. Perhaps the old version had
a bug and the results obtained were the "right" result for the "wrong" reason.
I think that's rather unlikely, but it's the first step you have to take when
you can't reproduce a published finding.
> On Thursday, 20 April 2017 11:38 PM, Justin Lemkul <jalemkul at vt.edu> wrote:
> On 4/20/17 9:12 AM, Priyesh Mohanty wrote:
>> Dear Justin and Chris,There appears to be no difference between the old
>> and the newly created .tpr files. I determined this using gmxcheck. As an
>> additional confirmation I reperformed a production simulation of Ubiquitin
>> using the old .tpr which originally gave the proper occupancies for a
>> given salt bridge. The reperformed run also shows the increase in
>> occupancy compared to the original run. I think this suggests a problem
>> with mdrun.
> That's a rather serious allegation. mdrun undergoes correctness testing so
> that the physics is faithfully performed. Does your GROMACS installation
> pass all the tests after you have installed?
>> This problem appeared simultaneously across across multiple machines. The
>> stability is more than three times higher in the newer run with the same
>> corrections (53% vs 16% occupancy using a 5 angstrom cutoff).
> How long are your simulations? Can you reproduce the findings across
> multiple trajectories starting from different initial coordinates or
> velocities? You may just have a sampling problem. Have you tested the
> correctness of the force field modifications by e.g. comparing a single point
> energy in GROMACS with one done in AMBER?
Justin A. Lemkul, Ph.D.
Ruth L. Kirschstein NRSA Postdoctoral Fellow
Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 629
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201
jalemkul at outerbanks.umaryland.edu | (410) 706-7441
More information about the gromacs.org_gmx-users