My Community

Dear VASP users,
I am attempting to optimize the excited state of a system using the FERWE and FERDO flags. I've noticed that when performing the calculation with multiple k-points, the geometry appears incorrect. However, when I optimize the supercell using only the gamma point, the geometry looks reasonable. Is this a common occurrence? Additionally, during the excited state frequency calculation with the supercell (again using FERWE and FERDO), I am getting unusually large imaginary frequencies. Has this type of frequency calculation been tested before?

Hi,

Not exactly sure what you are describing by "geometry appears incorrect". Could you please upload a minimal reproducible according to the forum guidelines?

Cheers,
Marie-Therese

Dear Marie-Therese,
I have found that occupation is not constrained in the vasp calculations as given in INCAR. I am using vasp 6.4.2.
Is there any mistake in input or bug in vasp?

Hi,

to my knowledge, FERWE and FERDO can only be used as an initialization (like MAGMOM) and not as a constraint. I guess you could use NELM=1 to simulate an ad hoc change of Fermi weights, but I don't have experience with that. I will ask around and get back to you.

Meanwhile, could you please attach the output and describe the goal of your calculation? Why do you want to constrain the occupations rather than determine them self-consistently? This is just for me to understand better what you aim for and find a way to make it happen in VASP.

Best regards,
Marie-Therese

Dear Marie-Therese,
I am trying to do an excited state calculation by manually constraining the occupation using ISMEAR = -2, as mentioned in the VASP manual. However, after completing the SCF cycle (where my configuration involves exciting an alpha electron from the valence band to the conduction band which is set by FERWE and FERDO flag), the final occupations shown in the OUTCAR or EIGENVAL files is as if no excitation has occurred. Could you please advise on how to address this issue?

Fear aijitha_john,

please excuse the delay in this reply.

In principle, your methodology should be sound. But I see some discrepancies in your provided INCAR and OUTCAR files:
FERWE in your INCAR starts with:

FERWE = 24.0*1.0 1*0.0 1*1.0 6.0*0.0 ...

while in your OUTCAR it is:

FERWE = 215.0*1.0 ...

Please make sure to upload input and output files from the same run, so we can help you properly.

As for the difference in results when using Γ-only compared to more k-points: Are you sure that you adapted your FERWE and FERDO tags to include all bands at all KPOINTS?

Michael

Dear michael_wolloch,

Sorry for the delay as I was on vacation.
Please see the attached incar and outcar with all k-points. My FERWE AND FERDO flags included all bands and K-points.
The occupancy of in the outcar file doesnot follow the FERDO AND FERWE flags.

Dear aijitha_john,

I am very and truly sorry. I did not notice that you had already replied ages ago and forgot to follow up on your question.

I did some tests today on a small reproducer and I think I figured out two problems with your calculation:

1.) concerning the FERWE and FERDO tags:

You used floats to specify the multiplicity of values, which is not parsed correctly. Please try again with Integers.
e.g.

FERWE = 24*1.0 0.0 1.0 6*0.0 ...

instead of

FERWE = 24.0*1.0 1*0.0 1*1.0 6.0*0.0 ...

E.g. 1.0*1.0 will be interpreted as 1.0 1.0, instead of just 1.0. 1*1.0 works, but I would still rather write 1.0 alone.

2.) Concerning the ISTART tag:

This is less important, since in my testing, if FERWE and FERDO are set correctly, the charges will be set accordingly, regardless if a WAVECAR is present and ISTART is set to 1. Nevertheless, I would recommend to not have a WAVECAR present if you want to set the occupations manually.

However, when they are not set correctly (e.g. with float multipliers) the occupations from the WAVECAR will be kept, instead of garbage ones. I think this is what happened in your calculation

Please let me know if switching to integer multiples helps. Let me also know if there are other issues with the calculation (you mentioned geometry initially), which are still unresolved.

Sorry again for the late reply,
Michael