EOM-CC3 strange default logic?

Hi all,
What is the rationale behind the following cceom keyword having a default value of false?
“CC3_FOLLOW_ROOT-
Do turn on root following for CC3
Type: boolean
Default: false”

This may be creating different behavior from EOM-CCSD in optking, or at least optking may be ignoring defaults of prop_root and prop_sym?

For example, the following input

molecule {
0 4
Fe
H 1 1.583838
}

set {
reference rohf
docc [8, 0, 2, 2]
socc [0, 1, 1, 1]
roots_per_irrep [2, 0, 0, 0]
scf_type pk
guess sad
SAD_FRAC_OCC true
print_mos true
freeze_core false
}

basis{
assign Fe cc-pwcvtz
assign H cc-pwcvtz
}

optimize(‘eom-ccsd’)

is grabbing the correct root:

    Total CCSD energy   (CC_INFO) = -1263.843757303866596
    Number of States = 1

    Ground?  State     EOM Energy       R0
       No     2 A1    0.0683418643  -0.08206063
   Current energy   :     -1263.7754154395

Convergence Check

Measures of convergence in internal coordinates in au.
Criteria marked as inactive (o), active & met (*), and active & unmet ( ).

Step Total Energy Delta E MAX Force RMS Force MAX Disp RMS Disp

Convergence Criteria    1.00e-06 *    3.00e-04 *             o    1.20e-03 *             o

  7   -1263.77541544   -8.52e-08 *    4.82e-06 *    4.82e-06 o    5.40e-05 *    5.40e-05 o  ~

The same job with EOM-CC3 is ignoring the excited state stuff completely and optimizing the reference wavefunction!

molecule {
0 4
Fe
H 1 1.583838
}

set {
reference rohf
docc [8, 0, 2, 2]
socc [0, 1, 1, 1]
roots_per_irrep [2, 0, 0, 0]
scf_type pk
guess sad
SAD_FRAC_OCC true
print_mos true
freeze_core false
}

basis{
assign Fe cc-pwcvtz
assign H cc-pwcvtz
}

optimize(‘eom-cc3’)

gives in cceom:

follow_root returning: 1
2 0.0503601324 1.03e-09 6.57e-07 Y
Collapsing to only 2 vector(s).
Copying root 2 to start of EOM_Cxxx files.
Change in CC3 energy from last iterated value -0.0000000001

Final Energetic Summary for Converged Roots of Irrep A1
Excitation Energy Total Energy
(eV) (cm^-1) (au) (au)
EOM State 1 1.370 11052.8 0.0503601324 -1263.829468500531

then optking is immediately ignoring the EOM energy/wave function:

Computing gradient from energies (fd_1_0).
Using 3-point formula.
Energy without displacement: -1263.8798286329
Check energies below for precision!
Forces are for mass-weighted, symmetry-adapted cartesians (in au).

     Coord      Energy(-)        Energy(+)        Force
        0  -1263.8798275168 -1263.8798266191     0.0000897629

edit: the keyword below is behaving like it should and grabbing the correct number of threads available from the environment. Should have checked this in any output file before griping
Also:
CC_NUM_THREADS
Number of threads
Type: integer
Default: 1

Does this mean that ccenergy and cceom do not run in parallel by default!? Wouldn’t psi4 want to read OMP_NUM_THREADS from the environment variables?

@amjames Can you field this one?

First w.r.t threading:
In general psi4 will not read from the environmental variable OMP_NUM_THREADS or MKL_NUM_THREADS. To set the number of threads you should use the command either:

  • The command line option: -n <number of threads>
  • In the inputfile/script: psi4.set_num_threads(n)

The option CC_NUM_THREADS is only going to be used in CCSD(T) where some of the triples code is explicitly parallelized using pthreads @ashutosh would be better able to advise on how best to use that option best.

I have to dig a bit further into the behavior you describe for EOM-CC3 vs EOM-CCSD optimizations, and I will post back when I figure that out.