Page 1 of 1

About the atomic partitioning volume

Posted: Tue Apr 25, 2023 5:21 am
by zhangguangping
Dear Baders,

I have now analyzed the atomic magnetic moment by Bader (version 1.04) analysis for VASP calculations. According to the website of Bader, I produce the core charge for the investigated system and get the CHGCAR_sum for the reference by

chgsum.pl AECCAR0 AECCAR2

Also, I have the spin density file CHGCAR_spin (CHGCAR_spin = CHGCAR_up - CHGCAR_down).

Then, I use the following command to obtain the magnetic moment for each atom.

bader CHGCAR_spin -ref CHGCAR_sum

As far as I understand, the atomic volume partitioning is obtained for this system by only analyzing the CHGCAR_sum. And then, use this atomic volume partitioning for the integral of the spin density (CHGCAR_spin) to get the atomic magnetic moment . Because, in my opinion, partitioning the atomic volume by using CHGCAR_spin makes no sense since the spin density can not correctly define the atomic volume.

However, when I use the same CHGCAR_sum file for the same system and change the CHGCAR_spin file to another similar quantity for this system, I find the atomic volume in ACF.dat is very different indicating that the atomic volume partitioning is highly relevant to the CHGCAR_spin file.

So, my question is
(1) Does the the atomic volume partitioning depend on the CHGCAR_spin file in Bader (version 1.04)?
(2) How can I do an analysis in which the atomic volume partitioning is only determined by the reference CHGCAR_sum file?
(3) If I shift the data in CHGCAR_spin with respect to the atomic structure in CHGCAR_spin and still use the CHGCAR_sum for reference, will the atomic volume in ACF.dat change?

Thanks very much.
/Guang-Ping Zhang

Re: About the atomic partitioning volume

Posted: Tue Apr 25, 2023 1:00 pm
by graeme
The way that you have described how you are determining atomic spins looks correct to me.

The atomic volumes should only depend upon the CHGCAR_sum file and not the CHGCAR_spin. Maybe double check the test where you found this was not the case. If you are pretty sure of your result, I would like to take a look at the example. If you are willing to post the charge density files, I will try to reproduce the issue and see what is going on.

Re: About the atomic partitioning volume

Posted: Wed Apr 26, 2023 1:35 am
by zhangguangping
graeme wrote:
> The way that you have described how you are determining atomic spins looks
> correct to me.
>
> The atomic volumes should only depend upon the CHGCAR_sum file and not the
> CHGCAR_spin. Maybe double check the test where you found this was not the
> case. If you are pretty sure of your result, I would like to take a look
> at the example. If you are willing to post the charge density files, I
> will try to reproduce the issue and see what is going on.
Dear Graeme,

Thanks very much for your kind and quick reply. Yes, as you said and as I understand before, the atomic volumes only depend upon the CHGCAR_sum file and not the CHGCAR_spin. This applies to the cases where both the origin of the volumetric data and the atomic positions keep the same for CHGCAR_spin and CHGCAR_sum.

However, in my case, I shift only the position of the origin of the volumetric data but not the atomic positions (or shift rigidly only the atomic positions but not the volumetric data) in CHGCAR_spin while CHGCAR_sum is not changed at all. In this case, the printing atomic volume is totally different and wrong.

I have now resolved this problem by following procedure. If I want to shift rigidly the atomic positions but not the volumetric data in CHGCAR_spin, then I must apply the same rigid shift to both the atomic positions and volumetric data in CHGCAR_sum. By this, the atomic volumes are correct, and also this can reach my requirement.

With best regards,
/Guang-Ping Zhang

Re: About the atomic partitioning volume

Posted: Wed Apr 26, 2023 1:51 am
by graeme
Ah, yes, I see what you mean! Ok, I have no idea what the code will do if the atoms in the CHGCAR being analyzed and the reference are different - I just never considered that as a possibility. Ideally our code should flag that as an error and not allow it, but again, I just didn't think about that as a possibility.

Anyway, great that this is resolved.