Natural occupation numbers are not in descending order.

[HehnLukas]

In the compute_natorbs function, there is this raise ValueError. I am encountering this for some of my systems. Does this imply that the mp2 natorbs are computed incorrectly? If so, is there anything I can do about it?

or is there a possibility this comes from the DF approximation, that some numbers are slightly off? And I could just remove the error raising statement? As it stands now, it precludes me using the ASF with these systems.

Greetings from BASF, big fan of the updates :)

[ppinski-hqs]

Hi Lukas,

Thanks for opening the issue.

I just looked into the MP2NatorbPreselection.compute_natorbs function: it appears to contain a bug due to a misplaced parenthesis (we would like to take the difference of floats, not of booleans). Additionally, the > should be changed to >= to deal with exactly degenerate natural occupation numbers.

Would you mind to try changing this line as in the following code snippet and trying out if it works for you?

        if np.any(np.diff(natocc) > 0.0):
            raise ValueError("Natural occupation numbers are not in descending order.")

[HehnLukas]

Thank you. This fix seems to work. However, I am now getting an error that

".../asf/natorbs.py", line 293, in count_active_electrons
    raise Exception("Occupation number outside mo_list does not round to 2 or 0.")

and printing the natoccs shows that the first few values are above 3. This seems to be a pyscf problem, as the natocc come straight from the pyscf natocc, natorb = DFUMP2(self.scf).make_natorbs() function, I just wanted to ask if you have ever encoutered it here or if I am mistaken and it could have something to do with the ASF?

[ppinski-hqs]

It is indeed a bit strange, as I would normally expect an unrelaxed MP2 density to have natural occupation numbers between 2 and 0 - in contrast to a relaxed MP2 density, which often does has natural occupation numbers outside that range.

Is there any chance you could send us an example where this happens? If you don't want to post it here, feel free to drop me an email.

[HehnLukas]

I will send you an email with the example. I believe it may be due to a bad convergence of the scf system I am using, as the homo-lumo gap is negative. Alternatively, so far I have only encountered this with a DFT reference, but I don't think that should cause this. Thanks for your help!