Frequency calculation with ROHF in D2 symm fails: Invalid spatial symmetry

Dear MRCC developers,

I have quite enjoyed exploring the higher-order correlated methods that MRCC provides, and have been successful running geometry optimizations and frequency analysis of small molecules. But I am consistently coming across a problem that I thought maybe experts here can help me to understand. The attached example (pVDZ was a real attempt, STO-3G is a toy example) and description is specifically for ethylene radical cation:

The problem is that when I try to run a frequency calculation, say at the CCSDT level of a radical cation with ROHF reference and automatic symmetry detection, the calculation stops after taking a finite difference step to one of the lower-symmetry displaced geometry.

Attached example 'ethylene_radcat_pvdz_ccsdt_freq_fail.txt of ethylene radical cation in (its proper) D2 symmetry reveals:
 Step 0: Computational point group: D2     Executing xmrcc: all good
 Step 1: Computational point group: C2     Executing xmrcc: all good
 Step 2: Computational point group: C2     Executing xmrcc: all good
 Step 3: Computational point group: C1     Executing xmrcc: Invalid spatial symmetry!  Fatal error in exec xmrcc.
 Spatial symmetry:                      2
 Spatial symmetry of ground state:                      1

The second attached example, starting ethylene radical cation in a flattened (not minimum) D2h symmetry:
Step 0: Computational point group: D2h   Executing xmrcc: all good
Step 1: Computational point group: C2v   Executing xmrcc: Invalid spatial symmetry!  Fatal error in exec xmrcc.
  Spatial symmetry:                      6
  Spatial symmetry of ground state:                      3

The only way I have found to avoid the problem is to specify 'symm=off' but this increases the computational time a lot (we are now calculating gradients at redundant displacements).  But the final frequencies in this case are correct.

The problem does not affect closed shell systems, e.g., running a frequency job of ethylene either in D2h or in D2 symmetry, even with ROHF reference, will take the more-or-less the proper number of finite difference steps without crashing. For example, a toy case of ethylene twisted to D2 geometry, and with ROHF reference happily completes the frequency calculation:

 Computational point group: D2
 Computational point group: C2
 Computational point group: C2
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1
 Computational point group: C1

The problem does not affect geometry optimizations: ethylene radical cation keeps its proper D2 symmetry during CCSDT optimization.

The problem shows up on different computer platforms (Intel, AMD). In some cases, MRCC was compiled from the up-to-date source with recent patches using Intel compilers and MKL math library. In other cases, pre-compiled binaries were used.

Any thoughts?  Given that MRCC is rather unique in its ability to allow the evaluation of frequencies of open-shell systems based on finite differences of gradients at CCSDT and CCSDTQ level, and given that these gradients are not exactly cheap, it would be nice to run frequency calculations of with a smallest number of displacements and with the right symmetry at each displaced geometry.

Thank you,

Kalju

Dear Kalju,
For higher-order CC frequency calculations, you should use the Cfour interface, because together with Cfour, analytic second derivatives can be computed, and it resolves this issue.
If you use the numerical frequency calculations, you can try to change the value of keyword gtol to fix this.

Dear Professor Kallay,

Thank you for your quick and helpful reply. Yes, a ROHF calculation of ethylene radical cation using the Cfour interface to MRCC with FINDIF builds the Hessian based on analytically evaluated gradients at 19 points (each either in D2 or C2 symmetry), and yields the correct frequencies. And if I wanted to use UHF, I could use ANALYTIC. There are no analytic Hessian with ROHF at the CCSDT level using the Cfour interface, I think.

I will proceed with using the Cfour interface as you suggested. Thank you for nudging me to the right direction!