PARCHG writing error for LSEPB = T and LSEPK = T

[joel_eaves]

Dear VASP developers,

I have recently noticed what appears to be a writing error for partial charge density files (PARCHG) separated per-band (LSEPB=T) and per-kpoint (LSEPK=T). Alternatively, it might be a computation error that manifests in the printed files, perhaps a buffer overflow error, for example. I am not exactly sure, but I will explain the issue below.

The error is as follows: at seemingly random points within the files, asterisk (*) marks take the place of expected numerical values. I have attached the corresponding INCAR and OUTCAR files, as well as a screenshot of my terminal output where I have used 'grep' to extract the asterisk marks from the affected files. I attempted to attach an example PARCHG file, but it was too large. The screenshot contains all affected data points, so hopefully that is sufficient.

Overall, I ran a job that wrote 7 PARCHG files, and across these files, 19 errors occurred in total (see attached screenshot named PARCHG_pb_pk_error.png). Each PARCHG file contains about 500 million numerical values, so 19 errors is exceedingly rare. However, it was enough to cause issues for me while analyzing the results. Not all files were affected: 4 printed correctly, and 3 printed incorrectly. One comment I have is that these are spin-polarized calculations, restricted to a total triplet multiplicity (ISPIN=2, NUPDOWN=2). And furthermore, the asterisks only occur in the up - down densities. All up + down data points are correctly printed as numerical values. I'm not sure if this is relevant considering how rare the error is, but it is something I noticed.

Any help would be appreciated.

Many thanks,
Peyton Cline
Postdoctoral Researcher
Dr. Joel Eaves' Group
University of Colorado, Boulder

[joel_eaves]

Dear VASP developers,

I did some searching since writing my post, and it seems this issue has been brought up before, and reportedly fixed.

See: https://vasp.at/forum/viewtopic.php?f=3 ... ror#p18621

However, I do not recognize the piece of code discussed in the above in my version of VASP, which is 6.2.0. The above post was for a VASP.5.4.4.

Any help would be appreciated.

[martin.schlipf]

Thank you for digging up the old post that made debugging it much faster. I'm certain that the suggested fix would work in VASP 6.2.1 as well, but it was probably decided that it would make the file to big in general to implement that.

Anyhow, there are two ways you can achieve what the old patch did:
- In the subroutine write_pard in pardens.F, you can change the OUTCHG calls to .TRUE. (line 1132 and 1138)
- In the subroutine outchg in fileio.F, you can increase the width for the compact output (line 1076), e.g., G13.5.

[joel_eaves]

Dear Martin,

Thanks for the reply. I found the lines in my source code files and changed that flag from FALSE to TRUE in pardens.F. I just finished running some jobs, and it seems my PARCHG files are now being written correctly, with CHGCAR precision.

If I may make a suggestion - it seems the issue could be easily resolved in future VASP releases by changing the PARCHG formatting to reflect the CHGCAR formatting more closely, but at reduced precision to account for file size concerns. As the user rubel pointed out in the post I linked above, it seems the issue comes down to the current choice of G11.5 in fileio.F when LLONG = .FALSE., which breaks in certain rare instances like it did for me. I know you suggested G13.5 as a possible fix, but perhaps changing this to E11.5 instead might be more worthwhile. This would reflect the E17.11 formatting of the CHGCAR file more closely, but at reduced precision.

Additionally, if an entry about the pardens.F fix were added to the PARCHG documentation page in the meantime, that would certainly help others encountering similar issues, regardless if the problem is ever changed in the source code in future releases.

Cheers,
Peyton Cline

[martin.schlipf]

Thanks for your comments, I will bring it up in the next developer's meeting.

[martin.schlipf]

I have tried to reproduce this behavior to fix it, but could not find a case where this format actually fails. Could you tell me which compiler in which version you are using? If you have this data: do you know, which numbers are the ones that get replaced by ***?