TinkerTools / tinker

Tinker: Software Tools for Molecular Design
https://dasher.wustl.edu/tinker/
Other
130 stars 61 forks source link

Bug in potential fitting #129

Closed zjing7 closed 1 year ago

zjing7 commented 1 year ago

There is a bug in potential fitting (POTENTIAL option 6) that, in rare cases, causes a shift of the multipole parameters after fitting, and thus makes the output parameters even worse than the initial one. A workaround is to change RESP-WEIGHT to a slightly different value. I used the latest version built on Ubuntu 22.04 (gfortran 11.3), but the prebuilt executables for Linux and MacOS (https://dasher.wustl.edu/tinker/) work fine. I think the same issue happened in a very early version and was fixed.

Please see the attached example.

resp_0.8.log: Root Mean Square Potential Difference :              1.4791
resp_0.8.log: Root Mean Square Potential Difference :              0.2012
resp_1.0.log: Root Mean Square Potential Difference :              1.4791
resp_1.0.log: Root Mean Square Potential Difference :              2.8677
resp_1.2.log: Root Mean Square Potential Difference :              1.4791
resp_1.2.log: Root Mean Square Potential Difference :              0.2157

potfit_fenuron.tgz

jayponder commented 1 year ago

Thanks, I'll track this down. The behavior appears "correct" for the values of 0.8 and 1.2 that you have tried, but also for other values closer to 1.0. The least squares optimization and the resulting multipole values are, I think, correct even for 1.0. So it's something in the RMS calculation or after that point.

jayponder commented 1 year ago

It's not related to the problem with the potential fitting, but I'd also note that this molecule has another of our "problem" functional groups. Urea groups are definitely flat in solution, but in gas phase QM the nitrogens are puckered. This is kind of like the situation with anilines, only worse..

jayponder commented 1 year ago

This is now fixed, and the corrected version is pushed to GitHub. The issue was rare. It only occurred when a parameter being fit was initially nonzero, then optimized to "zero" to at least five decimal places during the least squares fitting. In that case the fitting results were still fully correct, but the parameter got removed from the list of fit values following the least squares, resulting in an indexing bug when writing summary statistics and the new key file.