search

openmopac / mopac

Molecular Orbital PACkage
http://openmopac.net
GNU Lesser General Public License v3.0
115 stars 31 forks source link

Is convergence in Mopac v22 inferior to Mopac2016? #129

Closed nwmoriarty closed 1 year ago

nwmoriarty commented 1 year ago

The file below takes 3 times as many SCF iterations on my OSX machine using Mopac v22 compared to Mopac2016. Is this normal or expected?

PM7 CHARGE=0 THREADS=1 qmr_01_chain_A_and_resid_3211_and_resname_PM2_3.5_C_PM7_energy

C 13.82600 0 17.56700 0 16.23200 0 C 17.48600 0 16.95800 0 17.50400 0 C 19.22600 0 16.57800 0 15.57800 0 C 15.27000 0 17.83500 0 16.53200 0 C 17.51100 0 18.47600 0 15.56800 0 C 16.05500 0 18.24000 0 15.23400 0 C 20.00600 0 15.43500 0 16.19000 0 C 20.24300 0 14.19200 0 15.47300 0 C 20.56300 0 15.54500 0 17.48900 0 C 13.41100 0 17.09800 0 14.94500 0 C 21.03500 0 13.12800 0 16.11400 0 C 21.33400 0 11.81000 0 15.41000 0 C 21.52500 0 13.39900 0 17.42600 0 C 22.78500 0 11.63400 0 14.92700 0 C 23.26000 0 12.61500 0 13.89100 0 C 23.03400 0 12.40700 0 12.49800 0 C 23.96600 0 13.82300 0 14.30700 0 C 23.50600 0 13.39900 0 11.50500 0 C 24.42300 0 14.78500 0 13.34600 0 C 12.82700 0 17.77300 0 17.26900 0 C 24.19800 0 14.58600 0 11.93500 0 C 12.04400 0 16.83400 0 14.65900 0 C 11.43300 0 17.50300 0 16.99900 0 C 11.03300 0 17.03600 0 15.70100 0 C 11.67800 0 16.35900 0 13.29300 0 C 15.98600 0 16.59700 0 17.21900 0 N 18.17600 0 17.28200 0 16.22900 0 N 21.28600 0 14.57500 0 18.08600 0 N 11.84700 0 17.44000 0 12.27200 0 O 19.60200 0 16.88800 0 14.45000 0 H 14.14645 1 16.94580 1 14.16889 1 H 13.12185 1 18.11545 1 18.24991 1 H 15.32397 1 18.67492 1 17.22462 1 H 19.86202 1 14.05494 1 14.47177 1 H 20.41329 1 16.44793 1 18.06233 1 H 22.10412 1 12.65508 1 17.95289 1 H 22.51126 1 11.52183 1 12.16693 1 H 24.14251 1 13.99835 1 15.35795 1 H 23.32952 1 13.22949 1 10.45309 1 H 24.94303 1 15.66835 1 13.68611 1 H 24.54973 1 15.30920 1 11.21412 1 H 10.69302 1 17.65750 1 17.77034 1 H 9.99134 1 16.84323 1 15.49081 1 H 17.99203 1 16.11349 1 17.97180 1 H 17.54107 1 17.79530 1 18.19969 1 H 18.06165 1 18.69064 1 14.65213 1 H 17.61888 1 19.34801 1 16.21302 1 H 15.99542 1 17.45648 1 14.47859 1 H 15.62792 1 19.14362 1 14.79905 1 H 20.66995 1 11.70888 1 14.55157 1 H 21.08914 1 10.98446 1 16.07830 1 H 23.44053 1 11.68797 1 15.79617 1 H 22.89287 1 10.62272 1 14.53485 1 H 10.67535 1 15.93298 1 13.32897 1 H 12.34112 1 15.53741 1 13.02213 1 H 11.96741 1 17.00630 1 11.33445 1 H 12.72604 1 17.96252 1 12.46137 1 H 15.49143 1 16.33848 1 18.15531 1 H 15.94555 1 15.71837 1 16.57520 1

godotalgorithm commented 1 year ago

The numerics in MOPAC are not tight enough to guarantee that the same input file will produce the same numerical outputs to all reported decimal places between different versions of MOPAC. In some edge cases, small numerical changes can have outsized effects such as altering decisions to terminate a calculation. The example you have posted is such an edge case. The default convergence criteria for geometric relaxation is a gradient norm of 1, and the calculation reports a gradient norm of 1.09 at geometric relaxation step 19 before the gradient increases again for a while before finally dropping below the convergence criteria at step 54. From your "3 times as many iterations" remark, it is likely that in a previous version the gradient norm at step 19 was slightly below 1 rather than slightly above 1, and the geometry relaxation terminated there. Because of this altered decision, MOPAC is taking longer to finish, but it is not wasted effort as it reduces the heat of formation of the system by an additional 3 kcal/mol during these extra geometry relaxation steps. Specifically for this example, you could mimic the older behavior with the extra keyword GNORM=1.1, which will loosen the convergence criteria enough for the relaxation process to terminate at step 19.

nwmoriarty commented 1 year ago

Thanks for the info.