- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Andreas Goetz <agoetz.sdsc.edu>

Date: Thu, 17 Dec 2009 16:24:26 -0800

Hi Dave,

Thanks for checking this out. The antechamber tests now pass both with

gnu gcc-4.4.1 and intel 11.0.074 with mkl. Tiny numerical differences

remeain, sqm requires a couple more geometry optimization steps (I

checked the sustiva and ash examples), with both compilers. But I think

this is not an issue, after all, the geometry convergence criteria are

extremely tight (but see below my question on the number of required steps).

*> It turns out that the default behavior for sqm has gradients that are not
*

*> accurate enough. If you set "grms_tol=0.0001, tight_p_conv=1,
*

*> scfconv=1.d-10," in the namelist input for sqm, you then get good behavior
*

*> with the TCNG minimizer, as expected, and as we see with MM gradients (which
*

*> are essentially exact.)
*

This is good to know (but see my question below). It means that the

implementation of the gradients is correct and the observed problems

result from insufficiently converged MOs/density. Otherwise I would not

have known how to test for small numerical errors as in my experience it

is difficult to obtain numerical (finite difference) gradients with an

accuracy better than 1.E-4 au or 0.1 kcal/(mol*A).

Convergence of the density matrix in SCF methods can be a much more

stringent criterium than energy. The energy can already be stable while

the MOs/density and consequently molecular properties (like gradients)

are not. It would be nice if the user could control both parameters

independently (now tight_p_conv is coupled to scfconv).

The behavior of TNCG is different from what I am used to see in other QM

programs (with different optimizers) - the SCF convergence and accuracy

of gradients does in my experience not affect the rate of convergence

but merely limit the final accuracy. Thus, if one is satisfied with less

stringent geometry convergence criteria one can also use less stringent

SCF convergence criteria.

Here my question:

I wanted to play around with scfconv, tight_p_conv and grms_tol and

turned on verbosity. For the ash test I get for the standard non-verbose

output

...

sqm energy: 50 -179.5406 0.001885

sqm energy: 60 -179.5406 0.000357

Final SCF energy is -179.540648949995

Turning on verbosity shows that there is *many more* calls to the

energy/gradient routines than what is apparent from sqm's output. I

printed the number of force calls in the do while loop in xmin.f and it

counts 870 calls... this means that the TNCG optimizer does not need 60+

steps but rather almost 900... if this is correct there is still

something wrong with the optimizer, interface, or gradients. So what

does the variable xmin_iter actually count? Or did I overlook something?

Switching back to LBFGS results in 846 force calls.

*> But this also leaves open the question of what the defaults should be for
*

*> sqm as used in QM/MM molecular dynamics. I don't know how much testing was
*

*> done, but it is of concern that the default for tight_p_conv is zero, since
*

*> Istvan's analyis shows that this is dangerous, at least for minimization.
*

*> I'm not changing things right now, since that would probably involve updating
*

*> every one of 100 or so QM/MM test cases (sigh), but it is something that
*

*> I'd like to get comments on.
*

I guess we will have to look into this.

All the best,

Andy

Date: Thu, 17 Dec 2009 16:24:26 -0800

Hi Dave,

Thanks for checking this out. The antechamber tests now pass both with

gnu gcc-4.4.1 and intel 11.0.074 with mkl. Tiny numerical differences

remeain, sqm requires a couple more geometry optimization steps (I

checked the sustiva and ash examples), with both compilers. But I think

this is not an issue, after all, the geometry convergence criteria are

extremely tight (but see below my question on the number of required steps).

This is good to know (but see my question below). It means that the

implementation of the gradients is correct and the observed problems

result from insufficiently converged MOs/density. Otherwise I would not

have known how to test for small numerical errors as in my experience it

is difficult to obtain numerical (finite difference) gradients with an

accuracy better than 1.E-4 au or 0.1 kcal/(mol*A).

Convergence of the density matrix in SCF methods can be a much more

stringent criterium than energy. The energy can already be stable while

the MOs/density and consequently molecular properties (like gradients)

are not. It would be nice if the user could control both parameters

independently (now tight_p_conv is coupled to scfconv).

The behavior of TNCG is different from what I am used to see in other QM

programs (with different optimizers) - the SCF convergence and accuracy

of gradients does in my experience not affect the rate of convergence

but merely limit the final accuracy. Thus, if one is satisfied with less

stringent geometry convergence criteria one can also use less stringent

SCF convergence criteria.

Here my question:

I wanted to play around with scfconv, tight_p_conv and grms_tol and

turned on verbosity. For the ash test I get for the standard non-verbose

output

...

sqm energy: 50 -179.5406 0.001885

sqm energy: 60 -179.5406 0.000357

Final SCF energy is -179.540648949995

Turning on verbosity shows that there is *many more* calls to the

energy/gradient routines than what is apparent from sqm's output. I

printed the number of force calls in the do while loop in xmin.f and it

counts 870 calls... this means that the TNCG optimizer does not need 60+

steps but rather almost 900... if this is correct there is still

something wrong with the optimizer, interface, or gradients. So what

does the variable xmin_iter actually count? Or did I overlook something?

Switching back to LBFGS results in 846 force calls.

I guess we will have to look into this.

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-developersReceived on Thu Dec 17 2009 - 16:30:02 PST

Custom Search