PS: We included significant discussion on proper reporting of simulation results in a review a while back. Bits of that could be used/adapted/referenced. If there are other refs, they could go in, too.
http://onlinelibrary.wiley.com/doi/10.1002/wcms.89/abstract
It also contains lots of history, etc. about carb ffs.
:-) 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: B. Lachele Foley <lfoley.ccrc.uga.edu>
Sent: Sunday, March 8, 2015 5:53 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] force-field naming (redux)
Adding a version number makes it much more palatable. I still think the instructions should say to copy the file for their records (for source-file changes, lost AMBERHOME directories, etc.).
Re review system: It might not be our job, but we are the best able to help with this part. Why not make a list of minimum recommendations for an experimental section? That would be useful for reviewers and for researchers. Increasingly, papers are so multi-disciplinary that 2 or 3 reviewers can't possibly be qualified to assess everything. Also, having a minimum chunk of things to know and worry about would help people feel more oriented and comfortable using MD if they aren't experts.
I think a new section in the parmtop file is still a very good idea, too. But, that can't happen quite yet. We'll definitely add it into GMML writes.
:-) 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 5:33 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] force-field naming (redux)
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
_______________________________________________
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
