I'm not sure give g them a leaprc version to quote in their manuscript is
enough, even if we can decide it. Most readers won't be able to, and even
though reviewers should be better about it, we do need to make it easy for
when reviewers do ask the right questions (or users want to cite the right
things). I think Lachele's suggestion makes sense - our outputs should list
what force fields were used and maybe give the citation in some standard
format, or the doi. That has to someone be in the library files and get
passed from leap to prmtop to sander/pmemd.... Might not be doable this
release, but it makes sense to me.
I think we should try to specify which of the various polymer/ molecule
params are in each leaprc like Ross said. One complication is that there
is overlap between atom types so you can't load a protein set without
loading some sort of nucleic set too. Maybe this was Jason's concern. Maybe
we just use really long labels on the leaprc files so they know what they
will get from each?
On Mar 8, 2015 5:33 PM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
> What about calling it: leaprc.amber15
>
> And then 'in principal' if they list the version number of the code they
> used properly then one would have a good idea which force field they used.
>
> That said it beyond our remit to fix a broken peer review system so I
> wonder how much we should lean on just making it easy and less confusing
> for new users vs making it easier to post sim decipher what settings /
> parameters one used in a simulation.
>
> All the best
> Ross
>
> > On Mar 8, 2015, at 2:07 PM, B. Lachele Foley <lfoley.ccrc.uga.edu>
> wrote:
> >
> > I like this very much in principle. But, experimental sections for MD
> studies are already likely to be useless. They use the "AMBER force field"
> in an "AMBER simulation". Sometimes, they give the release number.
> Sometimes, the citation even matches the release number.
> >
> > That is, I think we should also make it a no-brainer for users to know
> precisely which force fields they used - even better if we also record the
> names of any external files (pdb, mol2, etc.) that were used. So, I think
> that first we need a section in the topology files called "SOURCES" or
> "PROVENANCE" or whatever. And, I cannot write this right now... But, in
> principle I volunteer.
> >
> > In the meantime, the directions could strongly suggest that they copy
> the leaprc.default to their local directory as part of their scientific
> record. Indeed, that could be Step 1. But, I really think we need a
> better mechanism eventually.
> >
> > I wouldn't be opposed to a "minimum information to include in your
> experimental section" bit in the manual, too.
> >
> > :-) Lachele
> >
> > Dr. B. Lachele Foley
> > Associate Research Scientist
> > Complex Carbohydrate Research Center
> > The University of Georgia
> > Athens, GA USA
> > lfoley.uga.edu
> > http://glycam.org
> >
> > ________________________________________
> > From: Ross Walker <ross.rosswalker.co.uk>
> > Sent: Sunday, March 8, 2015 3:40 PM
> > To: AMBER Developers Mailing List
> > Subject: Re: [AMBER-Developers] force-field naming (redux)
> >
> > I would like there to be a 'default' force field that is either:
> >
> > 1) Loaded by leap by default.
> >
> > 2) Loaded with 'source leaprc.default'
> >
> > This would make things a lot simpler for beginning users. Option 1 might
> prove troublesome since I don't know how well one can unload parameter sets
> in leap if you wanted to switch things out so option 2 with documentation
> might be optimal.
> >
> > I would suggest it be:
> >
> > source leaprc.ff14SB
> > source leaprc.gaff
> > source leaprc.GLYCAM_06j-1
> > source leaprc.lipid14
> > loadamberparams frcmod.ionsjc_tip3p
> >
> > This would be good since it will also give us early warning in the
> future of atom type clashes, incompatibilities etc.
> >
> > Does it make sense to make TIP3P with ionsjc the default water model and
> ion parameters? - These are probably the most commonly used.
> >
> > What do people think?
> >
> > Then we just have a 'quickstart' section as it were in the manual (and
> we update the tutorials to use this default) and then in the future we can
> update this with whatever is the latest set of force fields we recommend.
> >
> > All the best
> > Ross
> >
> >> On Mar 8, 2015, at 6:31 AM, David A Case <case.biomaps.rutgers.edu>
> wrote:
> >>
> >> We have not yet addressed the problem of force field naming that was
> brought
> >> up at the Amber developers' meeting in February. Some notes:
> >>
> >> 1. Section 3.2.1 of the manual still reads as though ff14SB is only for
> >> proteins. There is one tiny sentence, many paragraphs later, that
> indicates
> >> it could also be used for RNA; nothing about whether it might be good
> for a
> >> combination of proteins and nucleic acids.
> >>
> >> 2. Table 3.1 is not as helpful to users as it should be. It lists of
> bunch
> >> of modifications, but gives no indication of *how* to load any of the
> force
> >> fields that are listed there.
> >>
> >> 3. We talked about having separate leaprc files for proteins, DNA and
> RNA,
> >> but Jason has noted potential problems with this. I don't have a
> suggested
> >> solution (and I've not really heard one): but we need very soon to come
> to
> >> some agreement, and to have appropriate leaprc files for various
> recommended
> >> combintations of parameters.
> >>
> >> 4. On a related topic: we need a better way for a user to specify
> water and
> >> ion parameters. Specifying TIP3P water should automatically load the
> >> associated ion paramters; same for other supported water models. This
> should
> >> probably be implemented by having a leaprc.tip3p that performs these
> actions.
> >>
> >> 5. (I can do this one): the beginning of section 3.1 should probably
> suggest
> >> to people that they load a "leap.in" file, which in turn would load
> *several*
> >> leaprc files for the components they need. That is, the "standard"
> would be
> >> to expect to load at least a protein and a water/ion file; if there are
> >> ligands, one would usually load leaprc.gaff; if one has lipids
> >> or nucleic acids or carbohydrates, one would load additional files.
> >>
> >> Suggestions are both welcome and needed....thx...dac
> >>
> >>
> >> _______________________________________________
> >> AMBER-Developers mailing list
> >> AMBER-Developers.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 08 2015 - 15:30:02 PDT
