Molcas Forum

andrewshyichuk

Member

Registered: 2020-02-13

Posts: 86

MCKINLEY after RASSCF results in error

Dear Users,

I am having a strange issue with RASSCF and MCKINLEY.

I want to calculate vibrational frequencies for a cluster of atoms using RASSCF ground state.
The system of interest is Lu2O3 solid, I thus use embedding with AIMPs. The cluster is (LuO6)9-.

Following the example from https://www.molcas.org/documentation/ma … de122.html, I have a GATEWAY > SEWARD > SCF > RASSCF > MCKINLEY sequence of inputs.
Depending on the system, this sequence does either numerical ( MCKINLEY > { SLAPAF > SEWARD > SLAPAF > ALASKA} ), or analytical (MCKINLEY > MCLR) gradient.

1. The example works fine, analytical gradient.
2. A test cluster without embedding, using CASSCF (ciroot 1 1 1, nactel 36 0 0, oxygen 2p and some higher orbitals in RAS2) calculates with no issues, analytical gradient.
3. A test cluster without embedding, using RASSCF (ciroot 1 1 1, nactel 36 2 0, oxygen 2p in RAS1, Lu 6s6p5d in RAS2) tries analytical gradient, results in an error:
  OpnFls: Wavefunction type:RASSCF
          Illegal type of wave function!
          McKinley can not continue
which is quite weird to me. Why does a possibility to get analytical gradient depend on the active space? Why doesn't it use numerical gradients in this case?
4. The same test cluster put into the embedding calculates with no issues, using both kinds of active spaces and numerical gradient.

Hense, the questions:

- Why does the choice of numerical or analytical gradients depend on the AIMPs?
- What is the exact correct list of cases where analytical gradients are used?

The manual is inconsistent in regard of the latter matter.

Page https://www.molcas.org/documentation/manual/node32.html says:
MOLCAS 8.2 can perform geometry optimizations at the SCF (RHF and UHF), DFT (RHF and UHF based), CASSCF (CASSCF and RASSCF) levels of theory, where efficient analytical gradients are available and at the CASPT2 and other correlated levels where numerical gradients are used.

The very same page also says:
MOLCAS can compute analytical Hessians for SCF and single state CASSCF wave functions. For other methods, numerical procedures can be used to compute the Hessian.

Thank you in advance.
Best regards.
Andrew

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,085

Re: MCKINLEY after RASSCF results in error

You talk about gradients (first derivative), but MCKINLEY is about Hessians (second derivative). I assume whenever you say analytical/numerical gradient you mean Hessian.

Why does a possibility to get analytical gradient depend on the active space?

There's a difference between CASSCF and RASSCF. In CASSCF (no RAS1 or RAS3), all active orbitals are in the same subspace and can rotate freely, in RASSCF there is a difference between RAS1, RAS2 and RAS3.

The manual is inconsistent in regard of the latter matter.

I don't think so, analytical gradients are implemented for some methods, analytical Hessians are implemented for fewer methods.

What is the exact correct list of cases where analytical gradients are used

That is quite difficult to answer, as there are combinations with e.g. RICD/Cholesky, symmetry, parallel. But, if you mean Hessian, I think it's basically HF and ground-state-only CASSCF, without RICD or PCM.

Why does the choice of numerical or analytical gradients depend on the AIMPs

It might be a bug, it might be that some required terms are not implemented. Please provide a small test case.

using RASSCF (ciroot 1 1 1, nactel 36 2 0, oxygen 2p in RAS1, Lu 6s6p5d in RAS2) tries analytical gradient, results in an error:
  OpnFls: Wavefunction type:RASSCF
          Illegal type of wave function!
          McKinley can not continue

That is definitely a bug. If analytical RASSCF Hessians are not implemented, the code should have never reached here; if they are, it should not stop.

andrewshyichuk

Member

Registered: 2020-02-13

Posts: 86

Re: MCKINLEY after RASSCF results in error

Dear Ignacio,

I have indeed mistaken Hessians with gradients, thank you. No questions to the manual.

As for the test cases - pleace consider this zip:
https://www.dropbox.com/s/8oqog3dtndnd4 … k.zip?dl=0

Inside, there are 4 cases: input, outputs and libs, as well as a description of the files.

The two CASSCF cases differ in the embedding only, and result in different Hessian calculations.

Thank you for your help.

Best regards.
Andrew

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,085

Re: MCKINLEY after RASSCF results in error

Try to create a test that runs in a few minutes, not a few hours.

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,085

Re: MCKINLEY after RASSCF results in error

The problem is XField. MCKINLEY does not support analytical Hessians with external field

&GATEWAY
Coord = 2

H 0.0 0.0 0.0
H 1.0 0.0 0.0
Basis = STO-3G
Group = NoSymm

XField = 1 0
  10.0 10.0 10.0 0.1

&SEWARD

&SCF

&MCKINLEY

andrewshyichuk

Member

Registered: 2020-02-13

Posts: 86

Re: MCKINLEY after RASSCF results in error

Thank you, that clarifies the things.

andrewshyichuk

Member

Registered: 2020-02-13

Posts: 86

Re: MCKINLEY after RASSCF results in error

I've tried the metioned calculations without the xfield (regular atoms + AIMPs).

MCKINLEY initiated properly, but resulted in an error:

Location: WrMck                   
"Undefined Label: ELEC  1"

The code terminated with rc=_RC_INTERNAL_ERROR_ and "Some internal inconsistency of the code was detected".

Notewothy, the same input file with reduced number of atoms (two oxygens and several AIMPs, at least one of each AIMP kind) completed with no issues.

Could that be another bug?

andrewshyichuk

Member

Registered: 2020-02-13

Posts: 86

Re: MCKINLEY after RASSCF results in error

In continuation of my previous post in this topic, I did some more tests.

I replaced Lu and O with He to make a smaller basis. Other then that, it is an almost correct LuO6 cluster of C2 symmetry in Lu2O3 embedding.
"Almost correct" means that the nearby AIMPs have no orbitals, while in the correct/production version they have some.
The tests ran for a few seconds.

Briefly, it turned out that the occurence of the  "Undefined Label: ELEC  1" depends on the kind of AIMPs I use (it can be also "Undefined Label: ELEC  2" or "Undefined Label: ELEC  3"). But, when I reduced the number of AIMPs from hundreds to a dozen, that error disappeared, MCKINLEY called MCLR, which failed at printing frequencies part, namely:

      ************************************
      *                                  *
      * Harmonic frequencies in cm-1     *
      * Intensities in km/mole           *
      *                                  *
      * No correction due to curvilinear *
      * representations has been done    *
      *                                  *
      ************************************


    Symmetry a
   ==============
--- Stop Module: mclr at Sat May 30 15:43:32 2020 /rc=_RC_INTERNAL_ERROR_ ---
*** files: xmldump
    saved to directory /scratch/andrew/WorkSpace/AIMP-test

.########################################################.
.# Some internal inconsistency of the code was detected #.
.########################################################.

Tested with builds d7828899 and e37d2a1c.

Steps to reproduce:

1. Download my tests: https://www.dropbox.com/s/39c2wdfcpk3f2 … e.zip?dl=0
2. Make a folder for tests, e.g. /scratch/test
3. Unpack the zip there.
4. export MOLCAS_WORKDIR=/scratch/test
5. Run tests as pymolcas $name.input > $name.output
This will use /scratch/test/$name folder as the actual workdir. The folders are already there, and contain the required AIMPLIB/ECP file.

Thus, there are two potential bugs here:
a). WrMck failure with many AIMPs;
b). MCLR failure with few AIMPs.