[Wien] ghost band

[Stefaan Cottenier]

Do 'grep :DIS case.scf' to see how the charge distance evolves. Is is 
steadily decreasing or oscillating? Assuming the former, it looks like 
you do not have a real problem, but are using a (somewhat older?) wien 
version with the maximum number of iterations by default at 20. If after 
those 20 iterations your -fc 1 force criterium is not satisfied, you 
thet this message. In that case, just add -i 999 (a crazy high number of 
iterations). The risk is now of course that it will run 'forever' if it 
refuses to converge. Watch it closely...

Stefaan

>Dear Stefaan,
>
>Thank you very much for your prompt reply and advice.
>I have restarted the initialization from a scratch directory. The SCF 
>iteration stopped at cycle 9 after lapw1. Again, all the error files 
>were empty. The case.scf2 file shown message: QTL-B value EQ 5.59310 in 
>band of energy  -0.55906 atom = 12, L=1. The fermi level was 0.10020
>I tried to remove the broyden file, changed all global E-parameter from 
>-0.04 to -0.10, and changed E-parameter for atom 12, L=1 from 0.3 to 
>-0.5 in case.in1c file. The SCF iteration then was stopped at cycle 20 
>with the message "Forces not converged". The ghost band message still 
>exist but apparently, the value was reduced to 3.246 for atom 2.
>I tried to decrease the mixing factor in case.inm file from 0.01 to 
>0.005 and restarted the SCF iteration. But the same problem occurred, 
>where the iteration stop at cycle 20 with message "Forces not 
>converged". (The issued command was: run_lapw -p -fc 1 NI)
>I don't have experience to solve the scf converged problem. Any 
>suggestion? Should I ignore the ghost band message since the qtl value 
>was quite small?
>
>Thanks in advance
>
>Regards
>Yen Fun
>
>
>Stefaan Cottenier wrote:
>  
>
>>>, I don’t understand why LO is added in case.in1 file (in what case we 
>>>should add the LO), and how to define the energy for this LO. Can 
>>>anyone explain to me?
>>>    
>>>      
>>>
>>Most of the LO's are decided upon automatically, and this is fairly 
>>robust. What you probably refer to is adding extra LO's at high 
>>energies. This is needed when you are interested in the DOS of 
>>unoccupied states. This enhances precision, but is rarely necessary to 
>>get a case converged. I don't think your troubles are due to this.
>>
>>  
>>    
>>
>>>Currently I tried to run an interface LiTaO3/RuO2. Everything was fine 
>>>during initialization. When come to scf calculation, the dayfile 
>>>message shown: /INFO: K-LIST in CLMSUM changed in MIXER xxx /after 
>>>Lapw1,and QTL-B value shown after Lapw2.The calculation was then stop 
>>>with message “lapw2 crashed!” at cycle 2. In this case I used RmtKmax 
>>>5 with Kmesh 50. I understand that we can ignore the K-list message in 
>>>cycle 1. So I presume that the ghostband have caused the problem 
>>>(QTL-B value >5%). Thus, I tried to change all E-parameter from 0.3 Ry 
>>>to -0.04 Ry, which is 0.2 Ry below the Fermi Level and rerun the scf. 
>>>But it doesn’t help. The same error occurred again.
>>>    
>>>      
>>>
>>Re-initialize from scratch in a new, clean directory to make sure that 
>>this k-list message is really there. It could be a result of messing up 
>>something while playing with the initialization. If it still crashes 
>>after lapw2, look at the bottom of case.scf2 to see which state triggers 
>>the qtl-b problem. You will also see there to what value you have the 
>>change the linearization energy of that state.
>>
>>  
>>    
>>
>>>I tried to switch “in1new 5”, but this time the calculation even stop 
>>>at 1^st cycle. Then I tried to reduce the mixing factor from 0.1 to 
>>>0.01, with restart the dstart. The calculation then stopped at cycle 4 
>>>after LAPW1, with empty error file.
>>>    
>>>      
>>>
>>I assume you are making all these changes in the same directory? If you 
>>do not know exactly what you are doing, it's easy to mess things up. For 
>>such a big interface supercell, I would definitely start with a mixing 
>>value around 0.01. Try it, in a clean directory. If there is really no 
>>error message, look in case.dayfile and to your 'screen' output to find 
>>out why it stopped (queue problem?)
>>
>>  
>>    
>>
>>>Another thing I want to note here is I found that there is no core for 
>>>Lithium, where from case.scfc file, I noticed that the core for 
>>>Lithium is 0.0000Ry. I am not sure whether this is the cause for the 
>>>problem or not. Did anyone face the same problem before?
>>>    
>>>      
>>>
>>That is no problem. The 1s level of Li is at -3.8 Ry, the 2s is at -0.2 
>>Ry. With the default separation energy of -6 Ry, both fall in the 
>>valence region. There are no core states for Li.
>>
>>Stefaan
>>
>>
>>Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>>_______________________________________________
>>Wien mailing list
>>Wien at zeus.theochem.tuwien.ac.at
>>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>  
>>    
>>
>_______________________________________________
>Wien mailing list
>Wien at zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>  
>


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm