Hi Andreas,
Ben also reported similar issues with using xmin. It is only very
recently that Sander and SQM use xmin and lmod from AmberTools. Sander
used to have its own lmod/xmin and SQM didn't use either. The problems
you guys see must be related to the new lmod/xmin drivers. The lmod
and xmin libraries are completely self-contained and thoroughly tested
in AmberTools. If they get the right input, they should work fine. I
will look at the new drivers to see what might be going on and will
probably ask Dave's help since I am not familiar with either Sander or
SQM. It would also make sense to have a single set of lmod/xmin tests,
preferably those already in AmberTools. I'll work on this and will get
back to you.
Istvan
Quoting Andreas Goetz <agoetz.sdsc.edu>:
> Hi,
>
> I have been looking into geometry optimizations with sander using xmin
> (ntmin=3) and sqm (which uses xmin by default). There are two problems
> with the output and the testjobs for sander and sqm fail. This affects
> both the Amber11 development tree (sander and sqm) and the AmberTools
> 1.3 release candidate (sqm).
>
> I am running opensuse 11.2:
> uname -a
> Linux gecko 2.6.31.5-0.1-default #1 SMP 2009-10-26 15:49:03 +0100
> x86_64 x86_64 x86_64 GNU/Linux
>
> I compiled with Intel 11.0.074 with MKL:
> ifort -V
> Intel(R) C Intel(R) 64 Compiler Professional for applications
> running on Intel(R) 64, Version 11.0 Build 20081105 Package ID:
> l_cproc_p_11.0.074
>
> and gnu compilers without MKL:
> gcc --version
> gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
>
> Ross confirmed problems described below for Amber11 with Intel
> Compiler version 10.1.018 on RHEL 5.
>
>
> A) sander:
> ==========
> Amber11 cvs tree (updated Dec 3rd, 2pm)
>
> $AMBERHOME/test/dhfr/Run.dhfr.lmodxmin
> --------------------------------------
> I am attaching my output file (intel compiler) for reference
> (mdout.dhfr.lmodxmin)
>
> There are three issues:
> 1)
> The RMS value of the gradient is printed as being zero for all steps
> of the geometry optimization. The relevant code is in subroutine
> run_xmin ($AMBERHOME/src/sander/lmod.f). The RMS value should be
> returned by function xminc (variable grms), so something goes wrong
> here - any help is appreciated.
>
> In addition, for printing during the geometry optimization, this is
> the *wrong place* to calculate the RMS value of the gradient. The
> gradient is calculated in subroutine gradient_calc *after* call of
> xminc and the progress of the minimization is printed after the
> gradient has been calculated there by subroutine
> report_min_progress. Thus either report_min_progress has to be called
> outside of gradient_calc or the RMS of the gradient has to be
> calculated in gradient_calc. Comments?
>
> 2)
> The second error is that the number of steps NSTEP printed for the
> FINAL RESULTS is wrong. The reason is that the variable xmin_iter (see
> subroutine run_xmin in $AMBERHOME/src/sander/lmod.f) does not count
> the number of iterations correctly. xmin_iter is updated by function
> xminc - any idea what it counts? The variable n_force_calls contains
> the correct number of geometry optimization steps (one force call per
> geometry optimization step) and should probably be used instead. Comments?
>
> 3)
> The geometry optimizer takes different steps. The energies and maximum
> gradient element differ already after the first step.
>
>
> I will file a bug report on the Amber Bugzilla about this.
>
>
> According to the cvs log, the test
> $AMBERHOME/test/dhfr/Run.dhfr.lmodxmin has been created only very
> recently (2009/08/18). I checked the Amber10 manual and the xmin
> method for geometry optimization is described there, so there should
> be other test jobs to verify the implementation. I found only one
> ($AMBERHOME/test/gbrna/Run.gbrna.xmin) but it is not invoked by the
> test Makefiles - any idea why? If invoked, this test fails for the
> same reasons as given above.
>
>
> B) sqm:
> =======
> AmberTools 1.3 RC (AmberTools.24nov09.tar.bz2):
> AmberTools cvs tree (updated Dec 3rd, 2pm)
>
> $AMBERHOME/test/antechamber/sustiva
> -----------------------------------
> I am attaching my output files (intel compiler) for reference
> (sustiva.mol2 and sqm.out)
>
> Charges in mol2 file are different (sustiva.mol2 vs sustiva.mol2.save).
> Reason: sqm needs 105 additional geometry optimization steps to
> converge and the energies are different already during the first
> couple of steps. As a consequence the geometry and charges are
> different. My guess is that this is related to the problems I observed
> for sander since sqm is using xmin for geometry optimization.
>
> I also compared the structures obtained from sqm with mopac (test
> output in Amber10) - the structures (and obtained charges) are
> different. I find this worrisome. Also, sqm requires many more steps
> to converge the geometry than mopac does - this, however, may be
> related to the coordinate set (Cartesian vs internal or redundant
> internal?) in which the optimization is performed. I will set up
> different test cases and look into this.
>
> $AMBERHOME/test/antechamber/ash
> -------------------------------
> Charges in mol2 file are different (ash.mol2 vs ash.mol2.save).
> Reason: Probably same as for $AMBERHOME/test/antechamber/sustiva (no
> sqm.out.save here to check)
>
> All other antechamber tests which use sqm for charge generation
> pass. My guess is that the problem remains but the optimized
> geometries are close enough to generate identical charges (there is no
> way to check because there is no sqm.out.save).
>
> $AMBERHOME/test/sqm/AM1
> -----------------------
> This test is not invoked by "make -f Makefile_at test" (is this
> intentional?).
> However, it fails when invoked manually. Again, the energies of the
> geometry optimization steps are different and an additional 23 steps
> are required for convergence which results in different geometry and
> charges.
>
>
> Thanks for your help and all the best,
> Andy
>
> --
> Dr. Andreas W. Goetz
> San Diego Supercomputer Center
> Tel : +1-858-822-4771
> Email: agoetz.sdsc.edu
> Web : www.awgoetz.de
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Dec 05 2009 - 10:00:04 PST
