Problem in Running Tinker9

[cdpoon]

I have created a Docker image with both Tinker 8.10.1 and Tinker9 (Commit: cdbd05e5) in it. Using the Docker container, I am able to run either dynamic in Tinker 8.10.1 with CPU or dynamic in Tinker9 with GPU acceleration. With 1000 benzene molecules in cubic box, I can get 24ns/day performance using a Quadro RTX 4000 card. Here is the output from "tinker9 info" command.

Primary GPU package :  CUDA

GPU Device :  Setting Device ID to 0 from GPU utilization


Program Information

Version:                             1.0.0 GIT cdbd05e3
Synchronized with Tinker commit:     5aa9948d
C++ compiler:                        nvc++ 21.9.0
Size of real (bytes):                4
Size of mixed (bytes):               8
Using deterministic force:           true
Debug mode:                          off
Platform:                            CUDA and OpenACC
Primary GPU package:                 CUDA
Latest CUDA supported by driver:     11.4
CUDA runtime version:                11.4
Thrust version:                      1.12.1 patch 0
CUDA compiler:                       nvcc 11.4.152
OpenACC compiler:                    nvc++ 21.9.0
GPU detected:                        1
GPU 0:                              
   PCI:                              0000:01:00.0
   Name:                             Quadro RTX 4000
   Maximum compute capability:       7.5
   Single double perf. ratio:        32
   Compute mode:                     default
   Error-correcting code (ECC):      off
   Clock rate (kHz):                 1545000
   Number of Multiprocessors:        36
   Number of CUDA cores:             4608
   Used/Total GPU memory:            9.19 % / 7.79 GB

Then, with a more complicated molecular system, I am running into a problem. In that system, I have no problem running dynamic with Tinker 8. Here is a part of the output.

Current Time                 1.0000 Picosecond
Current Potential         8662.5168 Kcal/mole
Current Kinetic          17324.2839 Kcal/mole
Lattice Lengths           59.942500     59.942500     59.942500
Lattice Angles            90.000000     90.000000     90.000000
Frame Number                      1
Coordinate File             5cb-x512.arc

When I run the same job with Tinker9 (set openmp-threads to 1), I get something like the following.

Current Time                 1.0000 Picosecond
Current Potential   *************** Kcal/mole
Current Kinetic     *************** Kcal/mole
Lattice Lengths      ******************************************
Lattice Angles            90.000000     90.000000     90.000000
Frame Number                      1
Coordinate File             5cb-x512.arc

What have I done wrong? What could be the problem?

Any insight and help would be highly appreciated.

CD Poon.

[zhi-wang]

Would you send me the files and the command you used? This error message doesn't tell us much.

[cdpoon]

4cb-x256.tar.gz

I have attached a gz file which contains 3 files, 4cb-x256.xyz, 4cb-md.key, and amoebabio18_header_4cb.prm.

To run NPT "dynamic" with Tinker 8, I use the following command.
dynamic -k 4cb-md.key 4cb-x256.xyz 1000 1.0 1.0 4 298 1.0

To run NPT "dynamic" with Tinker 9, I use the following command.
tinker9 dynamic -k 4cb-md.key 4cb-x256.xyz 1000 1.0 1.0 4 298 1.0

The output from Tinker 8 looks good. The output from Tinker 9 gives strange output and the arc file contains a bunch of "*".

Thanks again for your help.

[zhi-wang]

It took me a while to figure out what may have caused the immediate crash in the parameters. What I have found so far is that in the functional group "R - C -= N" the local frames for the multipoles on C and N are all defined as the "Z-then-X" frame. Using such a local frame will cause a 0/0 situation in the electrostatic force calculation when the angle R-C-N is 180 degrees.

Tinker8 uses the real*8 type in the Fortran code running on CPU. It will usually survive when the structure is almost (but not exactly) linear. Even if it takes a much longer time for the system to find an almost perfect linear structure to crash, it's still not a good idea to use this local frame. Tinker9 (on GPU) uses the float type for the forces by default, thus it has a much (orders of magnitude) lower tolerance for the near-linear structure.

[cdpoon]

Thank you for your help. Your explanation makes a lot of sense.

In the prm file, the R-C-N angle is set to 179.97 degree. This is obtained by Poltype2. If this angle is changed to a value which is further away from 180, it may help according to what you said. However, it is not realistic.

Is there a way for Tinker9 to handle this situation?

[jayponder]

Yes, Tinker9 can handle this. As Zhi notes, the issue is not a problem with Tinker9, but a problem with the form of the parameters you are using, as generated by POLTYPE2. The correct solution is the use a "Z-Only" local coordinate frame on the nitrile C and N atoms, instead of a "Z-then-X" frame. If POLTYPE2 is using the latter, I would consider it to be a "bug" of sorts since as Zhi has noted it will become unstable when the angle is exactly or very close to linear. I'm sure you can manually get POLTYPE2 to use the "Z-Only" frame at those atoms. But I'll send a note to the POLTYPE guys to let them know that they should change the default.

In the meantime (ie, before you try rerunning POLTYPE2 to manually set the local frame), you can fix the problem by substituting in the following multipole parameters in place of the ones in the file you attached above:

multipole 413 422 0.57823
0.00009 0.00000 0.01087
0.27202
0.00000 0.27202
0.00000 0.00000 -0.54404

multipole 422 413 -0.68494
0.00000 0.00000 -0.58834
0.53161
0.00000 0.53161
0.00000 0.00000 -1.06322

[misterbrandonwalker]

Perhaps this is an older poltype version? The latest will give correct frame assignment. Just be sure to remove all key files before running again.

• Brandon

[cdpoon]

I am using Poltype2 which was pulled from GitHub on December 1st, 2021. Should I use the latest Poltype instead of Poltype2?

[misterbrandonwalker]

That is quite odd since I dont believe I have made any changes in frame detection in a long time on Poltype 2. Please try again with poltype 2 latest commit. I will attach the keyfiles I got below as well input files.

…

On Mon, Jan 17, 2022 at 2:44 PM cdpoon ***@***.***> wrote: I am using Poltype2 which was pulled from GitHub on December 1st, 2021. Should I use the latest Poltype instead of Poltype2? — Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKNB26KNNH65JFP7RAWPTDTUWR5TPANCNFSM5LPRQN7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[misterbrandonwalker]

phenylnitrile.txt
phenylnitrile.xyz_2.txt
poltype.ini.txt
phenylnitrile_postfitmultipole.key.txt

[cdpoon]

Thanks so much for all the help. I have modified the multipole parameters on 4CB according to @jayponder and I do NOT get those "*****" error anymore. Changing local frame for C and N of -CN in 4CB from Z-then-X to Z-Only works really well.

Then, I recompile Poltype2 and build a new Poltype2 Docker image yesterday as suggested by @bdw2292. In the build, it will pull the current distribution of Poltype2 in GitHub. The new Poltype2 build works well for Ph-CH2-CN and @bdw2292 calls it phenylnitrile. Poltype2 creates multipole parameters for C and N correctly and I reproduce what @bdw2292 gets. However, when I use this build to work on cyanobenzene Ph-CN (without CH2 in between Ph and CN), it fails in "Searching database for parameters" right after Psi4 optimization. My old Poltype2 build (20211201) works without error but with frame problem.

It looks like I do not have problem running Tinker9 anymore and now I have Poltype2 problem. Should I switch to Poltype2 channel to discuss?

[misterbrandonwalker]

Thank you for catching that. Basically, last week I added a large database of SMARTS strings for torsion and vdw matching from a large FDA drugbank testing set. Explaining the exact technical issue would get complicated, but essentially its a special case where matching from input molecule to max common substructure of external SMARTS failed. Unfortunately without testing on huge number of molecules every time there are code changes made, sometimes special cases are missed. The latest commit fixes the database matching error.

[cdpoon]

poltype.log
I pulled the Poltype2 distribution on 20220120 and used that to work on a bunch of molecules. Ph-CH2-CN and Ph-CN works really well. For a little more complex molecule, 4CB, it has a n-butyl group, it works fine too. Then, with 5CB, it has similar structure as in 4CB but with n-pentyl group instead of n-butyl group. Poltype2 has problem with 5CB. The Fragmentor in Poltype2 is throwing an error. The error log is attached.

At the moment, I believe it may have something to do with memory size of the machine I use. I am looking into running the same job in another machine. I would like to hear your thought on this.

I notice that in many of the Poltype2 examples, PubChem SDF files are used. PubChem SDF files have information about the molecule besides the coordinates. Are those extra information in PubChem SDF file being used in Poltype2 calculation? When I use Pymol to create the SDF file, it has atomic coordinates only.

[misterbrandonwalker]

Hello,

It appears one of your fragment jobs did not finish (perhaps an error) by the time poltype has finished all other fragment poltype jobs. Could you attach all input and output files in to a zipper folder and upload somewhere? Then I can take a closer look.

Thanks,

• Brandon

[cdpoon]

I can create a tar archive of that Poltype2 run and keep it in a web server. Then, I can email you the URL to download it. Would you mind telling me your email address?

[misterbrandonwalker]

[email protected], Google drive, Box, drop box all of those work as well.

[cdpoon]

Thanks to the amazing support from the Tinker9 and Poltype2 developers. @bdw2292 uploaded an update for Poltype2 to GitHub. With the update, I am able to get Amoeba force field parameters for a bunch of molecules. The local frame assignment for C-CN is correct and Tinker9 works really well with GPU acceleration.

Thanks again to @zhi-wang, @jayponder, and @bdw2292.