My Community

Hi Admin,

i am using LAECHG =.TRUE. tag for writing Bader files. i used to get proper output earlier for many systems. but i fond recently the AECCAR0 is written all NAN for charges.
attaching the .tar file of input files. Kindly see if this a bug or something wrong with input?
Regards

Please also upload your INCAR and final POTCAR file.

hi
i have given INCAR and the POTCAR header file already in my original question itself.
Do you need anything more, please?

Ok, strangely when I open the file with the previewer on linux mint there is no INCAR file, but now I extracted the file manually on the terminal and the file suddenly appeared.

I've run your calculation with your input files and see no problems.
I used VASP 6.2 as downloaded from the portal. I used gfortran 9.3 with open mpi.
I ran on 32 cores.

Can you please write the specs of your calculation:
VASP version
Compiler
Number of nodes

I meant number of cores

Hi
thanks for the reply.
anyway to give more clarity to you, i did another test on similar system with two different jobscript tags.
one run is success and the other not in writing proper AECCAR0 file.

Kindly see the attached .tar file. Same input files but only difference in VASP version etc. tags gave this success and non-success.

Regards

Hi Admin
Kindly look into this.
it seems a version issue, as my works are now with only 5.4.4 version.
Not sure if i need to change version, i need to repeat all calculations.
Regards

I've been running some calculations with LAECHG = .TRUE. in hopes of doing some charge analysis. However, in some cases the values printed to AECCAR0 are insanely high (in the range E+150 - E+250) and other times it's NaN. I'm not sure what is causing this, and have not been able to find any answers so far elsewhere. What would be the reasons that this could happen?

I'm running with PREC = Accurate and ADDGRID = .TRUE.

Hello!

Please post more information about your problem, in particular zip together your output files. Have a look at the posting guidlines:

Provide a report in form of a zip-file in the attachment of your post that contains:
* all input files of the job, that is POSCAR, INCAR, KPOINTS, POTCAR
* OUTCAR and stdout of the run
* your jobscript, if you use one

Without more information it is difficult or even impossible to provide any useful hints.. thank you!

Here's two examples of some reference runs on FeO and Fe2O3 that showcase high values and NaN-values respectively, as well as one example of FeO where the values are sensible. For the Fe2O3-case, the ENCUT is set quite high but changing this between runs have not led to any improvement. What seems to make a difference is adjusting the KSPACING-tag, although finding a consistent value for KSPACING to use across a series of runs so far hasn't been possible. See for example the difference between high_values_1.zip and high_values_2.zip where both are calculations of FeO where the only change is KSPACING = 0.2 in the case with high values and 0.1 where the values are more sensible.

My main hope is to better understand the origin of this behaviour to help me make better and consistent choices of input parameters so that I can obtain results are more reliable and more easily comparable.

Thank you very much for the information and files, we are looking into this...

Just for reference: there is a related topic (potentially the same issue): forum/viewtopic.php?f=3&t=18110

Thanks for providing the files! For reference, this seems to be related to: forum/viewtopic.php?f=4&t=18152 . There it also seems to occur with VASP 5.4.4, probably it's the same issue, we are looking into this...

Best,
Andreas

Dear all,

I merged the two topics because they describe the same error. I could reproduce the behavior for (almost) all of your example files in both VASP 5.4.4 and 6.2.1. It seems there is indeed a bug in the code which will be fixed until the next release. In the meantime there is a workaround which should allow you to get the desired AECCAR0 output:

In your INCAR files please remove or comment out the tag ADDGRID=.TRUE. and set the fine grid values manually according to the desired output:

For example:

@rasmusvt:
Change your INCAR to contain (High_values_? examples): or (Nan_values example) @SKM:
You already set the fine grid dimensions manually, so it should suffice to comment out: The AECCAR0 file is written rather at the beginning of the run, so you can actually stop the program when the main loop starts and combine the AECCAR0 with your previous results.

Hope this helps, please try it out and comment if it works for you.

All the best,

Andreas

Hi all,

it seems that also AECCAR1 is affected by this problem! While there are no NaNs or extreme values (10^150+) the data is not comparable to the result with the aforementioned workaround (ADDGRID=.FALSE. and manual NG?F setup). Quick tests indicated that only AECCAR2 matches with/without the workaround. Please check your data as well and in case you can confirm this use AECCAR1 also from the workaround runs.

Hi Admin,
i did take some time to dissect and investigate the issue, because i found that some times i got success and some times not with same INCAR file, rather same input files, i should say now, based on the final outcome of my investigation.

I converged the problem (in my case at least) is associated with the CPU allocation (and memory) for the system under study.

The details of investigation as below:

1. Same input for a system (say SYS1) two different jobscript files with different vasp versions (5.4.1 and 5.4.4), and different executable (like in one case vasp_gam and in another it was vasp_xy) ----> resulted one success and one fail.
2. i suspected with vasp version and the executable. So i did another run by changing only the executable same as that of failed run in the previously successful script. Result is success run. [ i did not have 5.4.1 now, so could not check] : Confirmed that its not the issue of executable.
3. Then i realized that in another system (say SYS2), i used almost similar jobscript file except few tags, was a failure, but was success in SYS1 above.
4. Then did few runs with increasing and decreasing CPUs and memory request tags....----> found that unless the CPUs are not enough for the system to run and with necessary memory (if memory is less the run stopped throwing an error). My system contain 120 atoms, 472 electrons (i.e. NELECT) was successful with NCPUs=96, Memory=50GB (checked very small value 10GB, then run stopped for short of memory), but did not run when NCPUs=48 and Memory is even 190GB.

So ultimately it is something to do with CPUs allocation and Memory, in my opinion.

May please investigate with your expertise, if my assessment is correct, and kindly suggest how can we assess the minimum resource allocations based on system under study.

Regards