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 AT15_Amber11.py 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, AT15_Amber11.py 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 AT15_Amber11.py after it's over, or just print out a warning that you
need to run that script afterwards?
Note that this will force AT15_Amber11.py 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 AT15_Amber11.py prints, which avoids the
issues mentioned above (but AT15_Amber11.py would still need to be run for
Amber11 to properly work with AmberTools 1.5).
Thoughts?
Jason
On Thu, Mar 10, 2011 at 11:32 AM, David A Case <case.biomaps.rutgers.edu>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 AT15_amber11.py script to get this to work.
>
> ....dac
>
>
> _______________________________________________
> 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 - 14:00:02 PST
