On Fri, Apr 29, 2011 at 4:50 PM, B. Lachele Foley <lfoley.uga.edu> wrote:
> 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.
>
This gets my vote.
>
> 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.
>
I vote for no toggle switch! That value is taken from the topology file;
end of story, and that's the *only* way to change it (short of hacking the
code, which users should avoid). IMO, the *only* reason we should support
prmtops that have it is for backwards compatibility. Only. ONE_SCEE and
ONE_SCNB are now part of the topology (as they should be), so to have modern
topology files *not* write that section makes no sense. The only time leap
*doesn't* write a section is if that section will definitely not be needed
(like SOLVENT_POINTERS/ATOMS_PER_MOLECULE in topologies lacking a box), but
1-4 interactions are always calculated, so these sections should always be
included.
Indeed, I would even suggest that maybe any current parm data set should
have the scaling parameters in them by default.
> >> 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.
>
classes are far more flexible/powerful than structs. I could understand the
desire to use C++ instead... Of course I'd probably just write it in
Fortran :).
>
> >> 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
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Apr 29 2011 - 10:30:03 PDT
