My Community

Hi,

I am studying a mineral in particular and I am investigating the D3, and two other functionals which use the IVDW = 11 tag. For all of these functionals when I use VASPKIT to look at the elastic constants I get wild numbers and it says its mechanically unstable. For the three other functionals which I use with no IVDW = 11, it gains decent numbers and says the structure is stable. I am now trying optPBE and DF_cx to see if its a vdw corrections issue or if its an actual IVDW = 11 issue

I am now also retrying with ISYM = 0, but I was wondering if there could be a reason this could be the case? If further information is required I am happy to provide it

Many thanks,
Jess

Hi Jess,

Thanks for posting on the VASP forum, I'm happy to assist you. However, it is difficult to say what causes your calculation to produce these wild numbers without further data. Could you please provide the relevant input and output files according to the forum posting guidelines?

Hi Manuel,

Thank you for offering to help! So I have my POSCAR, INCAR and also the elastic.dat which was the elastic properties which VASPKIT gave me. In the INCAR I am currently re-running with ISYM = 0 to see if that will work. However, the output I have here with the elastic.dat was from before I resubmitted with ISYM = 0.

Thank you!

There are a few things I can already comment on based on the input files you provided.

1. The ISPIN tag appears multiple times in the INCAR file. This usually means that only the first occurrence of the tag counts. Make sure that you are actually running a spin-polarized calculation if this is what you want. You can check the actual input that VASP reads in the OUTCAR file. Search for a section starting with "Startparameter for this run".
2. Depending on your system, LREAL=auto might not be accurate enough. You could try LREAL=False.
3. Try running without ADDGRID. This setting can sometimes yield strange results. For details, consult the corresponding page on the VASP wiki.

Maybe these comments can already help resolve your issue. In case it still persists, I encourage you to send me new input files and also the corresponding output (OUTCAR) files if possible.

Good luck!

Thanks Manuel! I have resubmitted with your suggestions so fingers crossed it will work

Just an update - for one it worked for the other two it did not. However, I am going to resubmit as I think it may be me not deleting WAVECARs etc before I submitted those two. So I am cautiously optimistic! Will know in 24 hours.

Hi Manuel,

Although results are getting better for PBE now the C44 is very off. It should be around 32 and it is instead -32. The RP-D3 gained very bad results (all like 3000 for the c11, c22 etc) so I am trying ISYM = 0 for that one as well as the D3.

Let me know how it goes. In the meantime, I will have a look at the data you uploaded.

So I resubmitted RP_D3 and D3 and as it was ISYM = 0 it took a very long time (sorry about that). D3 is still running but RP_D3 has just finished and its still the same as when ISYM wasn't 0. The values are extremely large in the 1000s where I am expecting 200 at most for C11 I think it is. Were you able to work out the issue with PBE?

Thanks,
Jess

I'm sorry to hear that you still do not get the desired results. I have examined your files and I could not really find any glaring mistake. However, the default EDIFF tag is probably not strict enough for these kinds of calculations (finite differences). I suggest you try setting it to something like 1e-6 or 1e-7.

Regarding the long runtime, there are a few performance settings you can try to accelerate your calculations (I don't know your hardware, so do your own testing). Unfortunately, NCORE is not yet supported for finite-difference calculations. You may also try switching to ALGO=Fast to speed up the calculation.

(sorry about that)

No worries, I have all the time in the world.

Sadly D3 also same crazy values I am going to try EDIFF to 1e-7 and I will turn off the ISYM = 0 (although for D3 I think it wants me to do ISYM = 0 but we will see)
I will also change it to ALGO = Fast. If I do that though, for consistency should I redo the others with ALGO = fast?

Thanks again for your help and patience!

RP_D3 has finished with higher EDIFF and ALGO Fast and still same results with crazy large elastic constants. Hmmm is it because there is Fe in the system that it causes crazy results? I am wondering if worth to increase ENCUT even more as well? I may try that
D3 with higher EDIFF still running but should be finished soon

At this points, I'm a bit out of my depth. I will consult with my colleagues and get back to you as soon as possible.

Thanks Manuel! Sorry about this. I appreciate all the effort you are doing in helping me! I have my fingerscrossed that someone will have some answers

Hi Manuel,

I was just popping in and was wondering if there are any updates?

Many thanks,
Jess