Faulty wfn files

[hmsenn]

I have used the $wfn keyword and ridft -proper to generate wfn files for a couple of molecules. The AIM analysis program that reads the wfn file performs some simple consistency checks. It calculates the number of electrons, N, in two ways: (1) By summing up the occupation numbers given for each MO in the wfn file; and (2) by integrating the density constructed from the MOs.
All the wfn files generated by TM (version 5.9.1) fail the test:
- In one case, not all occupation numbers in the wfn file are exactly 2, and they don't sum up to N.
- In all cases, the integrated density deviates somewhat from the correct N. The discrepancy seems to be related to the size of the molecule/no. of basis functions.

The results of the AIM analyses, however, look reasonable in all cases. By comparison, with wfn files generated by Gaussian, the N from integration is exact to about 10 decimal places, and we have never seen incorrect occupation numbers.

So I am rather concerned that something goes wrong in the conversion from mos to wfn in TM. Any comments or suggestions? Has anybody else seen this problem?

Thanks
Hans

[uwe]

Hi,

try the alternative way using tm2molden and then molden2wfn from ftp://ftp.chemie.uni-karlsruhe.de/pub/tools/tm2aim/

Regards,

Uwe

[Jerry]

I have been using wfn files for ELF analyses with TopMod.  The wfn files I generated from GAMESS worked fine, but the ones using $wfn did not work.  Some of the problems I had were the use of lower case letters for the atoms instead of capital letters, the word "CENTER" instead of "CENTRE", and scientific notation being 1.00D-5 instead of 1.00E-5.  Also, there are not atom numbers associated with the atoms.  When I edited the file, everything was OK, but it took a lot of work to do that.  Uwe sent me the molden2wfn file.  I was able to generate wfn files that were identical to the ones generated by GAMESS.  However, the conversion from molden to wfn worked for most of my cases, but not all.  Hopefully they (TURBOMOLE) are fixing the problem.  I'm not sure if the problem occurred in the tm2molden or the molden2wfn step.

Hope this helps.

Kindest regards,
Jerry

[tcsh]

Hello everybody,

I have also experienced problems while generating *.wfn wavefunction files with Turbomole (Version 5.9 and 5.10). Some of the testruns worked nicely (single molecule of water, benzene), others deliver very curious results within AIM2000 (water dimer, substituted benzene structures). I need these files for further analysis within the QTAIM theory. If I generate these files with Gaussian03 Rev C.02, they are fine and work perfectly, but if I try to create them within Turbomole, the format is somewhat mixed up. I figured out, that the sequence of CENTRE/CENTER ASSIGNMENTS (no matter if written with "RE" or "ER") is different, but that the corresponding EXPONENTS are the same. Unfortunately also the TYPE ASSIGNMENTS are mixed up and I could not find matching values for the values given for each MO.
I would like to know, weather there is some information freely available on the format of *.wfn files, so that I can figure out how to get the right values at the right place. molden2wfn does not work on our machines.
Greetings

tcsh

[CoJack]

Hi there,
we also experienced problems with the tm2molden tool (no wfn file involved!). According to Dr Kohout (the inventor of the DGrid package) something goes wrong with the d-function normalization in this step. The integration over the density grid e.g. for a single Krypton atom calculated with TM does not yield an integer number! This problem arises when d orbitals are involved. For any hint how to solve this problem we would be very grateful!
Cheers,
CoJack

[uwe]

Hi,

here I would like to take the opportunity to thank hmsenn for sending a bug report to the Turbomole support. Obviously there have been other users who had problems with the export of the orbital coefficients too, but without sending a bug report to the support, the problem will most likely never ever be fixed 

Currently I do not see where the problem is. The orbitals are transformed from AO to CAO basis with default Turbomole functions which are also used in many other places. For tm2molden, a factor of 1.0/sqrt(3) has been applied for the xy, xz, yz values, since molden multiplies sqrt(3) when reading in the input file.

Any hint is welcome and can shorten the effort finding the problem!

Regards,

Uwe

[CoJack]

Is there a similar thing for the normalization for f-functions?

[uwe]

Hi,

tm2molden as well as wfn files should be correct for up to d functions, as far as I can see. tm2molden also exports f and g functions in the right order and with the right normalization within the shells. But there still might be that a program which reads in those input files assuming a different global scaling factor for all f's or g's, etc.

So I can just repeat my plea: If you think that there are problems with the files, please contact turbomole # cosmologic de !

Regards,

Uwe

[sebastian]

Sorry, the problem with d-functions in molden files and DGRID should be fixed in DGRID 4.5.

Regards,
Sebastian