How generate wfn file in TM V6.3

[tayed]

I'm using turbomole v.6.3 I want to generate wfn file after rimp2 calculation. I have used wfn keyword (keyword not documented in this

TM version) i have wfn file. The problem when i used this wfn file for ELF analyses, I have got something wrong. how can i have a correct wfn file after rimp2 calculation?

Thanks for your help

[Ian K]

You might have to try using tm2molden and then molden2wfn (from here), as described in this thread.

If that works for you, you might also want to send an email to the support guys about it, as uwe says at the bottom of that thread -- otherwise, no one will realise that it's a problem and it won't get looked at.   

[Hauke]

I think I know one problem in the creation of the wfn file in TM 6.3.1 when using ricc2.
Due to the perturbation the occupation of an orbital can become larger than 2 and also negative but Turbomole seems only to exports the orbitals  with occupation >  0.10E-11 and therefore the orbitals with negative occupation are missing in the wfn file. I don't know if one should count orbitals with a negative occupation number as occupied in the output (this seems to me to be more a philosophical question) . In any case, I think they are important as they for example have an effect on the number of electrons calculated as sum over all occupation numbers.

This can easily be reproduced when for example calculation H₂O with aug-cc-pVDZ basis set.

Code: [Select]

    Analysis of the density matrix:
        Number of occupied orbitals   (occupation >   0.10E-11): 38
        Number of unoccupied orbitals (occupation <=  0.10E-11):  5
        total number of electrons as calculated from occupation numbers:       10.0000000000

     Occupation numbers:
         2.000002    1.985848    1.968297    1.966035    1.965894
         0.024128    0.022744    0.020641    0.011503    0.006185
         0.006132    0.005912    0.005255    0.005223    0.000975
         0.000867    0.000662    0.000661    0.000571    0.000557
         0.000525    0.000451    0.000288    0.000286    0.000272
         0.000210    0.000133    0.000068    0.000051    0.000026
         0.000025    0.000024    0.000021    0.000018    0.000010
         0.000009    0.000001    0.000000    0.000000    0.000000
        -0.000002   -0.000103   -0.000405

And the corresponding lines in the wfn file are

Code: [Select]

NO  1       NO 0.0        OCC NO =    2.0000019  ORB. ENERGY =   0.0000000
NO  2       NO 0.0        OCC NO =    1.9858482  ORB. ENERGY =   0.0000000
NO  3       NO 0.0        OCC NO =    1.9682972  ORB. ENERGY =   0.0000000
NO  4       NO 0.0        OCC NO =    1.9660346  ORB. ENERGY =   0.0000000
NO  5       NO 0.0        OCC NO =    1.9658936  ORB. ENERGY =   0.0000000
NO  6       NO 0.0        OCC NO =    0.0241280  ORB. ENERGY =   0.0000000
NO  7       NO 0.0        OCC NO =    0.0227437  ORB. ENERGY =   0.0000000
NO  8       NO 0.0        OCC NO =    0.0206414  ORB. ENERGY =   0.0000000
NO  9       NO 0.0        OCC NO =    0.0115034  ORB. ENERGY =   0.0000000
NO 10       NO 0.0        OCC NO =    0.0061848  ORB. ENERGY =   0.0000000
NO 11       NO 0.0        OCC NO =    0.0061317  ORB. ENERGY =   0.0000000
NO 12       NO 0.0        OCC NO =    0.0059125  ORB. ENERGY =   0.0000000
NO 13       NO 0.0        OCC NO =    0.0052547  ORB. ENERGY =   0.0000000
NO 14       NO 0.0        OCC NO =    0.0052232  ORB. ENERGY =   0.0000000
NO 15       NO 0.0        OCC NO =    0.0009751  ORB. ENERGY =   0.0000000
NO 16       NO 0.0        OCC NO =    0.0008673  ORB. ENERGY =   0.0000000
NO 17       NO 0.0        OCC NO =    0.0006625  ORB. ENERGY =   0.0000000
NO 18       NO 0.0        OCC NO =    0.0006606  ORB. ENERGY =   0.0000000
NO 19       NO 0.0        OCC NO =    0.0005712  ORB. ENERGY =   0.0000000
NO 20       NO 0.0        OCC NO =    0.0005569  ORB. ENERGY =   0.0000000
NO 21       NO 0.0        OCC NO =    0.0005253  ORB. ENERGY =   0.0000000
NO 22       NO 0.0        OCC NO =    0.0004514  ORB. ENERGY =   0.0000000
NO 23       NO 0.0        OCC NO =    0.0002878  ORB. ENERGY =   0.0000000
NO 24       NO 0.0        OCC NO =    0.0002861  ORB. ENERGY =   0.0000000
NO 25       NO 0.0        OCC NO =    0.0002719  ORB. ENERGY =   0.0000000
NO 26       NO 0.0        OCC NO =    0.0002099  ORB. ENERGY =   0.0000000
NO 27       NO 0.0        OCC NO =    0.0001335  ORB. ENERGY =   0.0000000
NO 28       NO 0.0        OCC NO =    0.0000679  ORB. ENERGY =   0.0000000
NO 29       NO 0.0        OCC NO =    0.0000507  ORB. ENERGY =   0.0000000
NO 30       NO 0.0        OCC NO =    0.0000257  ORB. ENERGY =   0.0000000
NO 31       NO 0.0        OCC NO =    0.0000247  ORB. ENERGY =   0.0000000
NO 32       NO 0.0        OCC NO =    0.0000241  ORB. ENERGY =   0.0000000
NO 33       NO 0.0        OCC NO =    0.0000212  ORB. ENERGY =   0.0000000
NO 34       NO 0.0        OCC NO =    0.0000177  ORB. ENERGY =   0.0000000
NO 35       NO 0.0        OCC NO =    0.0000096  ORB. ENERGY =   0.0000000
NO 36       NO 0.0        OCC NO =    0.0000090  ORB. ENERGY =   0.0000000
NO 37       NO 0.0        OCC NO =    0.0000012  ORB. ENERGY =   0.0000000
NO 38       NO 0.0        OCC NO =    0.0000001  ORB. ENERGY =   0.0000000

As the negative entries are missing the sum over all OCC NO in the wfn-file is 10.0005103 and not longer 10.0000000000 as it should be.
I (naively) think that this issue could easily be fixed (one just has to look on the absolute value of the occupation number before deciding if this orbital is exported).
If one is already in this part of the code one can maybe also allow the output (in TM itself and in the wfn file) to have orbital numbers with more than 3 digits. This is not uncommon in these days and then I would have recognized this bug more easily.
(I don't know about the moden format but when running t2molden I seem to get 40 Orbitals of which 4 (!) have an "Occup= 2.000000" and all other 36 have "Occup= 0.000000". I don't know if this can be right.)


But besides this post-HF issue I also have huge troubles with creating proper wfn-files even for DFT/HF-cases (where all occ numbers are positive)

• For some molecules I get the error "too many iterations in tqli (rdiag)" and no wfn is created at all. This problem was already posted here.
• Sometimes the created wfn-file contains huge/small numbers (see attached example) or even NaN entries as coefficients,
• Sometimes the wfn-file looks OK but (AIMAll complains that) it's not proper normalized

The problem with these issues is that I already spent more than a week in trying to reproducible get the error (I already tried different computer clusters, different types of parallelisation, older version of tM...). Sometimes the same input work and sometimes it does not. Also sometimes it worked for me if I just use ridft/dscf -proper to overwrite the faulty wfn file with a correct (proper  ;-) ) one.

Can somebody comment on this negative occ. values and maybe also has an idea about the other problems? I really like QTAIM and would love to do it more often.


Is there a general guide line what questions/comments one should e-mail to the support and for which this forum is the right place? I was expecting that the support guys are also reading this forum as the number of total posts/day is still reasonable.

[uwe]

Hello,

when running post-HF calculation with ricc2 the 'orbitals' for the wfn file format are of course not those of Hartree-Fock, but natural orbitals built from the full density.

For some molecules I get the error "too many iterations in tqli (rdiag)" and no wfn is created at all.

The diagonalization fails to converge, could be caused by the diffuse basis functions. Try a non- or less augmented basis set to check that.

Sometimes the created wfn-file contains huge/small numbers (see attached example) or even NaN entries as coefficients,

That is indeed very strange. I also get strange numbers with dscf, but ridft and ricc2 both work well. As a quick work around I'd recommend to switch on RI-J and run ridft instead of dscf.

But if you get such nonsense output you should in any case send a bug report to the Turbomole support !!

Sometimes the wfn-file looks OK but (AIMAll complains that) it's not proper normalized

That was an issue in older Turbomole versions. Turbomole wfn output should meanwhile be correct up to basis sets with g functions, at least the AIMAll complaints about not properly normalized orbitals or densities disappeared for all test cases.

Is there a general guide line what questions/comments one should e-mail to the support and for which this forum is the right place?

This user forum is not the Turbomole support!

If you run into bugs or whenever problems occur, contact the support.
If you want to ask other users for help,  or if you want to get or give hints, or if you want to discuss topics with other users, of if you want to share tools or scripts that other users might find useful too, ... then this forum is the right place.

Regards,

Uwe

[Hauke]

Thanks for your reply!

when running post-HF calculation with ricc2 the 'orbitals' for the wfn file format are of course not those of Hartree-Fock, but natural orbitals built from the full density.

I understand why the occupation of a natural orbital in ricc2 can be larger than 2 or negative but I don't understand why only the larger ones but not the negative ones are written into the wfn file (see water example above). Or what is the point I'm missing here?

For some molecules I get the error "too many iterations in tqli (rdiag)" and no wfn is created at all.

The diagonalization fails to converge, could be caused by the diffuse basis functions. Try a non- or less augmented basis set to check that.

I got the error for example when calculation a system with HF/cc-pvDZ basis set, so I doubt that a too diffused basis set is the problem in my case (but a few lines above the error it stated Determinant: 0.4364783747+217 which might be related to the problem of the "big numbers" in dscf or is such a determinant reasonable?)
It even seem to work better for bigger basis set? I had studied a system with 4 different conformers. Of the HF runs using aug-cc-pVDZ only 1 of 4 produced a wfn-file, the other 3 exceeded the iterations in tqli (but all 4 runs had huge absolute values of the determinant). When switching to aug-cc-pVTZ all 4 produced wfn files (and all determinants where shown as 0).
At RI-MP2 level (ricc2) the one that worked at HF created a wfn containing some NaN coefficients and all other 7 directly failed in the diagonalization step.

That is indeed very strange. I also get strange numbers with dscf, but ridft and ricc2 both work well. As a quick work around I'd recommend to switch on RI-J and run ridft instead of dscf.

Good that you can at least reproduce it. As I don't have any experience in running simple HF calculations with ridft, do you recommend to use Coulomb- and exchange-fitting ($jkbas) or do you think Coulomb-fitting is sufficient (as you only mentioned RI-J)?

But if you get such nonsense output you should in any case send a bug report to the Turbomole support !!

As the nice $wfn keyword is not mentioned in the manual, I didn't know if there are any known limitations.

Sometimes the wfn-file looks OK but (AIMAll complains that) it's not proper normalized

That was an issue in older Turbomole versions. Turbomole wfn output should meanwhile be correct up to basis sets with g functions, at least the AIMAll complaints about not properly normalized orbitals or densities disappeared for all test cases.

I even got this problem when calculating a Ne-atom using RI-BP86/def2-TZVPP (the highest basis function is a f-function) in combination of TM 6.3.1 (MPI parallelized [of course I didn't used the MPI parallelized version because of the complicated Ne-atom but because I wanted to test if this type works for my bigger systems.]). But as I've mentioned, I still struggle to reproducible get the error as it works on some of our cluster machines but doesn't work on others and I haven't found the important difference yet.... (what makes it a bit difficult to contact the support about this, but I'll do some more tests and then contact them). But of course all other comments are welcome to.