FRAGONLY EFP2 energy calculation fails in DIPIT

[boatzj]

Make sure these boxes are checked before submitting your issue - thank you!

• [x] Summary of the issue and expected results. RUNTYP=ENERGY COORD=FRAGONLY fails, with the following error message: "DIPIT FAILED TO CONVERGE THE EFP POLARIZABILITY IN 61 ITERATIONS"

  The input is for a dimer of HCN and is a simple EFP2 energy calculation, using production version 18 Aug 2016 (R1).

• [x] Description of the run environment:

  • operating system RedHat Linux

  (examples: Centos 7, Ubuntu 14.04 LTS, Windows 10, OSX Sierra)

  • compiler (if using a pre-compiled binary indicate with pre-compiled binary) Intel 17.0.1.132

  (examples: GNU 6.2, Intel 17 Update 1, PGI 15.10)

  • math library Intel MKL

  (examples: OpenBLAS, ATLAS, Intel MKL, AMCL, OSX VecLib, GAMESS blas.o, PGI BLAS)

  • communication library Intel MPI (examples: sockets, Intel MPI, MVAPICH, MPICH, MS-MPI, OpenMPI)

• [x] An input file (if applicable) to reproduce the issue.
  ! EFP2 HNC ! $contrl units=bohr runtyp=energy coord=fragonly $end $system mwords=1 $end ! $efrag coord=cart FRAGNAME=HCN A01N1 -2.0113255301 -0.9683187190 -1.2411237636 A02C2 -2.5828826407 -0.1179585498 -1.8004916034 A03H3 -3.1057811810 0.6602138439 -2.3117554526 FRAGNAME=HCN A01N1 1.0292375702 1.6060993814 -0.5182177615 A02C2 0.0622240929 1.3201248495 -1.1062533302 A03H3 -0.8222848858 1.0588743509 -1.6445450029 ! ! HCN.efp; copied from GAMESS auxdata/EFP subdirectory.... $HCN ..... $end

• (Optional) A copy of your install.info file.

  !/bin/csh

  compilation configuration for GAMESS

  generated on centennial11

  generated at Tue Dec 12 19:03:56 EST 2017

  setenv GMS_PATH /p/home/boatzj/gamess setenv GMS_BUILD_DIR /p/home/boatzj/gamess

  machine type

  setenv GMS_TARGET linux64

  FORTRAN compiler setup

  setenv GMS_FORTRAN ifort setenv GMS_IFORT_VERNO 14

  mathematical library setup

  setenv GMS_MATHLIB none

  parallel message passing model setup

  setenv GMS_DDI_COMM mpi setenv GMS_MPI_LIB impi setenv GMS_MPI_PATH /p/app/intel/l_psxe_2017.1.043/impi/2017.1.132

  LIBCCHEM CPU/GPU code interface

  setenv GMS_LIBCCHEM false

  Intel Xeon Phi build: true/false

  setenv GMS_PHI false

  Shared memory type: sysv/posix

  setenv GMS_SHMTYPE sysv

  OpenMP support: true/false

  setenv GMS_OPENMP false

  If the input file is more than 50 lines then please send it as an attachment to the following email address (issuetracker@si.msg.chem.iastate.edu) with the subject being the title of the issue.

[colleeneb]

I reproduced the dipit error, also using 18 Aug 2016 (R1).

Sometimes EFP has problems with linear molecules, since it rotates the potential in the $HCN group to match the coordinates in the $efrag group as best as it can. To be more explicit, to generate potentials for the input coordinates in $efrag, GAMESS reads the first three input coordinates in $efrag, computes a local coordinate system for them, finds the corresponding three atoms in the potential in $HCN, computes a local coordinate system for them, and then finds the rotation matrix between the input coordinates and the potential coordinates in $HCN. It then rotates the potential parameters in $HCN using the rotation matrix to best match the input coordinates. So the rotation matrix is solely based on the first three atoms listed.

In hcn.inp, the first three atoms in $efrag are in a line, so GAMESS is possibly having problems finding the local coordinate system. If this is the problem, one solution is to use the "fake" A04D4 coordinate as the third input coordinate in $efrag instead of A03H3.

If I have time tomorrow, I'll try to test this out by modifying $efrag to use A04D4.

Another useful thing in situations like this is to check to see what coordinates GAMESS is using after rotating the input coordinates to match the coordinates in the potential. To do this, I usually compare the rotated coordinates to the original input coordinates in $efrag and also look at the rotated coordinates in macMolPlt. The rotated coordinates are printed at the beginning of the log file.

A snippet from hcn.log showing the rotated coordinates:

THIS IS A -EFP2- TYPE RUN, INCLUDING SEPARATE FORMULAE FOR
   PAULI REPULSION=T  DISPERSION=T  CHARGE TRANSFER=F

 OPTIONS FOR EFP SCREENING:
     ELECTROSTATIC EFP-EFP SCREENING CHOICE IS EXPONENTIAL, FOR CHARGE/CHARGE
     POLARIZATION EFP-EFP SCREENING IS TANG-TOENNIS LIKE
     DISPERSION EFP-EFP SCREENING CHOICE IS USING OVERLAP

     $EWALD OPTIONS
     -----------

     IFEWLD   =        F         TINFOIL        =        T
     BETA    =    0.200         ELECTRIC CONST =     1.00
     EPSILON =     1.00         CUT_OFF        = 0.10E+04
     CUTLIST =  1000.00         LEVEL          =    1
     KMAX    =       10         EWLDPL         =        F

            MULTIPOLE COORDINATES, ELECTRONIC AND NUCLEAR CHARGES

                  X              Y              Z           ELEC.   NUC.
 A01N1     -2.0113255301  -0.9683187190  -1.2411237636   -6.93753    7.0
 A02C2     -3.0914118554   0.6386289916  -2.2981757071   -4.95267    6.0
 A03H3     -4.0795468160   2.1091615870  -3.2643242895   -0.57206    1.0
 A04D4     -5.9300769422   4.8624828304  -5.0751300850    0.00000    0.0
 BO21      -2.5513686928  -0.1648448637  -1.7696497354   -1.17595    0.0
 BO32      -3.5854793357   1.3738952893  -2.7812499983   -0.36179    0.0
 A01N1      1.0292375702   1.6060993814  -0.5182177615   -6.93753    7.0
 A02C2     -0.7981529283   1.0656858767  -1.6294438573   -4.95267    6.0
 A03H3     -2.4696325317   0.5719940201  -2.6466676201   -0.57206    1.0
 A04D4     -5.6004352817  -0.3537027764  -4.5507203580    0.00000    0.0
 BO21       0.1155423209   1.3358926290  -1.0738308094   -1.17595    0.0
 BO32      -1.6338927300   0.8188399484  -2.1380557388   -0.36179    0.0

When I look at this in MacMolPlt, the coordinates don't look right, and these don't seem too similar to the input coordinates in $efrag (we don't expect a perfect match unless the coordinates are the same as those used to generate the EFP, but they should be close).