Tinker-OpenMM can correctly read non-orthogonal box dimensions from xyz file and run simulations, but when writing dyn and arc files, it incorrectly takes the diagonal components of the box vector as the lattice parameters [a, b, c]. Because the coordinates are move into the wrong (smaller) box, this causes overlap between atoms.
For example, with input lattice parameters:
117.9256 117.9256 117.9256 109.471219 109.471219 109.471219
the box vectors in the dynamic_omm output are

Box Vectors:      117.9256       0.0000       0.0000
  (Ang)          -39.3085     111.1813       0.0000
                 -39.3085     -55.5906      96.2858

The lattice parameters in the arc and dyn files become
117.9256 111.1813 96.2858 109.471219 109.471219 109.471219

Hello,

I see you guys updated ion parameters in amoeba09.prm but original paper title for parameters says "P. Ren and J. W. Ponder, "Polarizable Atomic Multipole Intermolecular
Potentials for Small Organic Molecules", in preparation." should this be the 2011 paper, Polarizable Atomic Multipole-Based Molecular Mechanics for Organic Molecules ?

• Brandon

We found for organic crystals, the vibrate executable computes non-physical vibrations. We expect the vibration to be 3 zero wavenumbers and 3*N-3 positive wavenumbers (where N is the number of atoms). Instead, the current version produces negative wavenumbers on the magnitude of -5 to -100 cm^-1.

If a finite difference approach is implemented using echarge1.f the issue is resolved. We have verified that the results with this fix match those of the numerical Hessian using testhess. We have our own implementation of the fix that we would be happy to share, but it has not been tested to assure it won't cause issues for executables other than vibrate.

When I try to run scan with either an xyz and key file generated with sdf2tinkerxyz for toluene or benzene (sdf files obtained from pubchem) I get the following error:

$ scan toluene.xyz -k toluene.key 0 10 20 0.00001 | tee toluene.tout

    ######################################################################
   ##########################################################################
  ###                                                                      ###
 ###            Tinker  ---  Software Tools for Molecular Design            ###
 ##                                                                          ##
 ##                          Version 8.7  June 2019                          ##
 ##                                                                          ##
 ##               Copyright (c)  Jay William Ponder  1990-2019               ##
 ###                           All Rights Reserved                          ###
  ###                                                                      ###
   ##########################################################################
     ######################################################################


 Additional Partial Charges for Specific Atoms :

        Atom                Charge

           1                0.1500
           2               -0.1500
           3               -0.1500
           4               -0.1435
           5                0.1500
           6               -0.1500
           7               -0.1500
           8                0.1435
           9                0.1500
          10               -0.1500
          11                0.1500
          12                0.0000
          13                0.0000
          14                0.0000
          15                0.1500

 Number of Torsions Used in Derivative Computation :     1

 Generating Seed Point for Potential Energy Surface Scan


    Potential Surface Map       Minimum      1               18.4174


 Normal Mode Local Search       Minimum      1


free(): invalid pointer

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x82337D
#1  0x80E360
#2  0x7FAFD682EFCF
#3  0x7FAFD682EF47
#4  0x7FAFD68308B0
#5  0x7FAFD6879906
#6  0x7FAFD6880979
#7  0x7FAFD6887E8B
#8  0x40AF19
#9  0x4062BC
#10  0x4068A3
#11  0x406F57
#12  0x402D4C
#13  0x7FAFD6811B96
#14  0x404FEC
Aborted

I do not know how to begin addressing this issue since tinker is written in fortran.

I do not get this error when I run scan on other molecules such as m-xylene.sdf, L-cysteine.sdf, and D-Leucine.sdf (all sdf files obtained from pubchem).

Dear Developers,

I am a new user to TINKER. I would like to calculate the IR spectrum of the peptide under the polarizable force field AMOEBA (amoebapro13.prm). Instead of creating the solute and inserting it into a water solvent, I created the xyz files of peptide, water box and counter ions separately and then concatenated them together. I assume the atom contacts are acceptable, as the atom coordinates are from an equilibrated system I simulated before with GROMACS under classical force fields.

The energy minimization seemed ok. But I got an energy burst in the NVT process and the program terminated. I can't really figure out why. Could you help me on this? Many thanks.

Attached are the log file, the coordinate files and the parameter files.

All the best,
Yangmei
tinker_files.zip

This is weird one, but it only shows up when running on more than 1 thread. Here's a an example to reproduce.

xyzfile: watersmall.xyz
keyfile:

parameters	./water03.prm

openmp-threads 20

ewald
pme-grid 6 6 6

neighbor-list
a-axis 18.643

cutoff 7
taper 6

If you print out the grid, qgrid, in grid_mpole. The elements will be different every time. If you set openmp-threads 1, then the problem goes away.

This is probably a pretty inconsequential bug. If you set the grid size to something reasonable, like 20x20x20, the error goes away.

Hi Jay,

Within the poledit 'priority' function, (line 1034 onwards), the loop for assigning the priority of bonded atoms is slightly different for atom ia and atom ib. In my view, lines 1076-1079 should read:

if (m .ge. kb1) then
   kb2 = kb1
   kb1 = m
else if (m .gt. kb2) then

similarly to lines 1062-1065 for atom ia / atomic no. ka2. This causes problems with automatic frame assignment in very rare cases, so just wanted to check this wasn't deliberate for any reason before submitting a pull request. I can provide an example case if needed. Thanks go to Asmit of Teresa Head-Gordon's group for pointing this out.
Thanks,
Richard

Hi,
I am writing this here since I could not find the forum for TINKER.
How can we change the parameter file so that a non standard residue can also used? Consider a case in which there is a bond between two standard residues.

My aim is to do QM/MM dynamics with SHARC. So I am using the tinker 6.3.3 coming with OpenMolcas.

Thanks and Regards,
Jo

When applying pdbxyz with the forcefield oplsaa.prm some of the atomtypes don't seem to fit perfectly:

• In amino acid isoleucine the C atom of the CH2 group gets atomtype 80 ("Alkane CH3-") whereas the C atom of the neighboring CH3 group gets atomtype 81 ("Alkane -CH2-"). Shouldn't it be the other way round?
• In lysine the C atom of the CH2 group which is next to the NH3+ receives atomtype 235 ("CH3NH3+"). Shouldn't atomtype 236 ("RCH2NH3+") be assigned instead?
• In N-terminal proline the C_delta atom gets atomtype 187 ("PRO CD") although atomtype 239 ("N-Terminal PRO CD") is exclusively for this purpose.

I've encountered some issues with the parameters of uAMOEBA water published in Qi et al., 2015. J. Chem. Phys., 143, 014504. Since this model is not implemented into Tinker 8.7 by default (that's the version I am currently using), I modified water03.prm using the parameters shown in Table 1 of the original paper. However, when starting minimize.x, dynamic.x or analyze.x I am observing that Tinker 8.7 gets stuck or crashes. I tried to fix these issues and isolated this issue to be due to the multipole parameters of the H atoms being zero throughout (1=O, 2=H):

multipole 2 1 2 0.00000
0.00000 0.00000 0.00000
0.00000
0.00000 0.00000
0.00000 0.00000 0.00000

Until now, I was not able to solve these issues in Tinker 8.7. I solely managed to get it to work in Tinker 6.3.3, when changing at least one multipole component to small values such as 0.000001. I attached my current uwater.prm file, that works in Tinker 6.3.3 below (with those small multipole components where water03 had some unequal to 0). Maybe, upon closer inspection, you'll find some issues that I've overlooked. Also, below the prm file are some error messages I obtained in Tinker 8.7 and 6.3.3, when all multipole components of H are zero.

Thanks for looking into this issue.

uwater.prm:
##############################
## ##
## Force Field Definition ##
## ##
##############################

forcefield uAMOEBA-WATER
#Added based on water03 and the paper cited below

bond-cubic -2.55
bond-quartic 3.793125
angle-cubic -0.014
angle-quartic 0.000056
angle-pentic -0.0000007
angle-sextic 0.000000022
opbendtype ALLINGER
opbend-cubic -0.014
opbend-quartic 0.000056
opbend-pentic -0.0000007
opbend-sextic 0.000000022
torsionunit 0.5
vdwtype BUFFERED-14-7
radiusrule CUBIC-MEAN
radiustype R-MIN
radiussize DIAMETER
epsilonrule HHG
dielectric 1.0
polarization MUTUAL
vdw-12-scale 0.0
vdw-13-scale 0.0
vdw-14-scale 1.0
vdw-15-scale 1.0
mpole-12-scale 0.0
mpole-13-scale 0.0
mpole-14-scale 0.4
mpole-15-scale 0.8
polar-12-scale 0.0
polar-13-scale 0.0
polar-14-scale 1.0
polar-15-scale 1.0
polar-12-intra 0.0
polar-13-intra 0.0
polar-14-intra 0.5
polar-15-intra 1.0
direct-11-scale 0.0
direct-12-scale 1.0
direct-13-scale 1.0
direct-14-scale 1.0
mutual-11-scale 1.0
mutual-12-scale 1.0
mutual-13-scale 1.0
mutual-14-scale 1.0

  #############################
  ##                         ##
  ##  Literature References  ##
  ##                         ##
  #############################

R. Qi, L.-P. Wang, Q. Wang, V. S. Pande, P. Ren, "United
polarizable multipole water model for molecular mechanics
simulations", J. Chem. Phys., 143, 014504 (2015)

  #############################
  ##                         ##
  ##  Atom Type Definitions  ##
  ##                         ##
  #############################

atom 1 1 O "AMOEBA Water O" 8 15.995 2
atom 2 2 H "AMOEBA Water H" 1 1.008 1

  ################################
  ##                            ##
  ##  Van der Waals Parameters  ##
  ##                            ##
  ################################

vdw 1 3.7553 0.1420
vdw 2 0.0000 0.0000 0.000

  ##################################
  ##                              ##
  ##  Bond Stretching Parameters  ##
  ##                              ##
  ##################################

bond 1 2 557.55 0.9499

  ################################
  ##                            ##
  ##  Angle Bending Parameters  ##
  ##                            ##
  ################################

angle 2 1 2 48.93 105.95

  ###############################
  ##                           ##
  ##  Urey-Bradley Parameters  ##
  ##                           ##
  ###############################

ureybrad 2 1 2 -9.74 1.5168

  ###################################
  ##                               ##
  ##  Atomic Multipole Parameters  ##
  ##                               ##
  ###################################

multipole 1 -2 -2 0.00000
0.00000 0.00000 0.70889
2.08011
0.00000 -2.08828
0.00000 0.00000 0.00817

multipole 2 1 2 0.00000
-0.00000001 0.00000 -0.00000001
-0.00000001
0.00000 -0.00000001
-0.00000001 0.00000 0.00000001

  ########################################
  ##                                    ##
  ##  Dipole Polarizability Parameters  ##
  ##                                    ##
  ########################################

polarize 1 1.7209 0.390

A few error messages that I obtained:

1. Tinker gets stuck and finally crashes, when running MINIMIZE:

SD Iter F Value G RMS F Move X Move Angle FG Call Comment
0 -8188.6155 NaN 1

2. With dynamic it starts loading parameters and ends with:
   ...
   Valence 9719-H 2 0 1
   Valence 9720-H 2 0 1
   Valence 9721-O 1 0 2
   Valence 9722-H 2 0 1
   Valence 9723-H 2 0 1
   Valence 9724-O 1 0 2
   Valence 9725-H 2 0 1
   Valence 9726-H 2 0 1
   Valence 9727-O 1 0 2
   Valence 9728-H 2 0 1
   Valence 9729-H 2 0 1

Tinker is Unable to Continue; Terminating the Current Calculation

3. Though it's possible to start analyze, using option M I get a segmentation fault:

Total Electric Charge : 0.00000 Electrons

Dipole Moment Magnitude : 127.490 Debye

Dipole X,Y,Z-Components : -34.875 105.286 62.868

Quadrupole Moment Tensor : -246.924 -879.025 1794.891
(Buckinghams) -879.025 -160.170 -1411.151
1794.891 -1411.151 407.095

Principal Axes Quadrupole : -1801.976 -1016.433 2818.409
Radius of Gyration : 22.992 Angstroms

Center of Mass Coordinates : -0.111634 0.048246 0.053490
Euler Angles (Phi/Theta/Psi) : -64.611 -22.599 149.178

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7f961d8cd33f in ???
#1 0x7f961e7fadd0 in save_parsed_format
at ../../../libgfortran/io/format.c:146
#2 0x7f961e80a187 in data_transfer_init
at ../../../libgfortran/io/transfer.c:2794
#3 0x4c83ac in ???
#4 0x404712 in ???
#5 0x414a21 in ???
#6 0x40269c in ???
#7 0x7f961d8b9494 in ???
#8 0x4026eb in ???
#9 0xffffffffffffffff in ???
Segmentation fault

Hi,
While using the enkephalin example which is based on the MM3pro ff, I've experienced that the numerical and analytical Hessian elements can differ much. For instance:
Comparison of Analytical and Numerical Hessian Elements :
1st Atom 2nd Atom Analytical Numerical Difference
...
16 (Y) 16 (Y) 5.8317 -14.3572 20.1889
16 (Y) 16 (Z) 17.6193 21.9278 -4.3085
16 (Y) 23 (X) 51.6569 46.2261 5.4308
16 (Y) 23 (Y) 45.3146 57.9164 -12.6018
16 (Y) 23 (Z) -0.5540 -3.0916 2.5375
...
in a calculation with van der Waals interactions only.

pdbxyzoutput.txt
isolecuine.txt

Hello,

When I attempt to use a single amino acid, pdbxyz throws in error (above in pdbxyzoutput.txt), however when I use two Isolecuines (built via pymol then convert to correct atom labels via babel) then pdbxyz works fine.

• Brandon

Hi there,

It would be nice to start using this shiny interface for talking about code. :)

One of our current goals is to carry out the mutual AMOEBA parameterization with condensed phase properties using TINKER as the MD engine. In order to do this, TINKER’s “analyze” program needs to rapidly loop over the MD trajectory and recompute the energies, but the .arc file contains no box information. The current solution (using unmodified TINKER) would involve writing a new .key file and calling “analyze” for each frame, which would be too time-consuming because "analyze" needs to be loaded into memory for each frame. It would be nice if the box information could be loaded as the program iterates over the trajectory.

My current solution involves modifying TINKER to write a separate “.box” file during the molecular dynamics, and when TINKER loops over the trajectory using “analyze”, it reads the .arc and .box files at the same time. This is sort of a clunky solution, and I can’t always keep my version up-to-date with the official code. Furthermore, I’m not sure if you think it’s a good idea to bundle the modified TINKER with ForceBalance, since the licenses are different.

Because of this, I’m hoping that we could revisit the topic of writing boxes to the .arc file. My idea would be adding an option to the key file, perhaps “new-archive” – it would then write a new .arc format with box information (just one extra line) which TINKER would still understand, but external codes such as VMD will no longer understand it. We can use a new file extension, perhaps “arx” or something similar. If both “archive” and “new-archive” are specified, then it will write both formats, though the storage will be doubled.

This way we could introduce the new archive format without breaking anything. Let me know what you think.

Hello,
When compiling Tinker8.7.2 in debug mode using gfortran version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) and OPTFLAGS := -Og -g -ffpe-trap=invalid,zero,overflow -Wall -fcheck=all -fbacktrace, running the aspirin case available in the examples directory fails with:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x7ff094a5fcd1 in ???
#1 0x7ff094a5eea5 in ???
#2 0x7ff09474520f in ???
#3 0x55e9716deca3 in kvdw_
at /home/ferre/tinker/8.7.2/source_orig/kvdw.f:352
#4 0x55e971338d19 in mechanic_
at /home/ferre/tinker/8.7.2/source_orig/mechanic.f:94
#5 0x55e9711a42b0 in analyze
at /home/ferre/tinker/8.7.2/source_orig/analyze.f:54
#6 0x55e9711a54c4 in main
at /home/ferre/tinker/8.7.2/source_orig/analyze.f:23

Using gdb shows that the error is precisely:
352 gik = (rad(i)-rad(k))/(rad(i)+rad(k))
which I confirms by printing both i and k values of the rad array. Both are 0.0d0, hence the forbidden division par 0.

Note that this error does not show up when normal optimization is achieved at compilation time.

Best regards,
Nicolas Ferré,
Aix-Marseille Université, France

The FreeBSD port fails to build:

gfortran -Ofast -msse -msse2 -mfpmath=sse -fopenmp -static-libgcc -o gda.x  -L/wrkdirs/usr/ports/science/tinker/work/tinker/fftw/lib gda.o libtinker.a  -lfftw3_threads -lfftw3; strip gda.x
/usr/local/bin/ld: libtinker.a(induce.o): in function `ulspred_': 
induce.f:(.text+0x19d88): undefined reference to `lusolve_'
/usr/local/bin/ld: induce.f:(.text+0x19da8): undefined reference to `lusolve_'
collect2: error: ld returned 1 exit status

Hi, I've just noticed a probable typo in echarge.f : line 132, cscale(in) should be set to c1scale, not c2scale.

I am not sure if this is a bug or if I am attempting to use TINKER incorrectly, but I would like to use the "taper" and "cutoff" keywords with AMOEBA. The taper keywords do not seem to have an effect on multipolar force fields, although the manual seems to suggest that taper is implemented for multipoles. I tried the calculations with both the static binaries on the TINKER website and source code compiled from GitHub.

As a test system I calculated the energy of NaCl at different bond distances. Using the AMBER99 force field, cutoff/taper smoothly adjusted the energy. With AMOEBA09, all settings gave the same result as using AMBER99 with the truncate keyword. Some of the input and output (energies at distances between 0 an 20 angstroms) are listed below.

Taper keyword file:

parameters NaCl09.prm
#parameters NaCl99.prm
cutoff 20.0
mpole-cutoff 20.0
taper 0.5
mpole-taper 0.5
#truncate
vdwterm none

AMBER99 taper:

1 A -13.439203229605 eV
4 A -2.6398434916303 eV
8 A -0.8399502020400 eV
12 A -0.2447941578734 eV
16 A -0.0333936331889 eV
20 A 0.00000000000000 eV

AMBER99 truncate:

1 A -14.399146317589 eV
4 A -3.5997865791806 eV
8 A -1.7998932895903 eV
12 A -1.1999288598714 eV
16 A -0.8999466447951 eV
20 A -0.7199573156626 eV

AMOEBA09 taper:

1 A -14.399644861664 eV
4 A -3.5999112154161 eV
8 A -1.7999556077080 eV
12 A -1.1999704052832 eV
16 A -0.8999778040708 eV
20 A -0.7199822430832 eV

Thanks,
-kratz

downloaded tinker package from github today, openmm is the latest version 7.0. Could anyone please help?

make all
gfortran -c -O3 -ffast-math -fopenmp angbnd.f -o angbnd.o
gfortran -c -O3 -ffast-math -fopenmp angpot.f -o angpot.o
gfortran -c -O3 -ffast-math -fopenmp angtor.f -o angtor.o
gfortran -c -O3 -ffast-math -fopenmp sizes.f -o sizes.o
gfortran -c -O3 -ffast-math -fopenmp atomid.f -o atomid.o
gfortran -c -O3 -ffast-math -fopenmp atoms.f -o atoms.o
gfortran -c -O3 -ffast-math -fopenmp bath.f -o bath.o
gfortran -c -O3 -ffast-math -fopenmp bitor.f -o bitor.o
gfortran -c -O3 -ffast-math -fopenmp bndpot.f -o bndpot.o
gfortran -c -O3 -ffast-math -fopenmp bndstr.f -o bndstr.o
gfortran -c -O3 -ffast-math -fopenmp bound.f -o bound.o
gfortran -c -O3 -ffast-math -fopenmp boxes.f -o boxes.o
gfortran -c -O3 -ffast-math -fopenmp chgpot.f -o chgpot.o
gfortran -c -O3 -ffast-math -fopenmp couple.f -o couple.o
gfortran -c -O3 -ffast-math -fopenmp deriv.f -o deriv.o
gfortran -c -O3 -ffast-math -fopenmp energi.f -o energi.o
gfortran -c -O3 -ffast-math -fopenmp ewald.f -o ewald.o
gfortran -c -O3 -ffast-math -fopenmp freeze.f -o freeze.o
gfortran -c -O3 -ffast-math -fopenmp group.f -o group.o
gfortran -c -O3 -ffast-math -fopenmp inform.f -o inform.o
gfortran -c -O3 -ffast-math -fopenmp iounit.f -o iounit.o
gfortran -c -O3 -ffast-math -fopenmp keys.f -o keys.o
gfortran -c -O3 -ffast-math -fopenmp ktrtor.f -o ktrtor.o
gfortran -c -O3 -ffast-math -fopenmp kvdws.f -o kvdws.o
gfortran -c -O3 -ffast-math -fopenmp limits.f -o limits.o
gfortran -c -O3 -ffast-math -fopenmp mdstuf.f -o mdstuf.o
gfortran -c -O3 -ffast-math -fopenmp moldyn.f -o moldyn.o
gfortran -c -O3 -ffast-math -fopenmp mplpot.f -o mplpot.o
gfortran -c -O3 -ffast-math -fopenmp mpole.f -o mpole.o
gfortran -c -O3 -ffast-math -fopenmp mutant.f -o mutant.o
gfortran -c -O3 -ffast-math -fopenmp nonpol.f -o nonpol.o
gfortran -c -O3 -ffast-math -fopenmp opbend.f -o opbend.o
gfortran -c -O3 -ffast-math -fopenmp openmm.f -o openmm.o
gfortran -c -O3 -ffast-math -fopenmp openmp.f -o openmp.o
gfortran -c -O3 -ffast-math -fopenmp pitors.f -o pitors.o
gfortran -c -O3 -ffast-math -fopenmp pme.f -o pme.o
gfortran -c -O3 -ffast-math -fopenmp polar.f -o polar.o
gfortran -c -O3 -ffast-math -fopenmp polgrp.f -o polgrp.o
gfortran -c -O3 -ffast-math -fopenmp polpot.f -o polpot.o
gfortran -c -O3 -ffast-math -fopenmp potent.f -o potent.o
gfortran -c -O3 -ffast-math -fopenmp restrn.f -o restrn.o
gfortran -c -O3 -ffast-math -fopenmp solute.f -o solute.o
gfortran -c -O3 -ffast-math -fopenmp stodyn.f -o stodyn.o
gfortran -c -O3 -ffast-math -fopenmp strbnd.f -o strbnd.o
gfortran -c -O3 -ffast-math -fopenmp strtor.f -o strtor.o
gfortran -c -O3 -ffast-math -fopenmp torpot.f -o torpot.o
gfortran -c -O3 -ffast-math -fopenmp tors.f -o tors.o
gfortran -c -O3 -ffast-math -fopenmp tortor.f -o tortor.o
gfortran -c -O3 -ffast-math -fopenmp units.f -o units.o
gfortran -c -O3 -ffast-math -fopenmp urey.f -o urey.o
gfortran -c -O3 -ffast-math -fopenmp urypot.f -o urypot.o
gfortran -c -O3 -ffast-math -fopenmp usage.f -o usage.o
gfortran -c -O3 -ffast-math -fopenmp vdw.f -o vdw.o
gfortran -c -O3 -ffast-math -fopenmp vdwpot.f -o vdwpot.o
gfortran -c -O3 -ffast-math -fopenmp dynamic_omm.f -o dynamic_omm.o
g++ -c -O3 -ffast-math -fopenmp -I/home/magno/protein/openmm/include ommstuff.cpp
ommstuff.cpp:85:3: warning: anonymous type with no linkage used to declare variable ‘ angbnd__’ with linkage [enabled by default]
} angbnd__;
^
ommstuff.cpp:107:3: warning: anonymous type with no linkage used to declare variable ‘ angpot__’ with linkage [enabled by default]
} angpot__;
^
ommstuff.cpp:123:3: warning: anonymous type with no linkage used to declare variable ‘ atomid__’ with linkage [enabled by default]
} atomid__;
^
ommstuff.cpp:131:3: warning: anonymous type with no linkage used to declare variable ‘ atoms__’ with linkage [enabled by default]
} atoms__;
^
ommstuff.cpp:156:3: warning: anonymous type with no linkage used to declare variable ‘ bath__’ with linkage [enabled by default]
} bath__;
^
ommstuff.cpp:161:3: warning: anonymous type with no linkage used to declare variable ‘ bitor__’ with linkage [enabled by default]
} bitor__;
^
ommstuff.cpp:168:3: warning: anonymous type with no linkage used to declare variable ‘ bndpot__’ with linkage [enabled by default]
} bndpot__;
^
ommstuff.cpp:175:3: warning: anonymous type with no linkage used to declare variable ‘ bndstr__’ with linkage [enabled by default]
} bndstr__;
^
ommstuff.cpp:183:3: warning: anonymous type with no linkage used to declare variable ‘ bound__’ with linkage [enabled by default]
} bound__;
^
ommstuff.cpp:210:3: warning: anonymous type with no linkage used to declare variable ‘ boxes__’ with linkage [enabled by default]
} boxes__;
^
ommstuff.cpp:222:3: warning: anonymous type with no linkage used to declare variable ‘ chgpot__’ with linkage [enabled by default]
} chgpot__;
^
ommstuff.cpp:233:3: warning: anonymous type with no linkage used to declare variable ‘ couple__’ with linkage [enabled by default]
} couple__;
^
ommstuff.cpp:262:3: warning: anonymous type with no linkage used to declare variable ‘ deriv__’ with linkage [enabled by default]
} deriv__;
^
ommstuff.cpp:291:3: warning: anonymous type with no linkage used to declare variable ‘ energi__’ with linkage [enabled by default]
} energi__;
^
ommstuff.cpp:296:3: warning: anonymous type with no linkage used to declare variable ‘ ewald__’ with linkage [enabled by default]
} ewald__;
^
ommstuff.cpp:308:3: warning: anonymous type with no linkage used to declare variable ‘ freeze__’ with linkage [enabled by default]
} freeze__;
^
ommstuff.cpp:320:3: warning: anonymous type with no linkage used to declare variable ‘ group__’ with linkage [enabled by default]
} group__;
^
ommstuff.cpp:332:3: warning: anonymous type with no linkage used to declare variable ‘ inform__’ with linkage [enabled by default]
} inform__;
^
ommstuff.cpp:347:3: warning: anonymous type with no linkage used to declare variable ‘ ktrtor__’ with linkage [enabled by default]
} ktrtor__;
^
ommstuff.cpp:354:3: warning: anonymous type with no linkage used to declare variable ‘ kvdwpr__’ with linkage [enabled by default]
} kvdwpr__;
^
ommstuff.cpp:362:3: warning: anonymous type with no linkage used to declare variable ‘ kvdws__’ with linkage [enabled by default]
} kvdws__;
^
ommstuff.cpp:382:3: warning: anonymous type with no linkage used to declare variable ‘ limits__’ with linkage [enabled by default]
} limits__;
^
ommstuff.cpp:393:3: warning: anonymous type with no linkage used to declare variable ‘ mdstuf__’ with linkage [enabled by default]
} mdstuf__;
^
ommstuff.cpp:399:3: warning: anonymous type with no linkage used to declare variable ‘ moldyn__’ with linkage [enabled by default]
} moldyn__;
^
ommstuff.cpp:406:3: warning: anonymous type with no linkage used to declare variable ‘ mplpot__’ with linkage [enabled by default]
} mplpot__;
^
ommstuff.cpp:420:3: warning: anonymous type with no linkage used to declare variable ‘ mpole__’ with linkage [enabled by default]
} mpole__;
^
ommstuff.cpp:435:3: warning: anonymous type with no linkage used to declare variable ‘ mutant__’ with linkage [enabled by default]
} mutant__;
^
ommstuff.cpp:453:3: warning: anonymous type with no linkage used to declare variable ‘ nonpol__’ with linkage [enabled by default]
} nonpol__;
^
ommstuff.cpp:459:3: warning: anonymous type with no linkage used to declare variable ‘ opbend__’ with linkage [enabled by default]
} opbend__;
^
ommstuff.cpp:465:3: warning: anonymous type with no linkage used to declare variable ‘ pitors__’ with linkage [enabled by default]
} pitors__;
^
ommstuff.cpp:482:3: warning: anonymous type with no linkage used to declare variable ‘ pme__’ with linkage [enabled by default]
} pme__;
^
ommstuff.cpp:506:3: warning: anonymous type with no linkage used to declare variable ‘ polar__’ with linkage [enabled by default]
} polar__;
^
ommstuff.cpp:521:3: warning: anonymous type with no linkage used to declare variable ‘ polgrp__’ with linkage [enabled by default]
} polgrp__;
^
ommstuff.cpp:541:3: warning: anonymous type with no linkage used to declare variable ‘ polpot__’ with linkage [enabled by default]
} polpot__;
^
ommstuff.cpp:571:3: warning: anonymous type with no linkage used to declare variable ‘ potent__’ with linkage [enabled by default]
} potent__;
^
ommstuff.cpp:601:3: warning: anonymous type with no linkage used to declare variable ‘ restrn__’ with linkage [enabled by default]
} restrn__;
^
ommstuff.cpp:612:3: warning: anonymous type with no linkage used to declare variable ‘ sizes__’ with linkage [enabled by default]
} sizes__;
^
ommstuff.cpp:638:3: warning: anonymous type with no linkage used to declare variable ‘ solute__’ with linkage [enabled by default]
} solute__;
^
ommstuff.cpp:644:3: warning: anonymous type with no linkage used to declare variable ‘ stodyn__’ with linkage [enabled by default]
} stodyn__;
^
ommstuff.cpp:650:3: warning: anonymous type with no linkage used to declare variable ‘ strbnd__’ with linkage [enabled by default]
} strbnd__;
^
ommstuff.cpp:666:3: warning: anonymous type with no linkage used to declare variable ‘ torpot__’ with linkage [enabled by default]
} torpot__;
^
ommstuff.cpp:677:3: warning: anonymous type with no linkage used to declare variable ‘ tors__’ with linkage [enabled by default]
} tors__;
^
ommstuff.cpp:682:3: warning: anonymous type with no linkage used to declare variable ‘ tortor__’ with linkage [enabled by default]
} tortor__;
^
ommstuff.cpp:700:3: warning: anonymous type with no linkage used to declare variable ‘ units__’ with linkage [enabled by default]
} units__;
^
ommstuff.cpp:707:3: warning: anonymous type with no linkage used to declare variable ‘ urey__’ with linkage [enabled by default]
} urey__;
^
ommstuff.cpp:713:3: warning: anonymous type with no linkage used to declare variable ‘ urypot__’ with linkage [enabled by default]
} urypot__;
^
ommstuff.cpp:719:3: warning: anonymous type with no linkage used to declare variable ‘ usage__’ with linkage [enabled by default]
} usage__;
^
ommstuff.cpp:733:3: warning: anonymous type with no linkage used to declare variable ‘ vdw__’ with linkage [enabled by default]
} vdw__;
^
ommstuff.cpp:756:3: warning: anonymous type with no linkage used to declare variable ‘ vdwpot__’ with linkage [enabled by default]
} vdwpot__;
^
ommstuff.cpp: In function ‘void setupAmoebaStretchTorsionForce(OpenMM_System_, FILE_)’:
ommstuff.cpp:2192:4: error: ‘OpenMM_AmoebaStretchTorsionForce’ was not declared in this scope
OpenMM_AmoebaStretchTorsionForce* amoebaStretchTorsionForce;
^
ommstuff.cpp:2192:38: error: ‘amoebaStretchTorsionForce’ was not declared in this scope
OpenMM_AmoebaStretchTorsionForce* amoebaStretchTorsionForce;
^
ommstuff.cpp:2193:73: error: ‘OpenMM_AmoebaStretchTorsionForce_create’ was not declared in this scope
amoebaStretchTorsionForce = OpenMM_AmoebaStretchTorsionForce_create ();
^
ommstuff.cpp:2246:75: error: ‘OpenMM_AmoebaStretchTorsionForce_addStretchTorsion’ was not declared in this scope
torpot__.storunit * ((strtor__.kst + 9_ii + 8)));
^
ommstuff.cpp: In function ‘void setupAmoebaAngleTorsionForce(OpenMM_System, FILE_)’:
ommstuff.cpp:2257:4: error: ‘OpenMM_AmoebaAngleTorsionForce’ was not declared in this scope
OpenMM_AmoebaAngleTorsionForce* amoebaAngleTorsionForce;
^
ommstuff.cpp:2257:36: error: ‘amoebaAngleTorsionForce’ was not declared in this scope
OpenMM_AmoebaAngleTorsionForce* amoebaAngleTorsionForce;
^
ommstuff.cpp:2258:69: error: ‘OpenMM_AmoebaAngleTorsionForce_create’ was not declared in this scope
amoebaAngleTorsionForce = OpenMM_AmoebaAngleTorsionForce_create ();
^
ommstuff.cpp:2297:60: error: ‘OpenMM_AmoebaAngleTorsionForce_addAngleTorsion’ was not declared in this scope
* ((angtor__.kant + 6 * ii + 5)));
^
ommstuff.cpp: In function ‘void setupAmoebaVdwForce(OpenMM_System, FILE_)’:
ommstuff.cpp:2503:63: error: too many arguments to function ‘int OpenMM_AmoebaVdwForce_addParticle(OpenMM_AmoebaVdwForce_, int, double, double, double)’
vdw__.kred[ii], mutant__.vlambda);
^
In file included from ommstuff.cpp:57:0:
/home/magno/protein/openmm/include/AmoebaOpenMMCWrapper.h:59:33: note: declared here
extern OPENMM_EXPORT_AMOEBA int OpenMM_AmoebaVdwForce_addParticle(OpenMM_AmoebaVdwForce* target, int parentIndex, double sigma, double epsilon, double reductionFactor);
^
ommstuff.cpp:2509:50: error: too many arguments to function ‘int OpenMM_AmoebaVdwForce_addParticle(OpenMM_AmoebaVdwForce_, int, double, double, double)’
vdw__.kred[ii], 1.0);
^
In file included from ommstuff.cpp:57:0:
/home/magno/protein/openmm/include/AmoebaOpenMMCWrapper.h:59:33: note: declared here
extern OPENMM_EXPORT_AMOEBA int OpenMM_AmoebaVdwForce_addParticle(OpenMM_AmoebaVdwForce_ target, int parentIndex, double sigma, double epsilon, double reductionFactor);
^
ommstuff.cpp:2557:69: error: ‘OpenMM_AmoebaVdwForce_computeCombinedSigmaEpsilon’ was not declared in this scope
OpenMM_AmoebaVdwForce_computeCombinedSigmaEpsilon (amoebaVdwForce);
^
ommstuff.cpp:2590:57: error: ‘OpenMM_AmoebaVdwForce_addVdwprByOldTypes’ was not declared in this scope
combinedEpsilon_OpenMM_KJPerKcal);
^
ommstuff.cpp: In function ‘void openmm_init_(void__, double_)’:
ommstuff.cpp:3388:70: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘void_’ -Wformat= fprintf (log, "\n OpenMMDataHandle: %x\n", (void_)(omm));
^
ommstuff.cpp:3389:76: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘void_’ -Wformat= fprintf (log, "\n Integrator: %x\n", (void_)(omm->integrator));
^
ommstuff.cpp: In function ‘void openmm_validate_(int_)’:
ommstuff.cpp:3934:22: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
char* ixnString = "Interaction Not Currently Supported by OpenMM.\n";
^
ommstuff.cpp: In function ‘int openmm_test_()’:
ommstuff.cpp:4363:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaPotentialsTest";
^
ommstuff.cpp:4394:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaHarmonicBondTest";
^
ommstuff.cpp:4405:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaHarmonicAngleTest";
^
ommstuff.cpp:4413:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaStretchBendTest";
^
ommstuff.cpp:4421:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaUreyBradleyForceTest";
^
ommstuff.cpp:4428:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaOutOfPlaneBendTest";
^
ommstuff.cpp:4435:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaTorsionTest";
^
ommstuff.cpp:4442:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaPiTorsionTest";
^
ommstuff.cpp:4449:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaStretchTorsionTest";
^
ommstuff.cpp:4456:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaAngleTorsionTest";
^
ommstuff.cpp:4463:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaTorsionTorsionTest";
^
ommstuff.cpp:4471:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaVdwTest";
^
ommstuff.cpp:4473:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaVdwNoCutoffTest";
^
ommstuff.cpp:4485:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaRestraintTest";
^
ommstuff.cpp:4507:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaMultipoleDirectTest";
^
ommstuff.cpp:4509:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaMultipoleMutualTest";
^
ommstuff.cpp:4521:16: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaWcaDispersionTest";
^
ommstuff.cpp:4569:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaKirkwoodDirectTest";
^
ommstuff.cpp:4571:19: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
testName = "AmoebaKirkwoodMutualTest";
^
make: *_* [ommstuff.o] Error 1

Dear,

I'm using the Tinker program potential.f to fit initial multipoles to a grid defining the ESP potential.
To do so I downloaded and compiled the last (I think) available version of Tinker. Unfortunately in a test calculation I encountered the following error:

######################################################################

#########################################################################

Tinker --- Software Tools for Molecular Design

Version 8.9.1 February 2021

Copyright (c) Jay William Ponder 1990-2021

All Rights Reserved

#########################################################################
######################################################################

Additional Atom Definition Parameters :

 Type  Class  Symbol  Description               Atomic    Mass   Valence

  401   401     C     ethene                       6     12.011     3
  402   402     H     ethene                       1      1.008     1

Electrostatic Potential Grid Points : 5983

Electrostatic Parameter Restraint Value : 1.0000

Additional Atom Definition Parameters :

 Type  Class  Symbol  Description               Atomic    Mass   Valence

  401   401     C     ethene                       6     12.011     3
  402   402     H     ethene                       1      1.008     1

Additional Atomic Multipole Parameters :

 Atom Type     Coordinate Frame Definition         Multipole Moments

     401      401    402      0   Z-then-X    -0.05342
                                               0.00000  0.00000 -0.07548
                                               0.10870
                                               0.00000 -0.04845
                                               0.00000  0.00000 -0.06026

     402      401    401      0   Z-then-X     0.02671
                                              -0.01212  0.00000 -0.17162
                                               0.01222
                                               0.00000 -0.00292
                                              -0.01278  0.00000 -0.00930

Additional Atomic Dipole Polarizability Parameters :

 Atom Type           Alpha       Thole     Group Atom Types

     401             1.750       0.390         401  402
     402             0.696       0.390         401

Average Electrostatic Potential over Atoms :
(Kcal/mole per unit charge)

Structure Atom Points Potential Target RMS Diff

    1        1        1165        -2.3205        -2.1166         0.3083
    1        2        1157        -2.2966        -2.0937         0.3125
    1        3         919         1.1629         1.1446         0.3222
    1        4         915         1.1640         1.1462         0.3141
    1        5         912         1.1654         1.1396         0.3120
    1        6         915         1.1630         1.1391         0.3131

Electrostatic Potential over all Grid Points :

Average Potential Value for Model : -0.1838
Average Potential Magnitude for Model : 1.8035
Average Potential Value for Target : -0.1180
Average Potential Magnitude for Target : 1.7183

Average Signed Potential Difference : -0.0658
Average Unsigned Potential Difference : 0.2200
Root Mean Square Potential Difference : 0.3135

###At line 1605 of file potential.f
Fortran runtime error: Index '0' of dimension 1 of array 'type' below lower
bound of 1###

Error termination. Backtrace:
#0 0x7f9dff4fdd3a
#1 0x7f9dff4fe849
#2 0x7f9dff4feec6
#3 0x5580763dca48
#4 0x5580763e9d25
#5 0x5580763eaebb
#6 0x7f9dff1790b2
#7 0x5580763d136d
#8 0xffffffffffffffff

So I checked the code, and it seems to me that the following loop, including line 1605, in potential.f might generate the problem:
...
do i = 1, npole
it = type(ii)
equiv(it) = equiv(it) + 1
sum = sum + pole(1,i)
end do
...

I might be written instead as:
...
do i = 1, npole
ii = ipole(i)
it = type(ii)
equiv(it) = equiv(it) + 1
sum = sum + pole(1,i)
end do
...

Best regards,

Daniele Loco

Hello,

I seem to have found a strange case where potential crashes during esp fitting for multipoles and there is no apparent reason why. I was hoping for some insight.

Files have .txt extension since github wont let me upload other extensions.

Thanks for your time,

• Brandon
  1645.key_2.txt
  1645.xyz_2.txt
  1645_fortinker.pot.txt
  1645_pymolvis.xyz.txt
  test.in.txt
  test.out.txt

Hello, can you please check simplex minimizer trudge.f
I think it has a lot of errors since very old releases even in the last version. The obvious ones are related to xx size being a 1D array instead of 2D array and its allocation..

In fact it seems incomplete......lot of non allocated variables , missing assignment of variables like eps

Hello,

Noticed small issue special case with this molecule, basically benzene but replace one of C with N.

The frame on the hydrogen attached to N gives z and the x in the same direction and causes MD to crash.

C5H5NH+.gdmaout.txt
C5H5NH+.key.txt
C5H5NH+-peditin.txt

Hi,

When, by mistake (!), the ACTIVE keyword is used with an atom number larger than the total number of atoms, n, Tinker activates the nth atom, even if this last atom is intended to be inactive. In the attached archive, the second logfile (waterdimer.out2) shows this behavior.
active.zip

Of course, this case is a true user error. However, I suppose it is worth including a test in active.f that would check that ACTIVE atom numbers stay <= n.

Nicolas

Hey Dr. Ponder,

I have a molecule with a triple bond, kinda like a stick off the ring. It seems even without any torsion restraints the minimizer has hard time finding "complete convergence". Seems to get stuck in knowing right direction (maybe due to undefined dihedral plane?). Just wondering if this is like something that is "fixable" internally. I know for QM like Gaussian opt, they have trouble with this in modified redundant coordinates but sometimes can fix with cartesian coordinates instead. Hoping for any suggestions!
3561.key_4.txt
3561.xyz_2.txt

Hi Dr. Ponder,
We seem to have found an issue with current poledit.x file. There is a poor RMSPD shown in KeyOut.txt (at the bottom). The issue was compounded when we averaged the multipoles. Tinker 8.7 seems to provide reasonable results.

AveragedKeyOut.txt
Phosphoricacid.pot.txt
Phosphoricacid_oldpoledit.txt
CorrectOutput.txt
Phosphoricacid.key.txt
Phosphoricacid.key_2.txt
KeyOut.txt
Phosphoricacid.xyz_2.txt

Commands and output are in KeyOut.txt and AveratedKeyOut.txt , the correct output is in CorrectOutput.txt using older tinker version (like 8.7 something).

Thanks for your time!

• Brandon

Looking through the buckingham potential code in ebuck, it seems like the A, B, and C are global parameters, rather than per-atomic parameters. We're trying to translate something from gromacs, the system has three independent parameters A_ij, B_ij, C_ij. Since the sigma and epsilon can be set for these particles, that gives two parameters that one can adjust, so one can sort of set two of them:
i.e., the energy is:

e = epsilon_ij [abuck * exp(-bbuck r/sigma_ij) - cbuck * sigma_ij^12/ r^12

Which maps to:

A_ij = epsilon_ij *abuck
B_ij = bbuck/sigma_ij
C_ij = epsilon_ij * cbuck * sigma_ij^12

So for any given A_ij, B_ij, C_ij, you arbitrarily set A_ij and C_ij OR B_ij and C_ij, using epsilon_ij and sigma_ij but not all three independently. Am I missing something, and is there a way to do this?

I'm willing to do some work to implement this if necessary, if there is not a way to do this already.

Also, I see that it switches to a standard 12-6 potential outside of a certain cutoff. Is this just for speed, since at a certain distance, r^-12 and exp(-r)?

9_8_Index_0-peditin.txt
9_8_Index_0.sdf.txt
9_8_Index_0.gdmaout.txt

Hello, I noticed the hydrogens on the benzene in this molecule were assigned multipole frames of ions. Poltype relies on poledit defaults now instead of making our own in the input peditin.txt file.

Thanks for your time,

• Brandon Walker

There is a bug in potential fitting that I encountered several times where the parameters after fitting have huge errors in ESP.
I believe this is because the indices for multipole parameters are shifted when there are some zero-valued parameters. Although Tinker 8.7 has no problem for this molecule, it could be that the final parameters happen to have a small non-zero value.

Attached are the input and output files.
tinker87.log, tinker87.key_3 are the results from the older version
tinker892.log, tinker892.key_3 are the results from the latest version.

esp.zip

I have currently been using this version of Tinker to run a vibrational analysis on a crystal system of benzene and resorcinol. When I first tested these same crystals with OPLS-AA I found that after using the xtalmin executable with an RMS gradient/atom to 0.01 that the lowest three vibrational modes were between -0.1 to 0.1 cm^-1 for both crystals. This helped to support my conclusion that the crystal structure was properly minimized and the vibrational spectra was accurate.

I have since moved to testing both systems with AMOEBA and have found conflicting results. Once again the systems were xtalmin'd to an RMS gradient/atom to 0.01. With benzene the vibrate executable produced the three lowest wavenumbers between -0.1 and 0.1 cm^-1, which was congruent with OPLS-AA and what we expected. Alternatively, the resorcinol crystal produced the following three lowest wavenumbers: -5.7, -5.2, and 2.2 cm^-1 implying that the crystal system is not properly minimized or the mass-weighted Hessian is not being computed properly.

I have since begun looking in the code for any potential issues that could cause this. Here are the following things I have attempted:

1. Increased and decreased the finite difference step in the epolar2.f and empolar2.f codes, which changed the wavenumbers by ~10^-5.
2. Zero'd out and commented out polarization terms in parameter file and re-minimized the structure, which corrected for the large negative wavenumbers.
3. Zero'd out and commented out multipole terms in parameter file and re-minimized the structure, which corrected for the large negative wavenumbers.
4. In the epolar2.f code I have fixed the reinduce flag to 'false', which has corrected for the large negative wavenumbers and has had minimal effects on the rest of the vibrational spectra. This is a bit counter intuitive because setting it 'true' should make the calculation more accurate and less negative.

I appreciate the large number of changes that have gone into the current version of Tinker, which has allowed me to now implement the vibrate executable with AMOEBA. That being said, I am unsure as to how to circumvent the issues with these large negative wavenumbers. Please let me know how I can help in aiding any issues.

Thank you!

fftw/lib diffuse.o libtinker.a -lfftw3_threads -lfftw3 ; strip diffuse.x
/usr/local/bin/ld: libtinker.a(/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftsetup_':
fft3d.f:(.text+0x370): undefined reference to `dfftw_init_threads_'
/usr/local/bin/ld: fft3d.f:(.text+0x37c): undefined reference to `dfftw_plan_with_nthreads_'
/usr/local/bin/ld: fft3d.f:(.text+0x3a8): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: fft3d.f:(.text+0x3d4): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftclose_':
fft3d.f:(.text+0xe7e): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: fft3d.f:(.text+0xe8a): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftfront_':
fft3d.f:(.text+0x921): undefined reference to `dfftw_execute_dft_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftback_':
fft3d.f:(.text+0xe21): undefined reference to `dfftw_execute_dft_'
collect2: error: ld returned 1 exit status
fft3d.o): in function `fftsetup_':
fft3d.f:(.text+0x370): undefined reference to `dfftw_init_threads_'
/usr/local/bin/ld: fft3d.f:(.text+0x37c): undefined reference to `dfftw_plan_with_nthreads_'
/usr/local/bin/ld: fft3d.f:(.text+0x3a8): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: fft3d.f:(.text+0x3d4): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftclose_':
fft3d.f:(.text+0xe7e): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: fft3d.f:(.text+0xe8a): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftfront_':
fft3d.f:(.text+0x921): undefined reference to `dfftw_execute_dft_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftback_':
fft3d.f:(.text+0xe21): undefined reference to `dfftw_execute_dft_'
collect2: error: ld returned 1 exit status
strip: strip: open archive.x failed: No such file or directory
open correlate.x failed: No such file or directory
gmake[2]: *** [/usr/ports/science/tinker/work/tinker/make/Makefile:792: archive.x] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: *** [/usr/ports/science/tinker/work/tinker/make/Makefile:792: correlate.x] Error 1
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftsetup_':
fft3d.f:(.text+0x370): undefined reference to `dfftw_init_threads_'
/usr/local/bin/ld: fft3d.f:(.text+0x37c): undefined reference to `dfftw_plan_with_nthreads_'
/usr/local/bin/ld: fft3d.f:(.text+0x3a8): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: fft3d.f:(.text+0x3d4): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftclose_':
fft3d.f:(.text+0xe7e): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: fft3d.f:(.text+0xe8a): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftfront_':
fft3d.f:(.text+0x921): undefined reference to `dfftw_execute_dft_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftback_':
fft3d.f:(.text+0xe21): undefined reference to `dfftw_execute_dft_'
collect2: error: ld returned 1 exit status
strip: open diffuse.x failed: No such file or directory
gmake[2]: *** [/usr/ports/science/tinker/work/tinker/make/Makefile:792: diffuse.x] Error 1
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftsetup_':
fft3d.f:(.text+0x370): undefined reference to `dfftw_init_threads_'
/usr/local/bin/ld: fft3d.f:(.text+0x37c): undefined reference to `dfftw_plan_with_nthreads_'
/usr/local/bin/ld: fft3d.f:(.text+0x3a8): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: fft3d.f:(.text+0x3d4): undefined reference to `dfftw_plan_dft_3d_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftclose_':
fft3d.f:(.text+0xe7e): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: fft3d.f:(.text+0xe8a): undefined reference to `dfftw_destroy_plan_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftfront_':
fft3d.f:(.text+0x921): undefined reference to `dfftw_execute_dft_'
/usr/local/bin/ld: libtinker.a(fft3d.o): in function `fftback_':
fft3d.f:(.text+0xe21): undefined reference to `dfftw_execute_dft_'

Found this problem while trying to update the FreeBSD port.
FreeBSD 12
8.6.1 didn't have this problem.
It seems that -lfftw3 is missing.

FFTW is assumed in Makefile to come in tinker-release directory but there is no FFTW (where as previous versions come with it)

In make/0README, the instructions say to run ./buildmake.py ../source, but when you attempt to call this, it throws an IsADirectoryError. The full error message is listed below:

Traceback (most recent call last):
  File "./buildmake.py", line 364, in <module>
    categorize_fortran_files(sys.argv[1:])
  File "./buildmake.py", line 271, in categorize_fortran_files
    stem, filetype, use_list = determine_module_subroutine_program(filename)
  File "./buildmake.py", line 227, in determine_module_subroutine_program
    content = [line.rstrip().lower() for line in open(fortran_filename)]
IsADirectoryError: [Errno 21] Is a directory: '../source'

If I am understanding this script properly, it should be run with

./buildmake.py ../source/*.f > Makefile

Hi,
I have downloaded the latest version of TINKER ( Tinker Complete Distribution (ZIP, 44.5 Mb))
Following instructions of Christoph J. given in the configure folder, I did these steps

copy configure.ac and Makefile.am to the source folder
cd ../source
autoreconf -i -v
./configure
5 make
The steps seem okay till ./configure

However when I type make, I get the following error. please help

[source]$ make
/bin/sh ./libtool --tag=F77 --mode=compile gfortran -g -O2 -c -o action.lo action.f
libtool: compile: gfortran -g -O2 -c action.f -fPIC -o .libs/action.o
libtool: compile: gfortran -g -O2 -c action.f -o action.o >/dev/null 2>&1
/bin/sh ./libtool --tag=F77 --mode=compile gfortran -g -O2 -c -o active.lo active.f
libtool: compile: gfortran -g -O2 -c active.f -fPIC -o .libs/active.o
active.f:20.9:

use atoms
1
Fatal Error: Can't open module file 'atoms.mod' for reading at (1): No such file or directory
make: *** [active.lo] Error 1

I have a PDB file I need to convert to XYZ so I can use it with Tinker. (I'm working on amoebabio18 support in OpenMM, so I need to be able to compute forces and energies with both programs to compare.) When I run pdbxyz on it, I find that all the heavy atoms get translated correctly, but all the hydrogens end up with entirely new positions. Is there some way I can get it to translate the file accurately?

Hi there,

I'm posting here because the Tinker-OpenMM repo doesn't appear to have an issue tracker.

I just built dynamic_omm using the latest TINKER release (8.4.4 downloaded from Jay's website) and the latest OpenMM fork from https://github.com/TinkerTools/Tinker-OpenMM . After I provide the .key file to dynamic_omm, it hangs indefinitely as if waiting for me to type something in (I have waited minutes). I can quit the program with Ctrl-C but it doesn't show me anything useful.

leeping@libra:~/src/Tinker/example$ ../bin/dynamic_omm watersmall.xyz

     ######################################################################
   ##########################################################################
  ###                                                                      ###
 ###            TINKER  ---  Software Tools for Molecular Design            ###
 ##                                                                          ##
 ##                        Version 8.4  February 2018                        ##
 ##                                                                          ##
 ##               Copyright (c)  Jay William Ponder  1990-2018               ##
 ###                           All Rights Reserved                          ###
  ###                                                                      ###
   ##########################################################################
     ######################################################################

forrtl: error (69): process interrupted (SIGINT)
Image              PC                Routine            Line        Source             
dynamic_omm        00000000007F7271  Unknown               Unknown  Unknown
(and ~50 more of these lines)

I built dynamic_omm twice on two different machines and environments, both running Ubuntu 16.04. One environment uses Intel compilers (15.0.3 20150407) and CUDA 8.0; the other environment uses gfortran (GCC 5.4.0) and CUDA 9.0. On both machines I am getting the exact same error.

I've gotten previous versions of Tinker and OpenMM to work together, so I'm not sure what the most recent issue might be. Maybe you've experienced something similar? Please let me know.

I can provide any other useful information such as environment variables and compiler arguments if you need them.

Thanks,

• Lee-Ping

I am getting an error with the latest version when the key file contains multipoles (or many spaces followed by a number). This happens even when running programs like bar.x that doesn't require a key file. This seems to be related to the latest commit.

At line 107 of file getkey.f
Fortran runtime error: Substring out of bounds: upper bound (21) of 'keyword' exceeds string length (20)

Hello,

I installed Tinker 8.7.2 yesterday and am attempting to follow these directions for parameterizing a new molecule with the AMOEBA force field. Unfortunately, when I try and call poledit I get a segmentation fault (tried about 5 times). I think that the gdmaout file is being read correctly, since information populates. I'm using the amoeba09.prm file that came with the distribution when prompted by poledit.

I was trying this on H2 for simplicity.

Local Frame Intergroup Induced Dipole Moments (Debye) :

    Atom              X           Y           Z         Total

       1           0.0000      0.0000      0.1312      0.1312
       2           0.0000      0.0000     -0.1312      0.1312

 Condense Symmetric Atoms to Equivalent Types [Y] :  Y

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x5605BD
#1  0x54C270
#2  0x2B3B4334D27F
#3  0x408B69
#4  0x41704B
#5  0x402A0C
#6  0x2B3B433393D4
#7  0x404CAC
Segmentation fault (core dumped)
$ which gfortran
/n/sw/eb/apps/centos7/GCCcore/8.3.0/bin/gfortran
$ which gcc
/n/sw/eb/apps/centos7/GCCcore/8.3.0/bin/gcc

My .gdmaout file is attached.

Thanks!

mp2.gdmaout.txt

I am getting Segmentation Fault (core Dumped) while trying to run the dynamic_omm . The input files are working fine with the CPU version of dynamic. I have followed Lee-Ping Wang's notes while compiling. I am using CUDA-10.2 on RTX-2070 (Ubuntu 18.04). I also tried to run dynamic with just a water box (https://biomol.bme.utexas.edu/~pren/downloads/waterbox) and still i am getting the same error.

ERROR OBTAINED FOR THE SIMULATION of WATER BOX:
anees@basin:~/work/tinker_test/amoebanuc17_solv_noions$ /home/anees/src/Tinker/build_openmm/dynamic_omm.x water36.xyz

 ######################################################################

##########################################################################

Tinker --- Software Tools for Molecular Design

Version 8.7 June 2019

Copyright (c) Jay William Ponder 1990-2019

All Rights Reserved

##########################################################################
######################################################################

Enter the Number of Dynamics Steps to be Taken : 1000

Enter the Time Step Length in Femtoseconds [1.0] : 2.0

Enter Time between saves in Picoseconds [0.1] : 0.1

Available Statistical Mechanical Ensembles :

(1) Microcanonical (NVE)
(2) Canonical (NVT)
(3) Isoenthalpic-Isobaric (NPH)
(4) Isothermal-Isobaric (NPT)

Enter the Number of the Desired Choice [1] : 2

Enter the Desired Temperature in Degrees K [298] : 300

Return Data from the GPU at Every Time Step [N] : 1000

Number of CUDA Devices Detected : 1

Device Number : 0
Device Name GeForce RTX 2070
Clockspeed (GHz) 1.620
Total Memory (GB) 8.00
Free Memory (GB) 6.77
GPU load 1.00%

Platform CUDA : Setting Precision to MIXED via CUDA-PRECISION

Molecular Dynamics Trajectory via r-RESPA MTS Algorithm
terminate called after throwing an instance of 'OpenMM::OpenMMException'
what(): Error loading CUDA module: CUDA error (218)

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0 0x7f6e51c5231a
#1 0x7f6e51c51503
#2 0x7f6e51098f1f
#3 0x7f6e51098e97
#4 0x7f6e5109a800
#5 0x7f6e53b2e956
#6 0x7f6e53b34ab5
#7 0x7f6e53b34af0
#8 0x7f6e53b34d78
#9 0x7f6e184992e2
#10 0x7f6e1855765b
#11 0x7f6e18557f77
#12 0x7f6e184e9cfd
#13 0x7f6e54165483
#14 0x7f6e18502094
#15 0x7f6e541a519f
#16 0x55d2aefc248b
#17 0x55d2aefc135e
#18 0x7f6e5107bb96
#19 0x55d2aefc13e9
#20 0xffffffffffffffff
Aborted (core dumped)

ERROR OBTAINED FOR THE SIMULATION I WAS TRYING:
anees@basin:~/work/tinker_test/amoebanuc17_solv_noions$ /home/anees/src/Tinker/build_openmm/dynamic_omm.x scl_Na_solv_output.xyz

 ######################################################################

##########################################################################

Tinker --- Software Tools for Molecular Design

Version 8.7 June 2019

Copyright (c) Jay William Ponder 1990-2019

All Rights Reserved

##########################################################################
######################################################################

Enter Potential Parameter File Name : amoebanuc17.prm

Enter the Number of Dynamics Steps to be Taken : 100

Enter the Time Step Length in Femtoseconds [1.0] : 2.0

Enter Time between saves in Picoseconds [0.1] : 0.01

Available Simulation Control Modes :

(1) Constant Total Energy Value (E)
(2) Constant Temperature via Thermostat (T)

Enter the Number of the Desired Choice [1] : 2

Enter the Desired Temperature in Degrees K [298] : 298

Return Data from the GPU at Every Time Step [N] : 10

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7f322a5b531a
#1 0x7f322a5b4503
#2 0x7f32299fbf1f
#3 0x7f322cae9082
#4 0x7f322cc9190b
#5 0x56072cc3e46b
#6 0x56072cc45a5d
#7 0x56072cc3bf8d
#8 0x56072cc3b35e
#9 0x7f32299deb96
#10 0x56072cc3b3e9
#11 0xffffffffffffffff
Segmentation fault (core dumped)

I have tried the suggestion that came up here: #52.
Still its not working.

-Anees

In order for ForceBalance to do force matching calculations more efficiently, it would be ideal if the testgrad program could loop over a trajectory and calculate the forces on each frame.

Currently, testgrad needs to be called separately for each frame, which slows things down because the program gets loaded into memory, variables need to be initialized and so on.

Referring to #1, if we come up with a good way to include periodic boxes in the trajectory, it would be good for testgrad to take advantage of this as well.

30e_n1_tr2.key_2.txt
30e_n1_tr2.xyz_2.txt
30e_n1_tr2.pot.txt

Hello,

I noticed this issue with potential.x, I am guessing its complaining because poltype is using large atom type number values?

• Brandon
  potential.x 6 30e_n1_tr2.xyz_2 -k 30e_n1_tr2.key_2 30e_n1_tr2.pot N 0.1
  At line 1595 of file potential.f
  Fortran runtime error: Index '426' of dimension 1 of array 'equiv' above upper bound of 80

Hi,
I have installed Tinker-openMM using CUDA 9.2, intel compilers,and recent Tinker 8.7+ Tinker-OpenMM (from github). The installation completed without errors and it is based on Lee-Ping's instructions.

But, whenever I try jobs I receive following error:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
*** longjmp causes uninitialized stack frame ***: /home/m/mandar/pfs/softwares/new_tinker_openmm_gpu/gcc/tinker/bin/dynamic_omm terminated

Is there any variable I should set to avoid this error? Thanks in advance.

Regards,
Mandar Kulkarni

This is mainly a question for @dmargul (apologies for doing it here -- I don't know your email address).

I'm trying to get a version of the SINR integrator implemented in OpenMM (for use with both fixed-charge and AMOEBA force fields). What I expected to see in the code based on what I remember from the talk at Telluride and conversations with various people was to see the short-range forces comprised of the basic bonded terms in addition to short-range VDW and electrostatic forces, and then the long-range stuff had the long-range forces and the reciprocal sum of the multipole (or charge) interactions. Unless I'm reading the code incorrectly, though, what appears to be happening is that all vdW and electrostatic interactions are being turned off even the SR stuff (which is turned off with the "slow-evolving" forces).

Can you clue me into the basic components of the force at the inner (and outer) timesteps in the SINR integrator here?

Thanks!

I believe this is an issue with handling the multipoles, but I am not sure. If you add "multipoleterm" after the "repulsionterm only" line, the energy and forces are correct. Looking into it.

TINKER built using linux/intel/compile.make & co

ifabp test fails as follows:

./ifabp.run 

     ######################################################################
   ##########################################################################
  ###                                                                      ###
 ###            TINKER  ---  Software Tools for Molecular Design            ###
 ##                                                                          ##
 ##                        Version 7.1  February 2015                        ##
 ##                                                                          ##
 ##               Copyright (c)  Jay William Ponder  1990-2015               ##
 ###                           All Rights Reserved                          ###
  ###                                                                      ###
   ##########################################################################
     ######################################################################


 Enter Cartesian Coordinate File Name :  
 Number of Distance Geometry Structures Desired [1] :  
 Impose Chirality Constraints on Tetrahedral Atoms [Y] :  
 Use "Floating" Chirality for -XH2- and -XH3 Groups [N] :  
 Impose Planarity and/or Chirality of Trigonal Atoms [Y] :  
 Impose Torsional Planarity on Adjacent Trigonal Atoms [Y] :  
 Do You Wish to Examine or Alter the Bounds Matrix [N] :  
 Select the Enantiomer Closest to the Input Structure [N] :  
 Refinement via Minimization or Annealing [M or A, <CR>=A] :  ./ifabp.run: line 1: 16803 Bus error               ../bin/distgeom < ifabp.dat
rm: cannot remove `ifabp.0*': No such file or directory

Same issue when I run the test manually, providing the input from ifabp.dat:

$ ../bin/distgeom

     ######################################################################
   ##########################################################################
  ###                                                                      ###
 ###            TINKER  ---  Software Tools for Molecular Design            ###
 ##                                                                          ##
 ##                        Version 7.1  February 2015                        ##
 ##                                                                          ##
 ##               Copyright (c)  Jay William Ponder  1990-2015               ##
 ###                           All Rights Reserved                          ###
  ###                                                                      ###
   ##########################################################################
     ######################################################################


 Enter Cartesian Coordinate File Name :  ifabp

 Number of Distance Geometry Structures Desired [1] :  2

 Impose Chirality Constraints on Tetrahedral Atoms [Y] :  y

 Use "Floating" Chirality for -XH2- and -XH3 Groups [N] :  n

 Impose Planarity and/or Chirality of Trigonal Atoms [Y] :  y

 Impose Torsional Planarity on Adjacent Trigonal Atoms [Y] :  y

 Do You Wish to Examine or Alter the Bounds Matrix [N] :  n

 Select the Enantiomer Closest to the Input Structure [N] :  y

 Refinement via Minimization or Annealing [M or A, <CR>=A] :  a
Bus error

With a debug build, I can only enter the ifabp input, it never gets to asking the rest:

$ gdb ../bin/distgeom
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /gpfs/scratch/projects/project_gpilot/vsc40023/software/TINKER/7.1.2-intel-2015a/tinker/bin/distgeom...done.
(gdb) run
Starting program: /gpfs/scratch/projects/project_gpilot/vsc40023/software/TINKER/7.1.2-intel-2015a/tinker/bin/distgeom 
[Thread debugging using libthread_db enabled]

     ######################################################################
   ##########################################################################
  ###                                                                      ###
 ###            TINKER  ---  Software Tools for Molecular Design            ###
 ##                                                                          ##
 ##                        Version 7.1  February 2015                        ##
 ##                                                                          ##
 ##               Copyright (c)  Jay William Ponder  1990-2015               ##
 ###                           All Rights Reserved                          ###
  ###                                                                      ###
   ##########################################################################
     ######################################################################


 Enter Cartesian Coordinate File Name :  ifabp
forrtl: severe (408): fort: (3): Subscript #1 of the array REDUCT has value 0 which is less than the lower bound of 1

Image              PC                Routine            Line        Source             
distgeom           00000000006D4580  Unknown               Unknown  Unknown
distgeom           00000000005A1076  Unknown               Unknown  Unknown
distgeom           00000000004036C0  Unknown               Unknown  Unknown
distgeom           000000000040333E  Unknown               Unknown  Unknown
libc.so.6          00002AAAAB18CD5D  Unknown               Unknown  Unknown
distgeom           00000000004031C9  Unknown               Unknown  Unknown

Program exited with code 0230.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.x86_64
(gdb)

excuse me ,i need the rigid body simulation source code ,but i can not locate the target source code.

@leucinw found a "core-dump" in Tinker9 dynamic program. It turned out the problem was an invalid memory access in the udirect2b Fortran routine. It was trigger by keyword OPENMP-THREADS 12, so the temporary workaround is to remove this keyword from the key file, or setting the value to 1.

A fix (pull request #81) has been sent out for review.

Tinker9 depends on a libtinker.a binary file that was compiled without OpenMP, therefore the nthread variable should not have been modified by the keyword OPENMP-THREADS in Tinker9. I speculate that this keyword will cause crashes in serial Tinker8 as well.

With 1 thread, the shapes of ilocal and dlocal arrays in udirect2b would be long and thin. If nthread was set to a bigger number, these arrays would be shorter but thicker. Meanwhile, the serial program would still attempt to access the arrays as if they were longer, it eventually crashed.

After installing Tinker, I type pdbxyz in the test folder and input bdna.pdb, but get the errror:

Enter Protein Data Bank File Name :  bdna.pdb
At line 425 of file readpdb.f
Internal Error: get_unit(): Bad internal unit KIND

Jay,
Do your changes to angle & torsion unit from degree to radian affect the parameter files? The restraint constants are apparently inconsistent now between latest and older tinker.

Hi everyone,

For reference for anyone trying to use dynamic_omm, the current dev version here only seems to work with the dev version of OpenMM being worked on in the Ren group (https://github.com/pren/openmm-amoeba), not the latest OpenMM release. There are extra stretch-torsion potential terms, vdW softcore developments etc.

I think this is fairly well known ( @swails mentioned the issue here openmm/openmm#1439) but thought an issue would be useful to keep track of developments here too, at least for me. I recognise it's a work in progress!

Note that the current 7.1.3 Tinker release still works ok - it's the changes in 7.2 that break compatibility with OpenMM 6.3 or 7.0 for me.
Thanks,
Richard