Erronious AOM entries

Aerael · 2021-04-22 12:39:25

Dear Tian Lu, dear others,

I need help with an issue that I suspect is a MultiWFN bug.
I encountered erronious entries in an AOM I exported with MultiWFN:

Atomic overlap matrix of 1(Ru) 1 2 3 4 5 1 1.72115524 2 -0.24025565 1.08034266 3 -0.02063895 0.00695593 0.99851652 4 0.00998040 -0.00336499 -0.00017595 0.99797202 5 -0.00582560 0.00196416 0.00010847 -0.00009191 0.99790574 6 0.00000001 -0.00000001 -0.00000000 -0.00000005 -0.00000004 7 -0.00000002 0.00000001 -0.00000000 0.00000005 -0.00000004

[...]

... while an AIMAll AOM of a friend of mine of the SAME .wfn file resulted in

0.9999999396 0.0000000641 0.9999999216 -0.0000000001 0.0000000001 0.9999998757 0.0000000093 -0.0000000118 -0.0000000000 0.9999999144 -0.0000000004 0.0000000005 -0.0000000006 0.0000000005 0.9999999140

... and so on, which of course looks far more realistic.

The structure is [Ru(NO)_2(PMe_3)_2], a neutral singlet complex of Ruthenium (4d metal) with two nitrosyle and two phosphine ligands.
The real problem here is that subsequent treatment of the MultiWFN created AOM with a non-MultiWFN QTAIM method gave a charge of -1.6 for the whole (NEUTRAL!) complex. (We had a similar thing happen before when we used medium quality basin AOMs, which we quickly accounted for by exchanging "medium" with "lunatic" quality.)

As we work with ORCA, to obtain the .wfn file we feed into MultiWFN, I used a SARC4 basis plus a SARC/j auxiliary basis for my BP86/D3BJ/RI calculation.
(The other atoms were treated with def2-tzvp + def2/j.) The calculations should does thus not feature any ECPs.
The last SCF of my successful geometry optimisation went through fine within 12 steps, no errors, the diagnostics looked fine. I can post further details or uplaod the .out file on request. This is the S-part of the basis set I use for Ru:

S 8 1 802582.167241 0.001700308820 2 356703.185440 -0.000747250377 3 158534.749085 0.003509047748 4 70459.888482 0.002067471732 5 31315.505992 0.008453224479 6 13918.002663 0.014285362114 7 6185.778961 0.034641095215 8 2749.235094 0.075420901867 S 1 1 1221.882264 1.0 S 1 1 543.058784 1.0 S 1 1 241.359460 1.0 S 1 1 107.270871 1.0 S 1 1 47.675943 1.0 S 1 1 21.189308 1.0 S 1 1 9.417470 1.0 S 1 1 4.185542 1.0 S 1 1 1.860241 1.0 S 1 1 0.826774 1.0 S 1 1 0.367455 1.0 S 1 1 0.163313 1.0 S 1 1 0.072584 1.0 S 1 1 0.032259 1.0

Now we use ORCA's internal .gbw --> .wfn conversion tool to make a .wfn file. I then and open it in MultiWFN. I request the most accurate basins I can (17 1 1 4) and then export the AOM (6). I have in the past tried to raise the integration grid via the settings.ini to 100/590, which made only negligble differences for electronic integration and no difference for basin creation, so I strongly suspect this will not be the issue here.

I made a reality check with a smaller system, which consists of ONLY Ruthenium (q=+1 M=6, bp86 and the basis set above in the input):

MO #0 (Orca starts counting at 0) is comprised mainly of the first 4 functions of the 8 contracted 1s function we see in the basis above. MO #0 vector (there are literally only zeros after the s section):

0 -852.38121 1.00000 -------- 0Ru 1s -0.115034 0Ru 2s -0.304090 0Ru 3s -0.247047 0Ru 4s -0.445264 0Ru 5s 0.025511 0Ru 6s -0.077415 0Ru 7s 0.056038 0Ru 8s -0.039081 0Ru 9s 0.026399 0Ru 10s -0.017424 0Ru 11s 0.011220 0Ru 12s -0.006933 0Ru 13s 0.003924 0Ru 14s -0.001811 0Ru 15s 0.000495 ...

...but we still do not get 1 in the AOM, despite only having one atom and the 1s being VERY low and isolated in energy:

Alpha part of atomic overlap matrix of 1(Ru) 1 2 3 4 5 1 0.81646556 2 0.06853782 0.97412651 3 0.00000000 -0.00000000 1.00135680 4 0.00000000 -0.00000000 0.00000000 1.00135683 5 -0.00000000 0.00000000 0.00000000 -0.00000000 1.00135683

...

So, I am at a loss here. The possibility that ORCA does something wrong with .gbw to .wfn conversion is low, so I suspect an error in MultiWFN AOM creation. A friend of mine suggested maybe a normalisation issue. I have heard ORCA handles their d function in strange ways, and we did not have that problem of a weird charge appearing for 3d metals. Another structure of this very Ru complex (geometrically excited) did not show a drastic charge offset like the one I talk about, while charge and multiplicity, as well as rough geometry and bonding situation stay the same.

Note: I also checked the AOM entries for a simple sextet Co +2 (just because we worked a lot with Cobalt before), and this also gives non-1-entries for the AOM, where it should essentially be fully occupied 1s orbitals:

Alpha part of atomic overlap matrix of 1(Co) 1 2 3 4 5 1 0.96077244 2 -0.01236440 0.99610224 3 0.00000000 0.00000000 1.00007379 4 0.00000000 0.00000000 0.00000000 1.00007384 5 0.00000000 0.00000000 -0.00000000 -0.00000000 1.00007384

Anyway, please help me out here. I like MultiWFN, but this really makes me question the integrity of its basin analysis + AOM creation. The results LOOKED fine for 3d metals, but the error seems to be the same for 4d and 3d metals, just coincidentally exaggerated with the first Ru case... we rely on those AOMs for charges!

Thanks so much for your time, effort, help and friendlyness!
I wish best health to you all and your loved ones! All the best,
Daniel

sobereva · 2021-05-05 03:33:14

Dear Daniel,

The reason is that very heavy atom has very sharp core orbital (especially 1s); to accurately integrate this kind of orbitals, atomic-center integration grid must be employed to integrate the region very close to nucleus. Although basin analysis module of Multiwfn employs atomic-center grid to calculate atomic charge and atomic multiple moments, the AOM matrix is currently fully evaluated based on evenly distributed grid, which is able to satisfactorily integrate valence region but inadequate to nicely integrate core region (even if using lunatic grid for very heavy atoms).

If you really need to obtain an accurate AOM, there are two choices:
(1) Use pseudopotential basis set, in this case there is no core orbitals.
(2) Wait until I have time to modify basin analysis code, so that AOM can also be estimated via evenly distributed grid in combination with atomic-center grid.

If you just need to obtain atomic charges or atomic multiple moments, you can simply ignore the problem of inaccurate AOM.

There may also be other reasons leading to the problematic AOM. However if you find AIM atomic charges given by basins analysis module are reasonable, then your finding about AOM should be solely caused by the aforementioned issue.

Best regards,

Tian

Aerael · 2021-05-07 07:39:22

Dear Tian Lu,

Thanks a lot for the transparent explanation!

We really DO need an accurate AOM for use in third party programs.
We also do NOT want to rely on ECPs to include relativistic effects.

We will probably use AIMAll for the time being, but we're waiting eagerly on the update for a more precise atomic center integration grid for the AOM integration.
MultiWFN is a really, really useful and great tool and we can't wait to use it more again. Thanks for the awesome package!

All the best and good health!
Daniel

sobereva · 2021-05-07 07:56:28

Please send your wavefunction file to my E-mail (see first page of Multiwfn manual), I want to use it to test my new code.

sobereva · 2021-06-24 00:31:54

I am glad to inform you that I finally find time to finish new integration code for calculating basin overlap matrix using mixed type of integration grid, now you can download latest version from Multiwfn website. I have tested, AOM of your system containing Ru can be evaluated very accurately!

Note about this update:

[2021-Jun-24] Mixed type of grid (uniform + atomic center grid) now has been supported to calculate basin overlap matrix (BOM) of AIM basins in basin analysis module, the quality of the resulting BOM is significantly better than previous version especially for core orbitals. Specifically, in main function 17, if the real space function used to generate the basins is electron density, after entering option 4 to evaluate LI/DI, or after entering option 5 (or 6) to output BOM (or atomic overlap matrix), Multiwfn will ask you to choose type of integration grid for evaluating BOM.

Aerael · 2021-06-24 07:40:16

Dear Professor Tian Lu,

thanks as always for the (given your tight time schedule) quick and satisfactory solution!
I got your email and will get to work right away using this newly precision boosted tool.
We all greatly appreciate your support and service to this community!

All the best,
Daniel

Multiwfn forum

#12021-04-22 12:39:25

Erronious AOM entries

#22021-05-05 03:33:14

Re: Erronious AOM entries

#32021-05-07 07:39:22

Re: Erronious AOM entries

#42021-05-07 07:56:28

Re: Erronious AOM entries

#52021-06-24 00:31:54

Re: Erronious AOM entries

#62021-06-24 07:40:16

Re: Erronious AOM entries

Board footer