unreasonable CHGCAR

[YCZhang-USTC]

I opened the standard CHGCAR file (obtained by VASP) with VESTA, and then exported it to test.cube in the *.cube format. But the new CHGCAR file converted from test.cube by your script didn't look like the original one. How to fix the problem?

[YCZhang-USTC]

I find the key point. The line

density[i, j, k] = density_data[i+j+k]

leads to the wrong result. The solution is to delete the above line, and change the definition of variable 'density' from

density = np.zeros((N[0], N[1], N[2]))

to

density = np.reshape(density_data, (N[0], N[1], N[2]), order='C')

[sgodse16]

Thanks for pointing out! I've made these changes in the main branch. Also added some slight changes which should make the code more efficient. Although I am not currently active in the area of DFT, feel free to open a pull request in the future, I'll try my best to contribute.

[YCZhang-USTC]

Thanks for your reply, and the new code works well! By the way, can CHGCAR obtained by this script be read by VASP? More specifically, I obtained a charge density data in cube format by a DFT package named ABACUS. Then I converted it to CHGCAR by your code, and wished that the CHGCAR can offer a good initial charge density for the SCF calculation in VASP. But I failed and got the warning: "WARNING: chargedensity file is incomplete". I double checked the CHGCAR file, it really looked the same as a true CHGCAR generated by VASP, except the following two points:

1. the lack of 'augmentation occupancies' information at the end of the file. In order to rule out this possibility, I manully delete the 'augmentation occupancies' in a true CHGCAR. This only leads to the warning: "WARNING: PAW occupancies are missing on CHGCAR". So this difference doesn't count for the 'incomplete' warning.
2. the number format of charge density. A true CHGCAR's number format is like "0.14227680807E+03", but I not sure if this difference leads to the 'incomplete' warning.

Thanks again for your code, and I will appreciate it if you give me some suggestions about the above question.

[sgodse16]

When I first wrote the code, I wanted CHGCAR files that a machine learning package I was using back then, could read electron density data. With the current code, we can get charge densities at the grid locations and can visualize the converted CHGCAR with softwares like VESTA. As you said, the augmentation occupancies (something which I don't clearly understand) are not present when we convert from cube to CHGCAR format. If this is not the main issue, I've added scientific notation to the script to address point #2. If this does not work either, can you look into the file encoding for VASP files? I'm afraid that's all I can think of. Do let me know if you're able to solve it.

[YCZhang-USTC]

Thanks a lot, the new version code solves the problem. In my latest test, the number format really leaded to different results. If numbers are in explict style, ‘incomplete’ warning will arise and VASP will stuck after charge initialization step; if numbers are in scientific style, "WARNING: PAW occupancies are missing on CHGCAR" will appear just as a true CHGCAR without paw occupation information，as our expected. However, such CHGCAR without paw occupation can't offer a helpful initial charge density for SCF, because VASP will generate initial charge density by default automatically rather than using offered 'sick' CHGCAR, and corresponding words "charge density of overlapping atoms calculated" can be found in OUTCAR. Without your help, I can hardly solve this problem. Best wishes!