I recently tried to calculate the vibrational entropy of BCC Au. After I optimized the structure (no inflection detection needed), I used
fitfc -ernn=4.0 -ns=1 -ms=0.02 -dr=0.1 -nrr
and for each folder I did
runstruct_vasp -lu -w vaspf.wrap srun
with KPPRA=8000 in vaspf.wrap. Then I did
fitfc -f -frnn=1.5 -kp=8000 -dr=0.1 -fu
and I had a lot of unstable modes in unstable.out. I picked the one numbered as 7 and did a “-gu”
fitfc -f -frnn=1.5 -kp=8000 -dr=0.1 -gu=7
to generate the unstable mode in folder “p_uns_0.1_8000_7”. I did another single point calculation in the folder with
runstruct_vasp -lu -w vaspf.wrap srun
and after the calculation,
fitfc -f -frnn=1.5 -kp=8000 -dr=0.1 -fu
I can see the calculation result of mode 7 is taken into account, with output like:
Reading…
vol_0
p+0.1_9.82073_0
p+0.1_9.82073_1
p+0.1_9.82073_2
p_uns_0.1_8000_7
Generating Fitting matrices
1/480
121/480
241/480
361/480
Performing least square fit…
Problem size= 480 x 78
Done
Creating Force constants…
Done
Performing normal modes calculations
kmesh= 20 20 20
Now I still have the mode 7 in the “unstable.out", which means the -fu and -gu process did not eliminate the unstable mode in this case. Did I make anything wrong? What can I do here?
It could be that, given the current range of force constants, it is not possible to reconcile all the observed forces. You could
try to increase the range -frnn=… a bit, as long as grep svsl vol_0/fc.out does not output unphysical values of the force constants.
try to include another unstable mode in the fit (-fu and then -gu=…) (can be combined with 1)
restart from scratch using an even bigger supercell.
look at the dos (need to include -fn to force it) and perhaps the instability is very small so that it can be ignored. (-fn will just ignore the unstable modes a re-scale the weight of the other modes).
Yes, but it’s not a magic fix. If there are very few unstable modes and they are likley just numerical glitches, it gives reasonable answer. But, say, if you have 5% or 10% of modes that are unstable, that would not be a good fix.
Hello, I also have same problem. Some of my structures are unstable, so I tried the method mentioned above. It did generate some new structures from the unstable.out file, but some of them are still unstable.
So I’m wondering — what’s the aim of this process? Is the goal just to remove the unstable ones and add back some stable ones so we can get a correct vibrational entropy result?
If that’s the case, can I just delete the unstable ones directly? Like in my case:
(materialsframework-orb) [gzk@iap01 sqs_lev=0_a_Ni=1,b_Ni=1]$ fitfc -si=str_relax.out -f -frnn=1.5
Reading…
vol_0
p+0.2_9.91476_0
Warning: p+0.2_9.91476_0 is an unstable mode.
p_uns_0.2_1000_1
p_uns_0.2_1000_2
Warning: p_uns_0.2_1000_2 is an unstable mode.
p_uns_0.2_1000_3
Generating Fitting matrices
1/765
226/765
406/765
586/765
Performing least square fit…
Problem size= 765 x 5
Done
Creating Force constants…
Done
Performing normal modes calculations
kmesh= 6 6 6
Unstable modes found.
Aborting.
Then I need to delete the unstable structure: p+0.2_9.91476_0 and p_uns_0.2_1000_2 ? And after that I need run robustrelax_vasp -vib?
The message “Warning: p_uns_0.2_1000_2 is an unstable mode.” confirms that the mode that was predicted to be unstable is actually unstable based on the direct ab initio calculation.
Typically this means that the ground state of that structure is a symmetry-broken version of your input structure.
Knowing this, you can search for it more systematically. I suggest that you run the code with specific simple kmesh (e.g. -kx=4 -ky=4 -kz=4 -s0). Then, when you use -fu or -gu=… the supercell will not be too large. You may have to try different values of -kx=… etc.
ALTERNATIVE: it could be that the symmetry breaking is very small and you don’t want to bother. Then you could just run your existing command, adding -fn and check if most of the modes are stable. The code will just ignore the unstable modes and re-scale the stable ones to give a reasonable estimate of the free energy. If there are too many unstable modes, then the first option is unavoidable.