[x] Summary of the issue and expected results.
The following issues have been observed in GAMESS (2018R3, 2017R2 and 2016R1) and also in various versions of pre-compiled binary on windows (2018R1,2016R1, and 2013R1).
In a SA-MCSCF Hessian calculation (RUNTYP=HESSIAN, CISTEP=ALDET in $MCSCF, METHOD= SEMINUM in $FORCE), when the SA-MCSCF analytic gradient is calculated at initial geometry without any displacement, the CP-MCHF calculation takes many iterations to converge, in comparing with a RUNTYP=GRADIENT job. (about 75 steps for my input file, 100 steps if set IPDIR=50 in $CPMCHF group)
ITER RESPONSE ERROR IMPROVED ORB-ORB CI-ORB
1 1.10620E+01 3 0.0 6.6
DUE TO LARGE RES. NORM, GUESS SET TO 0 VECTOR.
1 2.23607E-01 3 0.0 3.4
2 1.35449E-01 3 0.0 3.4
3 6.04908E-02 3 0.0 3.4
4 3.87200E-02 3 0.0 3.2
5 2.62802E-02 3 0.0 3.4
6 4.27972E-02 3 0.0 3.3
7 2.82949E-02 3 0.0 3.4
8 1.65120E-02 3 0.0 3.4
9 2.42253E-02 3 0.0 3.3
10 1.87669E-02 3 0.0 3.4
...
99 7.55599E-07 2 0.0 3.4
DUE TO SLOW CONVERGENCE, TOLERANCE HAS BEEN RAISED TO 9.00E-07
RESET PDIRX AND RESIDUAL.
100 6.41779E-07 0 0.0 3.4
*** CAUTION! ***
RESPONSES CONVERGED AFTER 100 ITERATIONS,
BUT ONLY TO WITHIN AN INCREASED CONVERGENCE TOLERANCE
...
STATE-SPECIFIC GRADIENT OF STATE 2 (OVERALL STATE 3)
ENERGY= -113.0685263819 SPIN= 0.00 WEIGHT= 0.500000
UNITS ARE HARTREE/BOHR E'X E'Y E'Z
1 C -0.000000021 -0.300558743 -0.000000017
2 O 0.000000030 0.299639316 -0.000000029
3 H 0.000000178 0.000459700 -0.008787508
4 H -0.000000187 0.000459727 0.008787553
When doing the same SA-MCSCF analytic gradient calculation (RUNTYP=GRADIENT),
the CP-MCHF euqation converages smoothly. (about 28 steps for my input file)
ITER RESPONSE ERROR IMPROVED ORB-ORB CI-ORB
1 9.37571E+00 3 0.0 2.8
DUE TO LARGE RES. NORM, GUESS SET TO 0 VECTOR.
1 2.23607E-01 3 0.0 2.4
2 1.20000E-01 3 0.0 2.6
3 2.20756E-02 3 0.0 2.6
4 2.59686E-02 3 0.0 2.6
5 3.62597E-02 3 0.0 2.6
6 1.52174E-03 3 0.0 2.6
7 5.65174E-04 3 0.0 2.6
8 1.90152E-03 3 0.0 2.6
9 2.90008E-04 3 0.0 2.6
10 1.26929E-04 3 0.0 2.6
...
27 4.30635E-08 0 0.0 2.5
RESET PDIRX AND RESIDUAL.
28 5.99194E-08 0 0.0 2.5
THE CPMCHF HAS CONVERGED AFTER 28 ITERATIONS.
...
STATE-SPECIFIC GRADIENT OF STATE 2 (OVERALL STATE 3)
ENERGY= -113.0685263819 SPIN= 0.00 WEIGHT= 0.500000
UNITS ARE HARTREE/BOHR E'X E'Y E'Z
1 C 0.000000000 -0.300558380 0.000000004
2 O -0.000000000 0.299639112 -0.000000025
3 H -0.000000012 0.000459628 -0.008787454
4 H 0.000000012 0.000459640 0.008787475
In addition, when the program (RUNTYP=HESSIAN) is doing an extra CI calculation just before solving the CP-MCHF equation, the iterations are long and the converged CI coefficients are strange and different from the previously converged ones in the same job:
The issues depend on the paremeter CANONC in $MCSCF group. If set CANONC=.F., then similar issues observed in RUNTYP=HESSIAN job also appear in a RUNTYP=GRADIENT job.
But when doing RUNTYP=HESSIAN, however, CANONC=.T. (default) is useless. In the subroutine NEWTON ( around line 3850 in mcscf.src), CANONC is forced to be FALSE when RUNTYP=OPTIMIZE, SADPOINT, or HESSIAN (METHOD=SEMINUM):
C ----- MAKE CANONICAL ORBITALS -----
C OR, IN ANY CASE, PRINT OUT THE NO-S AND MO-S
C
C CANONICALIZATION TAKES SOME TIME, SO WE CAN SKIP IT DURING
C THE COURSE OF A GEOMETRY SEARCH OR NUMERICAL HESSIAN.
C CANONICALIZATION CAN DAMAGE ORBITAL SYMMETRY OF CORES,
C ESPECIALLY IN NON-ABELIAN GROUPS.
C NOTE THAT MR-PT OR MR-CI METHODS ARE BASED ON CANONICALIZATION
C HAVING SEPARATED CORE FROM VALENCE, SO DO NOT SKIP THIS,
C UNLESS THE USER'S INPUT HAS REQUESTED THAT.
C
CANSAV = CANONC
IF(RUNTYP.EQ.OPT .OR. RUNTYP.EQ.SAD .OR. IHESSM.EQ.1)
* CANONC = .FALSE.
I also tried RUNTYP=OPTIMIZE, and indeed the same issues appear. But when I block the above IF statement and recompile MCSCF.src, generate the new executable file, make sure CANONC=.T. in $MCSCF group, then the issues in RUNTYP= HESSIAN or OPTIMIZE jobs all disappear.
When the program are going to do the extra CI calculation just before solving the CP-MCHF equation,
for some reasons, CANONC=.F. makes the subroutine DAVCI ( in aldeci.src) to adopt a zero array as initial CI coefficients (probably received from the subroutine INITI), then the above issues appear.
Finally, I don't know if these issues also relate to this one mentioned in the google forum.
[x] Description of the run environment:
operating system
Centos 6.7 / Windows 7 & 10( pre-compiled binary)
compiler (if using a pre-compiled binary indicate with pre-compiled binary)
GNU 6.2 / pre-compiled binary
math library
Intel MKL
communication library
sockets / MS-MPI (pre-compiled binary)
[x] An input file (if applicable) to reproduce the issue.
In a SA-MCSCF Hessian calculation (RUNTYP=HESSIAN, CISTEP=ALDET in $MCSCF, METHOD= SEMINUM in $FORCE), when the SA-MCSCF analytic gradient is calculated at initial geometry without any displacement, the CP-MCHF calculation takes many iterations to converge, in comparing with a RUNTYP=GRADIENT job. (about 75 steps for my input file, 100 steps if set IPDIR=50 in $CPMCHF group)
When doing the same SA-MCSCF analytic gradient calculation (RUNTYP=GRADIENT), the CP-MCHF euqation converages smoothly. (about 28 steps for my input file)
In addition, when the program (RUNTYP=HESSIAN) is doing an extra CI calculation just before solving the CP-MCHF equation, the iterations are long and the converged CI coefficients are strange and different from the previously converged ones in the same job:
When RUNTYP=GRADIENT, the converged CI coefficients are the same as the previously converged ones in the same job:
The issues depend on the paremeter CANONC in $MCSCF group. If set CANONC=.F., then similar issues observed in RUNTYP=HESSIAN job also appear in a RUNTYP=GRADIENT job. But when doing RUNTYP=HESSIAN, however, CANONC=.T. (default) is useless. In the subroutine NEWTON ( around line 3850 in mcscf.src), CANONC is forced to be FALSE when RUNTYP=OPTIMIZE, SADPOINT, or HESSIAN (METHOD=SEMINUM):
I also tried RUNTYP=OPTIMIZE, and indeed the same issues appear. But when I block the above IF statement and recompile MCSCF.src, generate the new executable file, make sure CANONC=.T. in $MCSCF group, then the issues in RUNTYP= HESSIAN or OPTIMIZE jobs all disappear.
When the program are going to do the extra CI calculation just before solving the CP-MCHF equation, for some reasons, CANONC=.F. makes the subroutine DAVCI ( in aldeci.src) to adopt a zero array as initial CI coefficients (probably received from the subroutine INITI), then the above issues appear.
Finally, I don't know if these issues also relate to this one mentioned in the google forum.
[x] Description of the run environment:
operating system Centos 6.7 / Windows 7 & 10( pre-compiled binary)
compiler (if using a pre-compiled binary indicate with
pre-compiled binary) GNU 6.2 / pre-compiled binarymath library Intel MKL
communication library sockets / MS-MPI (pre-compiled binary)
[x] An input file (if applicable) to reproduce the issue.