[gmx-users] Higher that usual salt bridge occupancies in Amber99sb*-ildn forcefield despite adding nonbonded corrections

Priyesh Mohanty priyeshmohanty at yahoo.in
Thu Apr 20 20:30:56 CEST 2017

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). 
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 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.

    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

Gromacs Users mailing list

* Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-request at gromacs.org.


More information about the gromacs.org_gmx-users mailing list