Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mulliken's total charge seems to be only half of the real total charge #611

Closed
AsymmetryChou opened this issue Sep 10, 2023 · 10 comments
Closed

Comments

@AsymmetryChou
Copy link

Describe the issue
I use Mulliken analysis on a system with 120 shell electrons(60 up and 60 down) using spin polarization. However, through DM.mulliken operation which outputs [Total, Sz], I only find total charge is 60 sumed in all atoms.

PS: In #501, I found the definiton(consistent with me)
Total = up + down (So in this case Total should be 120?)
z = up - down

# spin polarization case
DM = sisl.get_sile('../test_mol/mol/+2_tshs/sta.fdf').read_density_matrix()
print(DM.shape)
mul_charge = DM.mulliken(projection='atom')
print(mul_charge.shape)

print('Total:', mul_charge[0,:].sum())

#(296, 296, 3)
#(2, 44)
#Total: 60.00020554917267

Here I have 2 questions:

  1. what 's the meaning of the last number 3 in (296, 296, 3). Apart from spin up and spin down,what's the third dimension?
  2. When I sum up the charge in all atoms, I only got half of the total eletrons(60,not 120). I carefully look up at the output file of Siesta where doing an Mulliken analysis, the total mulliken charge for up and down is both 60, which is consistent with my initial analysis but is different from sisl output Total in [Total, Sz]. It really bothers me.

I am a beginner in Sisl so maybe there are some naive mistakes above. Thanks!

Version details
Run the below code and add to issue (if an issue is relevant for the issue):

import sys
print(sys.version)
import sisl
print(sisl.__version__)

3.9.17 (main, Jul  5 2023, 20:41:20) 
[GCC 11.2.0]
0.0.0.dev+851d78c55d40d1f7aa1f5d8320aae1d3364064b8
@zerothi
Copy link
Owner

zerothi commented Sep 11, 2023

thanks for your report, could you share the folder with the content so I can debug it! :)

@zerothi
Copy link
Owner

zerothi commented Sep 11, 2023

I believe you are correct. I think I am missing a copy, hence the update happens in the same array.

@zerothi
Copy link
Owner

zerothi commented Sep 11, 2023

This will only affect spin-polarized calculations.

As for the 3, it is because the current way the matrices are built up is by having the density matrices in the first elements, and the last one (in this case 3) will be the overlap matrix.

@AsymmetryChou
Copy link
Author

thanks for your report, could you share the folder with the content so I can debug it! :)

OK! Which way do you prefer, by email or something else?

@AsymmetryChou
Copy link
Author

This will only affect spin-polarized calculations.

As for the 3, it is because the current way the matrices are built up is by having the density matrices in the first elements, and the last one (in this case 3) will be the overlap matrix.

Thanks! I get it!

@zerothi
Copy link
Owner

zerothi commented Sep 12, 2023

I am playing a bit now, perhaps I don't need it, lets wait and see. I'll ping you for more information, if needed! :) Thanks!

@AsymmetryChou
Copy link
Author

I am playing a bit now, perhaps I don't need it, lets wait and see. I'll ping you for more information, if needed! :) Thanks!

Ok, no problem!

zerothi added a commit that referenced this issue Sep 12, 2023
This happened because we were forgetting to do a copy of the
element matrix. This resulted in creating a view, but calculating
on the same array leaving the exact calculation wrong.
Essentially the old Mulliken was non-sense
 M[0] was M[0] + M[0] - M[1]

Signed-off-by: Nick Papior <[email protected]>
@zerothi
Copy link
Owner

zerothi commented Sep 12, 2023

Ok, I have now fixed the bug! thanks for discovering!

Could you please install the latest sisl development version, then you should have the fix! Let me know!

@AsymmetryChou
Copy link
Author

Ok, I have now fixed the bug! thanks for discovering!

Could you please install the latest sisl development version, then you should have the fix! Let me know!

Successfully running!!
I get the right total charge in Mulliken's analysis. Thanks!

@zerothi
Copy link
Owner

zerothi commented Sep 13, 2023

Thanks for returning! I'll close this issue then!

@zerothi zerothi closed this as completed Sep 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants