[gmx-developers] [gmx-core] removal of encad and gmx FF in 5.0?

Justin Lemkul jalemkul at vt.edu
Fri Feb 14 17:18:25 CET 2014

On 2/14/14, 11:12 AM, Mark Abraham wrote:
> Removing encad and gmx sounds good. Probably don't have time to rip out the code
> that supported encad.
> We're happy to add forcefields that are used by more than one person, have been
> extensively tested, have an associated publication record, etc. Any particular
> suggestions, Alexey? Others?
> Off the top of my head, Charmm36 would be an obvious thing to add. My
> reservation here is that there's not really ever been a good way to run
> CHARMM-style non-bondeds in GROMACS. I suspect this will change in 5.0 with
> Verlet-kernel support for switch functions, but perhaps a fully validated
> forcefield and workflow port for 5.1 would be a good joint project. Thoughts,
> Justin?

Yes, we're working on that.  I'm personally looking into the best ways to run 
CHARMM force fields within Gromacs.  Couple that with my ongoing implementation 
of our Drude algorithms and I think 5.1 is a good target.  Our only reservations 
about including a CHARMM36 force field directory in Gromacs are: (1) we update 
the force field quite frequently, certainly more often than Gromacs versions are 
released and (2) we keep detailed statistics about downloads from our lab 
website to help track usage (and get grants :).

At minimum, I am perfectly happy to oversee the coordination between Gromacs and 
the CHARMM force fields in terms of making sure we have a suitable (recent) 
distribution ready whenever a new Gromacs release comes out.



Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
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-developers mailing list