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

Note about this update:

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

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

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