Re: [AMBER-Developers] sqm and AmberTools 1.5

From: Jason Swails <>
Date: Thu, 10 Mar 2011 13:35:44 -0800

So I've been playing around a little more with building AmberTools 1.5 with
sqm from amber11-with-patches, and found an issue involved with just using
dropping in sqm 1.4:

Basically, sqm 1.4 knows nothing about the changes that have been done to
configure and how config.h is now set up differently, so the make fails
immediately with a mountain of errors. I was able to fix this by just
dumping the revised config.h created by in $AMBERHOME/src
into $AMBERHOME/AmberTools/src. Mostly, the changes I made were just adding
in config.h variables used by Amber11/AT1.4 that were dumped in favor of
more flexible versions some time ago; but I did add to some other variables
in a way that should make no difference to 99% of users, but which
sacrifices some of the flexibility introduced with the new suite of flags.

To get this to work, would have to be run immediately after
configure was run, and it would have to be modified to edit the config.h in
$AMBERHOME/AmberTools/src as well.

Should I modify configure in the at15-with-patches branch to automatically
call after it's over, or just print out a warning that you
need to run that script afterwards?

Note that this will force to be necessary even for
AmberTools 1.5 sans Amber11, which may be as confusing as having sqm and
sander_qm present in the same release (?). Alternatively we could just
modify AmberTools1.5 configure script to automatically dump out the revised
form of the config.h file that prints, which avoids the
issues mentioned above (but would still need to be run for
Amber11 to properly work with AmberTools 1.5).



On Thu, Mar 10, 2011 at 11:32 AM, David A Case <>wrote:

> On Thu, Mar 10, 2011, Jason Swails wrote:
> > 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...
> A key question here is: how much has really been updated in the stand-alone
> sqm since last April? Is the problem that Jason identifies (documentation
> changes) a serious one? Is there a reason to want to get version 1.5 of
> the stand-alone code out there in a more timely fashion (i.e. before the
> next
> release of sander)?
> My feeling from the meetings (and from monitoring code going into git) is
> that
> almost all recent development has been on the QM/MM side (e.g. getting
> various
> ab-initio codes hooked in, either directly or through PUPIL, having
> adaptive
> QM/MM boundaries, etc.) But if I am missing things, then Jason's
> suggestion
> (below) is probably the way to go. So, the sqm people need to chime in
> here.
> > To avoid having to sit on sqm 1.5 for another year until Amber12 is
> > released, we can ... 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 script to get this to work.
> ....dac
> _______________________________________________
> AMBER-Developers mailing list

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
AMBER-Developers mailing list
Received on Thu Mar 10 2011 - 14:00:02 PST
Custom Search