I'll provide my 2c, with a note on implementation. Not upgrading sqm will
certainly fix QM/MM in sander, but then the sqm documentation and such will
have to be rolled back to an earlier date if it's been updated with the code
(that may be a bit annoying to actually do).
Also, for the people that *just* download AmberTools (which is far greater
than the number that purchase Amber), sqm 1.5 doesn't really pose any issues
to them.
To avoid having to sit on sqm 1.5 for another year until Amber12 is
released, we can do a couple of things. First, package sqm1.4 into a
different directory that won't cause confusion (for example sander11_qm, or
something of the like). The only thing that would need to change is where
sander's Makefile has to go to build libsqm. This is a very fast, easy
change to the AT15_amber11.py script to get this to work. I can put
together a working example as a proof of concept type of thing if people
would like to try it out.
A compromise between the two (but definitely leaning farther toward the
dual-release) is to release sqm1.4 as a separate, compatibility download
that Amber11 users are required to download and unpack into their amber11
tree to get the 2 to work together properly. We can have it automatically
unpack into amber11/AmberTools/src/sander11_qm (or whatever directory we
choose). Since AT15_Amber11.py has to be run after config.h is written,
anyway, it would be trivial to add a check for the existence of this
sander11-compatible directory and refuse to do the conversion until the new
package was added. It is an extra hoop to jump through, but hardly a
painful one.
Thoughts?
Jason
On Thu, Mar 10, 2011 at 8:00 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> Hi everyone, but especially Jason, Ross, Andy:
>
> Recent tests have shown that sqm in the current git tree is not compatible
> with sander in amber11. So we have a problem with what to do in the
> upcoming
> release.
>
> Here is one idea: don't upgrade sqm in AmberTools 1.5; that is, the sqm
> directory in the tarball that users get would be the same as in AmberTools
> 1.4 (plus relevant bug-fixes). The argument is this: few people really
> use sqm (yet) as a stand-alone tool. It is mostly called behind the
> scenes by antechamber. I don't think(?) anything else in AmberTools
> depends on sqm or libsqm. So, the plan would be to upgrade sqm at the
> next release of sander.
>
> Comments? Objections? Are there improvements in sqm that are
> time-critical
> to get released?
>
> ...thx..dac
>
> [Note: there was a suggestion to have both a "new" and and "old" sqm
> directory, but that seems really quite complicated to explain and actually
> implement.]
>
> _______________________________________________
> 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 Thu Mar 10 2011 - 10:00:02 PST
