On Fri, Nov 11, 2011 at 6:49 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Yes we should go back to the original approach that I put implemented when
> I
> added it to Sander and PMEMD and had Wei put into Sleap. Why was this
> changed??? Where was the rational and the discussion for changing it on the
> AMBER dev mailing list?
>
I'm guessing here a failure to communicate. I freaked out when I first saw
0s there, since I didn't see why those would ever be present. Nowhere did
I actually see a note about why there were 0 terms in the SCEE/SCNB scale
factors, so it's reasonable that they would be removed by those that didn't
know the idea behind them.
> There was a VERY good reason for setting the 1-4 scale factors for
> additional dihedrals and impropers to zero. It is a safety check in the
> code
> and people should not be messing with this!
>
>From the commit logs, it appears as though there were some conflicts
resolved by people modifying the same parts separately (happens all the
time, and git makes this not nearly as bad to deal with). To be fair, a
feature important enough to remain invariant should be documented outside
of mailing list archives ;).
Where are all the test cases guys? - Come on! Messing with leap is probably
> the easiest place to hang us all so whoever updates it needs to be
> EXTREMELY
> CAREFUL and test it extensively. A mistake here could end up wrecking
> research for thousands of people and destroying ALL our reputations so I
> urge you all to be extremely cautious and careful!
>
No explicit test cases had been written for leap since the advent of the
new (10-year-old) format, so we have a *lot* of catching up to do. While
we certainly need to update *what* we test in tleap here, it's hardly just
the people of today's fault for our situation. The existing tests were so
incomplete that it never informed editors that they actually changed
existing behavior.
To make up for lost time, though, I think we have to compare AmberTools 1.5
vanilla (or older?) output with the output from today *and validate* any
changes that have occurred (for instance -- does anybody know if the
difference incurred by the variable 1-4 scaling addition is really just a
rearrangement of dihedral pointers? Was that expected?)
Time to break out the old AmberTools-1.4.tar.bz2 file...
Thoughts?
Jason
P.S. To hop on the bandwagon with Dave here, I think what would *really*
have avoided all of this in the first place is some _developer_
documentation. This would be the ideal place to put stuff like "keep
improper and multi-term dihedral scaling factors 0 because of -blah-", or
"We currently test for -blah-". It's hard enough to go looking through a
manual for information, much less search through mailing archives for
information that you don't even know exists (I had trouble finding my email
about SCEE scale factors from August, and I knew what and who I was looking
for). Dan Roe sets a good example for us all with cpptraj here, but the
best approach for this is probably worth discussing.
--
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 Nov 11 2011 - 22:00:02 PST
