Hi,
As Jason pointed out, very few (if any) people really use sqm as
standalone, and not upgrading it will fix sander's QM/MM. Besides
fixing the manual, would there be any real gain in releasing the new
sqm now? Shouldn't sqm releases be more in sync with new sander
releases?
Gustavo Seabra
Professor Adjunto
Departamento de Química Fundamental
Universidade Federal de Pernambuco
Fone: +55-81-2126-7417
On Thu, Mar 10, 2011 at 2:31 PM, Jason Swails <jason.swails.gmail.com> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 10 2011 - 11:00:06 PST
