Error while performing DFT+U calculations on FeO
Describe the bug
When calculating DFT+U for FeO, the calculation is incorrect when the k-point density is slightly larger。
Expected behavior
No response
To Reproduce
No response
Environment
No response
Additional Context
No response
Task list for Issue attackers (only for developers)
- [ ] Verify the issue is not a duplicate.
- [ ] Describe the bug.
- [ ] Steps to reproduce.
- [ ] Expected behavior.
- [ ] Error message.
- [ ] Environment details.
- [ ] Additional context.
- [ ] Assign a priority level (low, medium, high, urgent).
- [ ] Assign the issue to a team member.
- [ ] Label the issue with relevant tags.
- [ ] Identify possible related issues.
- [ ] Create a unit test or automated test to reproduce the bug (if applicable).
- [X] Fix the bug.
- [ ] Test the fix.
- [ ] Update documentation (if necessary).
- [ ] Close the issue and inform the reporter (if applicable).
Thanks for your report, can you upload your input files?
Set uramping 0.5 will get correct bandgap, you will see a increasing bandgap curve in SCF calculation:
------------------------------------------------------
Energy Rydberg eV
------------------------------------------------------
E_bandgap 0.0000277916 0.0003781246
E_bandgap 0.0000400355 0.0005447110
E_bandgap 0.0001210641 0.0016471621
E_bandgap 0.0000831820 0.0011317487
E_bandgap 0.0001351464 0.0018387618
E_bandgap 0.0000873010 0.0011877909
E_bandgap 0.0000483869 0.0006583377
E_bandgap 0.0000702388 0.0009556477
E_bandgap 0.0002124803 0.0028909429
E_bandgap 0.0001420357 0.0019324948
E_bandgap 0.0000410001 0.0005578353
E_bandgap 0.0001580042 0.0021497576
E_bandgap 0.0003137059 0.0042681876
E_bandgap 0.0058235562 0.0792335472
E_bandgap 0.0206244153 0.2806095659
E_bandgap 0.0352565269 0.4796896576
E_bandgap 0.0579382700 0.7882906049
E_bandgap 0.0668592768 0.9096671282
E_bandgap 0.0672814058 0.9154104880
E_bandgap 0.0776505389 1.0564897817
E_bandgap 0.1029670977 1.4009392355
E_bandgap 0.1025543748 1.3953238526
E_bandgap 0.1026821734 1.3970626410
E_bandgap 0.1110515606 1.5109339962
E_bandgap 0.1341241462 1.8248526282
E_bandgap 0.1336153500 1.8179301003
E_bandgap 0.1352249377 1.8398296650
E_bandgap 0.1414632697 1.9247065261
E_bandgap 0.1595030580 2.1701504367
E_bandgap 0.1596140032 2.1716599240
E_bandgap 0.1605181973 2.1839621156
E_bandgap 0.1618843831 2.2025500272
E_bandgap 0.1645047282 2.2382016513
E_bandgap 0.1664677312 2.2649096769
E_bandgap 0.1663291243 2.2630238345
E_bandgap 0.1658992910 2.2571756518
E_bandgap 0.1658240135 2.2561514487
E_bandgap 0.1656869293 2.2542863221
E_bandgap 0.1656742560 2.2541138929
E_bandgap 0.1656584099 2.2538982956
E_bandgap 0.1656617467 2.2539436952
E_bandgap 0.1656601457 2.2539219131
I have run FeO with symmetry=1 and 0. And for symmetry=0, the band gap is 0 eV, while symemtry=1, the band gap is about 1.7 eV(U=4eV).
@maki49 do you have any idea about the reason why symmetry will affect band gap in this case ?
I did the following tests:
symmetry=1but comment out the charge density symmetrization: E_bandgap=1.9 eVsymmetry=1,init_chg=filereading charge density andonsite.dmfromsymmetry=0: E_bandgap=1.7 eVsymmetry=1,init_chg=filereading charge density andonsite.dmfromsymmetry=0, and comment out the charge density symmetrization: E_bandgap=1.9 eV
So there seems nothing to do with charge density, all the difference results from reducing k-points. Maybe there's some bug with DFT+U when there are too many k-points?
symmetry =1 will lead to a rotation of occupation matrix (onsite.dm) with symmetry = 0 or -1, which should be rotate back when symmetry =1.
To solve this problem, I'll ask for your help @maki49 later.
Any progress for standard systems like FeO?