Wei -- your question is answered below, near a similar question from Jason.
>> 1. old tleap plain -vs- new tleap with SCEE/SCNB written out, but manually changed back to AMBER defaults.
> By this, I assume you mean hack the prmtops to have 1.2 for all scee and 2.0 for all scnb? (or 1 over that as it were)
Yes. And the un-hacked tleap prmtop didn't have any such entries at all.
>> The results from 1 were identical, as
> Results are energies from sander?
Yes, sander was used. The energies are from trajectory post-processing.
>> If you agree with our procedure and with our assessment of the sleap dihedral issue, we will push the changes to tleap.
> Seems reasonable to me. Does it print out any SCEE or SCNB sections if those sections don't exist in the parm files? What if it only exists in some of the parm files?
Currently, it always prints out SCEE and SCNB sections in the topology files (no flag has been set up). If it encounters SCEE and SCNB in some parameter files (for eg. glycam06) it will use those SCEE/SCNB values to overwrite the defaults. If no SCEE and SCNB are found when reading in the parameter file(s) it will assign protein defaults to those.
The kids are arguing to leave SCEE and SCNB output, by default. I can see their point. It is safer to add them automatically. It also makes it easier to identify the values assigned in a simulation. If you have some serious objection to that, though, we can add a switch that will recognize "set default write14scale on". As a compromise, "on" could be the default, and "off" would have to be set explicitly.
>> We'll also make the post-processor available on our site, but we can add it to Amber, too, if you want. We'll probably post the tleap mods to our site, too, to make sure the carb folks see them.
> My personal vote here is to either not post the post-processor to amber or keep it undocumented or something. ... My vote is to do whatever possible to include stuff in leap itself, and on top of that maybe create a little utility (GUI and CL?) that unifies the other utilities in a common wrapper to simplify the process of post processing a topology file.
Ok. We'll just post our utilities on our site until/unless you want them. Probably only carb folks need that particular one anyhow. They'll all be command-line things. Our new codemonkey insists on using C++ (he had to fight for that... and prove he -could- do it in C), in case the language matters. We've also made a checker that will find any common declarations between two force field files. We're using that to make sure that our next parameter set is as orthogonal to others as we can manage.
>> And these two impropers:
>> parm99 X -X -N -H 1.0 180. 2. JCC,7,(1986),230
>> Glycam06 X -X -N -CG 1.5 180. 2. X -X -N -H
> Aye... What would we even say is the right approach here?
The regular parm99 file contains impropers that are semi-redundant. That is, two impropers (say X-X-C-O and X-X-N-H) might fit a given torsion, but only one gets applied. Both tleap and sleap seem to know how to deal with it. We guess sleap only gets confused because these are in separate files. But, we need those values in our file.
When the params are in two separate files, I guess you should do what is currently done for other params. That is, values in subsequently loaded files overwrite values in earlier files. In this way, the user chooses the order of precedence by the file load order. See also statements above about a parm file duplication checker.
:-) Lachele
Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu
________________________________________
From: Wei Zhang [zgjzweig.gmail.com]
Sent: Friday, April 29, 2011 9:59 AM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] alternates to sleap (plus new sleap bug)
Hi Lachele,
About the sleap issue of two improper dihedrals, what do you think would be the correct approach here?
If we are going to choose from one of the two, what is the criteria for choosing?
Sincerely,
Wei
On Apr 28, 2011, at 4:47 PM, B. Lachele Foley wrote:
> In order to do a proper test of tleap versus sleap, we did the following:
>
> 1. Hacked 1-4 scaling writes into tleap.
> 2. Wrote a separate program, independently, that adds SCEE/SCNB to an existing top.
>
> Then, we compared output from post-processing an existing trajectory for a system containing both a glycan and a protein using top files produced by:
>
> 1. old tleap plain -vs- new tleap with SCEE/SCNB written out, but manually changed back to AMBER defaults.
> 2. new tleap with SCEE/SCNB -vs- the post-processor we wrote
> 3. new tleap with SCEE/SCNB -vs- sleap with SCEE/SCNB
>
> The results from 1 were identical, as were the results from 2. There was a small difference in the sleap dihedrals from 3 (explained below).
>
> If you agree with our procedure and with our assessment of the sleap dihedral issue, we will push the changes to tleap.
>
> We'll also make the post-processor available on our site, but we can add it to Amber, too, if you want. We'll probably post the tleap mods to our site, too, to make sure the carb folks see them.
>
> Here's the sleap issue.
>
> Consider these atom types relevant to an improper dihedral: CG, N, H, C
>
> And these two impropers:
> parm99 X -X -N -H 1.0 180. 2. JCC,7,(1986),230
> Glycam06 X -X -N -CG 1.5 180. 2. X -X -N -H
>
> When tleap generates a top file, the CG-N-C-H improper dihedral is specified only once. When sleap generates the top file, the improper is defined twice (once as CG-N-C-H and once as CG-C-N-H). We also checked comparing old tleap (no SCEE/SCNB) and sleap without using "write14scale". The improper is again defined twice by sleap and once by tleap.
>
> :-) Lachele
> Dr. B. Lachele Foley
> Complex Carbohydrate Research Center
> The University of Georgia
> Athens, GA USA
> lfoley.uga.edu
> http://glycam.ccrc.uga.edu
>
> _______________________________________________
> 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 Fri Apr 29 2011 - 08:00:08 PDT
