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

Fri Feb 14 19:10:39 CET 2014

Right, requiring this is a service to the field, not just GROMACS.

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821

From: Erik Lindahl <erik.lindahl at scilifelab.se<mailto:erik.lindahl at scilifelab.se>>
Date: Friday, February 14, 2014 at 12:52 PM
To: "gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>" <gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>>, "michael.shirts at virginia.edu<mailto:michael.shirts at virginia.edu>" <michael.shirts at virginia.edu<mailto:michael.shirts at virginia.edu>>
Subject: Re: [gmx-developers] [gmx-core] removal of encad and gmx FF in 5.0?

IIRC, Eric’s first testing (a long time ago) actually found a bug in _Amber_ for a particular sidechain when he couldn’t get the Gromacs results to match :-)

Cheers,

Erik

On 14 Feb 2014, at 09:40, Shirts, Michael (mrs5pt) <mrs5pt at eservices.virginia.edu<mailto:mrs5pt at eservices.virginia.edu>> wrote:

I generally agree with Erik here.   I think that force fields should be contributed at first.  I would be interested in helping brainstorm an approval process that would allow force fields to be eventually included in the main distribution.  Eric Sorin's validation procedure for AMBER and GROMACS is a nice example of what such a procedure would look like.  Such a validation process would consist of:

  *   A database of molecules + structures that supports the entire functionality that the force field is supposed to support
  *   Comparison of Gromacs energies and the native implementation energies over all the force fields for all molecules in the database, with tolerance down to the appropriate levels.
  *   An inclusion of the actual output of the comparison test.
  *   A script (we can help provide initial versions that can be adapted to particular databases) that run this regression test with each new Gromacs build to ensure that nothing strange happened to the internals in the meantime.

Those are the main things I can think of. Force fields that set such a set of standards would then be eligible for addition to the main distribution, and we can give them some nice designation.  Making such standards explicit would help improve the quality of such simulation anyway, and might help identify some bugs in parameter handling in gromacs.

Best,
~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu<x-msg://8/michael.shirts@virginia.edu>
(434)-243-1821

From: Erik Lindahl <erik.lindahl at scilifelab.se<mailto:erik.lindahl at scilifelab.se>>
Reply-To: "gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>" <gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>>
Date: Friday, February 14, 2014 at 11:47 AM
To: "gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>" <gmx-developers at gromacs.org<mailto:gmx-developers at gromacs.org>>
Subject: Re: [gmx-developers] [gmx-core] removal of encad and gmx FF in 5.0?

Hi,

I would strongly prefer that we do NOT ship forcefields that haven’t had (1) plenty of testing, (2) somebody named who is responsible for each of them, (3) specifics on how to repeat the testing.

The second we ship something with official Gromacs people will start using it, and then they will instantly blame Gromacs if there are errors in the force field. This is exactly why we have separate contributed sections, to make it clear it is not our responsibility.

BSC0 is a concrete example: It was only a week ago I got a mail from Eric Sorin about BSC0 not reproducing some results. For a contributed force field that is the problem of the contributor. If we are shipping it with Gromacs-5.0, it will tarnish our reputation.

Cheers,

Erik

On 14 Feb 2014, at 08:38, Rossen Apostolov <rossen at kth.se<mailto:rossen at kth.se>> wrote:

On 14/02/14 17:12, Mark Abraham wrote:
Removing encad and gmx sounds good. Probably don't have time to rip out the code that supported encad.

I can look at that.

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?

I vote also for Stockholm lipids, it can be quite useful, but hasn't got much publicity.

Rossen

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?

Mark

On Fri, Feb 14, 2014 at 4:39 PM, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru<mailto:alexxy at omrb.pnpi.spb.ru>> wrote:
Hi all!

Its good idea to drop deprecated force fields!

BTW are there any plans to add some new forcefields from contributuions pages?

Peter Kasson писал 14-02-2014 18:47:
Sounds good to me!  If anyone has a burning need to use them, they
can still of course do so, but having them part of the supported
distribution doesn't seem like a good idea at this point.

--Peter

----------------------------------------------------------------------
Peter Kasson, MD, PhD
Assistant Professor
Departments of Molecular Physiology and Biological Physics
 and of Biomedical Engineering
University of Virginia

On Fri, Feb 14, 2014 at 6:39 AM, Erik Lindahl
<erik.lindahl at scilifelab.se<mailto:erik.lindahl at scilifelab.se>> wrote:

Agreed!

On 14 Feb 2014, at 06:37, Rossen Apostolov <rossen at kth.se<mailto:rossen at kth.se>> wrote:

Hi,

Encad and GmxFF have been deprecated for a while. Now before 5.0
is a good time for cleanup, if nobody is using them.

Any objections?

Rossen
_______________________________________________
Gromacs Core Developers mailing list
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-core
[1]

_______________________________________________
Gromacs Core Developers mailing list
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-core
[1]

Links:
------
[1] https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-core

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum at gmail.com<mailto:alexxyum at gmail.com>
mailto:alexxy at gentoo.org<mailto:alexxy at gentoo.org>
mailto:alexxy at omrb.pnpi.spb.ru<mailto:alexxy at omrb.pnpi.spb.ru>

--
Gromacs Developers mailing list

* Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developers or send a mail to gmx-developers-request at gromacs.org<mailto:gmx-developers-request at gromacs.org>.

--
Gromacs Developers mailing list

* Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developers or send a mail to gmx-developers-request at gromacs.org<mailto:gmx-developers-request at gromacs.org>.

--
Gromacs Developers mailing list

* Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developers or send a mail to gmx-developers-request at gromacs.org<mailto:gmx-developers-request at gromacs.org>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140214/602cd507/attachment-0001.html>