Posts by Aerael

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

nevermind, it was an accounting error in my code which multiplies the NAdO occs with the orbcomp numbers.
I accessed the wrong array. which only differed by one letter. Classic. *sigh*

Thanks so much nevertheless!
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

unfortunately, there is another closely related issue that I do not understand.

For systems containing heavier elements (like our 3d transition metal complexes), the full real space DI (obtained during the NAdO generation), and the DI from integrating all NAdOs within ALL (!) basins do not match up.

The NAdO integrals rarely overshoot (still, sometimes it happens!), mostly they severely undershoot (my personal record was about 0.8e). Keep in mind that this happens although all atoms of the system are included in the NAdO generation and integration.

This is probably some sort of accuracy issue, as it only happens with post second row elements. I am using a lunatic-quality AOM with mixed grid. I also tried a 0.02 grid spacing, but it gave the same numbers as lunatic (which is comforting). I also tried increasing the box size because I had this issue with some anionic structures, but increasing box size to double the length did not change the numbers significantly either (in the 0.005e range).

So whatever is happening is not due to box size and grid spacing. I could not control anything about the uniform/atomic grid mixture. I do not know if it possible that the error is in there.

This is my echoed multiwfn input string:
17\n1\n1\n4\n6\n2\n-10\n200\n20\n3\n\nATOMS_OF_FRAGMENT_ONE\nATOMS_OF_FRAGMENT_TWO\ny\n0\n17\n1\n2\n11\n-4\n0\n-10\n100\n2\n7\n\n0\nq\n

Thanks again for having another look.
As always, I can send you an example via email.
I hope you have a great week!

Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

I wanted to kindly ask again if there might be an opportunity to expand the NAdO creation in MultiWFN to multi determinant wave functions.
NAdO author Pendàs published another paper this year which mentions cumulative densities and their relation to NAdOs but does not go into detail either:
https://doi.org/10.1002/jcc.23861

Thanks so much for your consideration!
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

thanks so much!
That should indeed work!

I just an hour ago also had success with a similar method:
I created the basins, exported the AOM, then exported the NAdOs from this AOM, and loaded NAdO.mwfn like suggested by the program automatically. I then used the grid data stored in memory to regenerate the correct basins of the previous SCF density, and subsequently did the orbcomp analysis on the NAdOs within the SCF density basins.

I might switch to your method though, as it allows me to separate AOM creation from orbcomp exporting, which are both pretty time consuming for some of the systems' sizes. I'll have to look wether the .cub files get too big -- those get pretty large sometimes.

Thank you so, SO much for your continuous support, Tian!
Can we do anything for you as a community besides citing the papers of your work?

Aerael · Multiwfn and wavefunction analysis

Dear Tian Lu,

I now know where things go wrong. After exporting the NAdO.mwfn from the correctly built AOM, I leave MultiWFN.
I then read in the exported NAdO.mwfn (to have access to NAdOs), and do a basin analysis from that file. This is the step where all goes wrong.
The resulting basin analysis is indeed inaccurate because it is done from the NAdO density, but only gives out an explicit warning if one tries to expert the AOM.

I instead tried loading in the correct basins (from a basin.cub of the correct AOM) after I open the NAdO.mwfn in MultiWFN, but failed.
I also tried to built the correct basins, and then load in in the NAdOs from their NAdO.mwfn, but also failed.

Could you please explain to me how I can get an orbcomp analysis of the NAdOs, but within normal SCF density AIM basins?
(I'm sending you the orca5.0.3 .gbw from the triplet def2-tzvp / bp86/d3 calculation via email.)

All the best,
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

thank you so much.

I see, so for some reason, between importing the correct orca WF (def2-tzvp / bp86) contained in the .gbw and the export of my NAdO wave function either via nado.mwfn (or the subsequent conversion to .fchk), the basis set gets reduced. That is bad news for me.

I will test some more, and when I find out where in the chain of conversion the error occurs, I will open a new thread.

Until then!

Aerael · Multiwfn and wavefunction analysis

Dear Tian Lu,

I have not received an email reply from you (also not in spam folder). Still, this is incorrect.

My used level of theory is and was NOT B3LYP / 6-31g(d) like it is wrongly stated in the respective .fchk files.
We use def2-tzvp + bp86/d3 (+ rijcosx + def2/j which is virtually impactless) and CPCM in ORCA 5.0.3. This combination is well suited to accurately describe partial charges, effective oxidation states, geometries, and vibrational modes of TMCs, and for our systems (nitrosyl transition metal complexes) it is more accurate than using Minnesota or Head-Gordon functionals and a variety of other meta hybrids, hybrids and pure functionals.

This is cool, so we can resolve two bugs at once, haha.

The .fchks were exported from an orca 5.0.3 wave function read into MultiWFN directly using the orca_2mklpath variable in the settings.ini.
I do not know why the level of theory is read in wrongly by MultiWFN, but it happens for all Orca wave functions, no matter if NAdO or usual, and it also happened independent of Orca main version (tried 4.2.1 and 5.0.3). But this is not important to me, honestly.

Anyway, I can reproduce the NAdO orbcomp error for an UKS singlet calculation, for which the respective RKS calculation of identical quality does NOT show the faulty behaviour. (I used the singlet example I sent you.) UKS and RKS give close to numerically identical results for charges and effective oxidation states based on the same AIM analysis from which I produce the NAdOs, so the AIM analysis is not at fault here.

I was also able to reproduce the error for a def2-qzvpp bp86/d3 (rijcosx def2/j CPCM) calculation of the triplet example I sent you.
I used tight optimisation and SCF convergence criteria, and the WF is not the same as in the optimisation runs, but from a subsequent single point.
Hence, the wave function quality is not to blame either. This is clearly a bug in how unrestricted .fchks are handled by the orbcomp subroutine (EDIT: or how the unrestricted nado.mwfn files are exported, or how unrestricted NAdO-.fchks are exported after being read in from the unrestricted nado.mwfn file).

Thanks for getting at it again!
We all appreciate all your hard work here!

Aerael · Multiwfn and wavefunction analysis

[EDIT: ISSUE SOLVED, IT WAS A USER ERROR, NOT A BUG. FOR A WORKAROUND, READ THE LAST FEW REPLIES!]

Dear Tian Lu,

the orbcomp routine (after 17 basin analysis is done --> 11) can be used to evaluate the natural adaptive orbitals of a .fchk file within the QTAIM basins of the whole electron density contained within the same file. This works flawlessly for simple cases and I use this method.

Unfortunately, for non-singlet transition metal cases, this results in faulty behaviour.
The percentages per spin orbital do not add up to 100.

E.g. for CH4+, all looks perfectly in line with the shape of the NAdOs, and also for other non-singlet systems.
For transition metal systems, it fails. If you calculate a triplet and a singlet state of the same system, the singlet NAdOs orbcomp analysis will result in numbers that match the shapes and add up, while the triplet calculation will not.

Please have a look yourself at the NAdO orbcomp of any non-singlet transition metal system.
I can also email you two examples if you would like.

Thanks so much as always and best wishes and health to you and your family!
Daniel

Aerael · Multiwfn and wavefunction analysis

Oooh, of course, because you integrate Gauss functions which are part of all MOs. Sorry, my bad.
Thanks a lot, I will just bite the bullet of long calculations then.

Aerael · Multiwfn and wavefunction analysis

Thank you Tian,

Yes, I am aware of that. I AM currently exporting all MOs at once with the -4 option, as you suggest.

The thing is, integrating 1000 MOs takes a lot more time than integrating 50 MOs, and I am (currently) mainly interested in the occupied ones, which leaves me with 95% junk (waste of computation time and ressources).
I was just trying to save some energy, and at the same time not do 50 MOs separately by hand.

It's not an urgent request, I just thought it might be a small and quick upgrade to a very useful utility. ^^

Thanks so much as always!
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian,

thanks so much, this works, but needs improvement.

Would it be possible to include a simple switch option to ONLY integrate for occupied MOs, instead of over the whole set?
(Or, alternatively, to be able to specify a set like 2,4-8,11-19 like for other functionalities?)
It is very tedious to do all MOs by hand, and the whole virtual set is probably never needed.

That would be awesome to have!

Thanks so much and all the best!
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Tian Lu & MutliwWFN folks,

is there a way to find out how much each orbital contributes to the occupation of a QTAIM basin?

I have tried to get those numbers myself, but failed:

By loading a wave function, doing a basin analysis for the whole electronic density, I obtain the QTAIM basins.
If I now go ahead and delete all orbitals but the one of interest, the options for basin analysis vanish and I cannot integrate my (by now one-orbital) electron density in these basins anymore.
My next try was loading a modified wave function file containing only the orbital of interest, trying to load the basin cube on top of it, and then to integrate this one-orbital density within the ell-electron basins -- But I do not find the option to do so.

Thanks so much as always for your great help, it is most appreciated!
Daniel

Aerael · Multiwfn and wavefunction analysis

Dear Prof. Tian Lu,

I have used the Bond Order Density (BOD) / Natural Adaptive Orbitals (NAdO) methods. [200,20]
For single determinant methods, everything is fine and well.
Unfortunately, your implementation does not seem to support multi determinant wave functions.
Will there be a way to construct meaningful BOD/NAdOs from e.g. CASSCF wave functions?

AOM creation seems to work well (with valid AOM results), even for non-singlet multiplicities, so I suppose this is not the issue?

Also, the respective error message given if you try to make NAdOs of non-singlet multideterminant WFs
"Error: Only restricted and unresticted single-determinant wavefunction is not supported!"
should probably read
"Error: Only restricted and unresticted single-determinant wavefunction are supported!"

Thanks so much in advance for your answer and thank you for all the good work!
Daniel

Aerael · Multiwfn and wavefunction analysis

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

Aerael · Multiwfn and wavefunction analysis

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

Aerael · Multiwfn and wavefunction analysis

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

Multiwfn forum

#1 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-09-20 11:22:30

#2 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-09-16 13:03:33

#3 Re: Multiwfn and wavefunction analysis » Will BOD/NAdOs be available for non-singlet multi-determinant WFs? » 2022-09-12 14:34:25

#4 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-08-26 15:53:39

#5 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-08-26 09:36:53

#6 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-08-25 16:00:51

#7 Re: Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-08-25 13:16:15

#8 Multiwfn and wavefunction analysis » Bug in non-singlet NAdO orbcomp analysis » 2022-08-22 14:58:13

#9 Re: Multiwfn and wavefunction analysis » Integrate orbital density in external basins » 2022-06-21 14:28:12

#10 Re: Multiwfn and wavefunction analysis » Integrate orbital density in external basins » 2022-06-20 19:58:03

#11 Re: Multiwfn and wavefunction analysis » Integrate orbital density in external basins » 2022-06-20 15:38:39

#12 Multiwfn and wavefunction analysis » Integrate orbital density in external basins » 2022-06-10 13:15:38

#13 Multiwfn and wavefunction analysis » Will BOD/NAdOs be available for non-singlet multi-determinant WFs? » 2021-09-01 12:57:28

#14 Re: Multiwfn and wavefunction analysis » Erronious AOM entries » 2021-06-24 07:40:16

#15 Re: Multiwfn and wavefunction analysis » Erronious AOM entries » 2021-05-07 07:39:22

#16 Multiwfn and wavefunction analysis » Erronious AOM entries » 2021-04-22 12:39:25

Board footer