Support and discussions for Molcas and OpenMolcas users and developers
You are not logged in.
Please note: The forum's URL has changed. The new URL is: https://molcasforum.univie.ac.at. Please update your bookmarks!
You can choose an avatar and change the default style by going to "Profile" → "Personality" or "Display".Pages: 1
Dear all,
Is there any undocumented keyword/procedure that would allow the direct extraction of CASPT2 natural orbitals onto a molden file ?
I'm aware that a &RASSCF run with CIONLY can produce it from a fed in PT2ORB file but that molden file will not contain the natural occupations in the same way as it can come out from an &mbpt2 run. I was planning to use such a molden file by a third party population analysis program which of course needs the correct occupations.
Best regards,
Nuno
Offline
I'm not sure there's any automated way in 8.0, generating a caspt2.molden file was added in the development version about a year ago. But the occupation numbers should be written in the Pt2Orb file, you may be able to transfer the numbers to the molden file. You could also try molpy (https://github.com/steabert/molpy), but I'm not sure it can do that either (the Pt2Orb does not contain all the information needed for the molden file). In any case, transferring the orbitals from Pt2Orb to molden is mostly a matter of rearranging the coefficients, I may have some old script that could do the job...
Offline
Nuno,
there is one 'undocumented' feature: run &SCF with ITER=0. It will do nothing with the orbitals, but compute all properties, e.g. charges, and produce a molden file
Offline
Thanks!
Molpy looks promising but it mentions an hdf file which I have no idea what it is. RunFile perhaps?
Valera's approach to cheat the program seems to be the most pragmatic, until the next version comes out that is.
Offline
Actually I've tried this with MOLCAS 8.0 and what I got was a memory error and no molden file.
++ Optimization specifications:
----------------------------
SCF Algorithm: LK-Cholesky
The actual AO density is used
Number of density matrices in core 1
Maximum number of NDDO SCF iterations 0
Maximum number of HF SCF iterations 0
Threshold for SCF energy change 0.10E-08
Threshold for density matrix 0.10E-03
Threshold for Fock matrix 0.15E-03
Threshold for linear dependence 0.10E-08
Threshold at which DIIS is turned on 0.15E+00
Threshold at which QNR/C2DIIS is turned on 0.15E+00
Threshold for Norm(delta) (QNR/C2DIIS) 0.20E-04
DIIS extrapolation of the SCF procedure
All orbitals punched on: SCFORB
--
Input vectors read from INPORB
Orbital file label: * CASPT2
---------------------------------------------------------------------------------------------
Nr. Label Type Offset Length Atime Address
---------------------------------------------------------------------------------------------
1 IP_DUM REAL 5129180 8 2 [0x3865020]
2 IP_SDUM SNGL 10258344 4 3 [0x3864fe0]
3 IP_IDUM INTE 5129176 8 4 [0x3865000]
4 IGATIM REAL 5126722 160 5 [0x3860350]
5 IGASTAT REAL 5126744 56 6 [0x3860400]
6 ONEHAM REAL 5134554 84680 12 [0x386f810]
7 OVLP REAL 5145140 84712 13 [0x38842e0]
8 LOWDIN REAL 17482276017114 168200 14 [0x7f3347e4d010]
9 TRMAT REAL 5155730 168200 18 [0x3898dd0]
10 CMO REAL 5176756 168200 19 [0x38c1ee0]
11 FOCK REAL 5197782 84712 20 [0x38eaff0]
12 OCCNO REAL 5208372 1160 21 [0x38ffae0]
13 EORB REAL 5208518 1160 22 [0x38fff70]
14 DENS REAL 5208664 169360 23 [0x3900400]
15 TWOHAM REAL 5229836 169360 24 [0x39299a0]
16 AW REAL 5253768 84680 57 [0x3958580]
17 DNSS REAL 5264354 168200 58 [0x396d050]
18 LWFSQ REAL 5302158 168200 59 [0x39b6db0]
19 TEMPFLT REAL 5285380 84680 60 [0x3996160]
20 NVEC_A+ INTE 5126778 16 61 [0x3860510]
21 CHOMOS REAL 5323184 168200 62 [0x39dfec0]
22 DIAGI REAL 5344210 84664 64 [0x3a08fd0]
23 DIAHI REAL 5354794 168200 65 [0x3a1da90]
24 ABSC REAL 5251928 1160 66 [0x3954c00]
25 YC REAL 5375820 168200 67 [0x3a46ba0]
26 MLK REAL 5295966 12760 68 [0x39aac30]
27 SKSH REAL 5297562 12760 69 [0x39ade10]
28 INDX INTE 5299158 13920 70 [0x39b0ff0]
29 IP_LAB INTE 5252074 88 71 [0x3955090]
30 IP_KOFF INTE 5252086 88 72 [0x39550f0]
31 IP_NNBF INTE 5252098 528 73 [0x3955150]
32 IP_ISHP INTE 5252166 528 74 [0x3955370]
33 IP_SVSH REAL 5252234 1056 75 [0x3955590]
---------------------------------------------------------------------------------------------
Maximal available memory for Molcas = 3143490092
MEMORY ERROR: Memory is exhausted!
MEMORY ERROR: Available memory = 3143490092 ( 2997 Mb ) !
MEMORY ERROR: Requested memory = 3145728088 ( 3000 Mb ) !
MEMORY ERROR: The suggested MOLCASMEM=5997 !
C_GetMem Calling parameters: ('F(K)SS ','ALLO ','REAL ',59114736,393216011)
++ Convergence information
No optimization is performed
Results refer to input orbitals read from INPORB
Single iteration finished!
--
MMA failed to allocate a memory block.
--- Stop Module: scf at Tue Oct 4 13:01:38 2016 /rc= _MEMORY_ERROR_ ---
Segmentation dump
...................................................................................................
...................................................................................................
....Let me put it this way, Mr. Amor...............................................................
....The 9000 series is the most reliable computer ever made........................................
....No 9000 computer has ever made a mistake or distorted information..............................
....We are all, by any practical definition of the words, foolproof and incapable of error.........
...................................................................................................
Offline
I found out what's causing the error. The &SCF module won't finish the job if CHOLESKY is chosen in &Seward. This could take some time for big molecules.
Last edited by Nuno (2016-10-04 13:48:38)
Offline
I'd suggest you use RICD in GATEWAY instead of Cholesky in SEWARD...
Offline
Perform a CASSCF calculation with zero iterations, with only the optimization of the CI vector.
The calculation ends quickly without converge, and MOLCAS prints the CASPT2 Molden file.
&GATEWAY
coord=test.xyz
basis=ANO-S-VTZP
Group=Nosym
&SEWARD
&RASSCF
FileOrb=$DIR/test.Pt2Orb
symmetry=1
spin=1
INACtive=23
nactel=12 0 0
Ras2=11
CIONly
CIMX=0
LumOrb
If the SCF calculation is performed the occupation numbers are assigned incorrectly.
Last edited by josejc (2016-10-08 01:27:31)
Offline
Dear josejc
I do not want to optimize the CI vector. That has already been done by the CASPT2 module. In fact I don't want MOLCAS to touch the MOs at all.
In fact I'm not even sure the MO order in the PT2Orb file is the same as in a RasOrb file since post-perturbation natural occupations can change slightly especially if you have moderately significant intruder states or you're using constraints as with supsym. Since the logical move would be to order the MOs by growing natural occupation the Pt2Orb file may well have a different orbital ordering from that of RasOrb as a consequence.
Valera's approach does work but only without Cholesky in &Seward. I have no idea why. I haven't tried it with RICD but I will do.
Last edited by Nuno (2016-10-14 11:02:38)
Offline
The RASSCF module is called in this case only for read the INPORB file and print the Molden file. The starting molecular orbitals (CASPT2) are included in the RASSCF module as "FileOrb=$DIR/test.Pt2Orb", and the the name of the caspt2 molden file will be $input.rasscf.molden as they were generated with the rasscf module.
The calculation does not optimize, does nothing (CIONly;CIMX=0); begins, read the starting MO, does nothing, finish and print the "$ input.rasscf.molden" file. In this case, the rasscf output (ci vector, etc.) makes no sense at all, but the Molden file is generated correctly.
In that way I get the caspt2 molden files with molcas78 (without Cholesky decomposition). Some time ago, I wrote a perl script to get the castp2 molden file directly from the Pt2Orb file (with other information from the Molcas output) and I got the same result as perform the fake rasscf calculation.
If you do the SCF calculation with zero iterations (the Valera's approach) the caspt2 molden file is also generated correctly, but in this case the occupation numbers are set to 0 and 2.
Offline
If you do the SCF calculation with zero iterations (the Valera's approach) the caspt2 molden file is also generated correctly, but in this case the occupation numbers are set to 0 and 2.
This is not true. The occupation numbers are copied verbatim from INPORB. The only thing different is that the orbitals have one electron energies assigned to them in the molden file. This of course on molcas 8sp1.
Offline
Pages: 1