Open yannra opened 1 year ago
Tagging @hgaburton here, in case he has any ideas...?
Hmmm... It looks like P1 and P2 are correctly evaluated in the libgnme::wick_rscf::evaluate_rdm12
routine (you should be able to verify with print statements at the end of this routine).
e.g. for reference determinant in the H2 example...
P1 # evaluated in libgnme::wick_rscf::evaluate_rdm12
2.0000 0
0 0
P2 # evaluated in libgnme::wick_rscf::evaluate_rdm12
2.0000 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
rdm1_tmp
[[0. 0.]
[0. 0.]]
This suggests that the error lies somewhere in the python wrapping?
Would make sense - might be worth a look @obackhouse ....?
I spent some time looking into this, evaluate_rdm1
also has the problem, and therefore I think it's something internal in carma
(probably my misuse rather than their bug). Their documentation isn't amazing so it might not be an easy fix but I will keep looking
Hi all, I stumbled over a slightly weird behaviour pointing to a bug in either the interface or libgnme itself. Essentially, for very small systems/active spaces, the returned RDMs are all zero. The following is a slight modification to the example from the repository, where however the system size is decreased to 4 H atoms, and the same active space (spanning the complete orbital space in this instance) is considered for the bra and the ket state (allowing for a comparison to the pySCF RDM evaluation).
For four Hydrogen atoms, the script gives an all zero 1RDM but the correct 2RDM, if I decrease the number of H atoms to two, also the 2RDM is all zero.
Maybe you guys can have a quick check what is going on here. I already had a brief chat with @obackhouse about this and he reckons the issue is in libgnme where some of the evaluations return early (incorrectly) due to break statements which are applied for small numbers of orbitals. Either way, I'm raising this here as I haven't tested the setup directly within a direct call to libgnme not going via this python wrapper.
Thanks a lot and best wishes, Yannic