[Pw_forum] LDA+U problem on Mac

[Gabriele Sclauzero]

Dear Mattia,

Quoting Mulazzi Mattia <mulazzi at spring8.or.jp>:

> Dear Gabriele,
>
> thank you for the prompt reply. Here are my comments:
>
>> I don't understand a thing: starting_ns_eigenvalue is used only on   
>> the species on which
>> you put +U (i.e. Hubbard_U(?)>0), so if you cannot not use LDA+U   
>> for V with your QE
>> installation, how could you say that using starting_ns_eigenvalue   
>> does not change the
>> result?
>
> I thought that the starting_ns_eigenvalue function might have worked  
>  also without the LDA+U being set to true.

This is not the case.

> So I tried, but the result  was the same as doing a calculation  
> without setting the occupations.

If lda_plus_u=.FALSE., then this is the case. Even if you enable  
LDA+U, it is not granted that changing starting_ns_eigenvalue will do  
anything. This feature  is needed to gently push the calculation to  
the LDA+U ground state when it is very distant to the plain LDA one.  
However, it is not granted that the LDA+U ground state will correspond  
to the atomic orbitals occupations that you have in mind.

>
>> One other important point is that occupations are symmetrized   
>> according to the symmetry >of the system. So that, perhaps,   
>> retrying after breaking some symmetry or using >nosym=.TRUE. may   
>> change something.
>
> I will try to use nosym=.true., but then, I guess, I cannot use the   
> automatice generation of the k-points and I have to supply to the   
> input file a list of k-points covering the whole non-irreducible   
> Brilluoin zone. Am I right?

I think that you can still use the automatic generation of k-points.  
Simply they will not be reduced by symmetry and the calculation will  
be longer. Anyway, you may not actually need to use nosym, if the  
supercell with two V types has already low enough symmetry to break  
the degeneracy of states that you want to occupy with different weights.

>
>> Which version of QE are you using? Please check if the Vanadium   
>> case has already been >inserted in tabd.f90 and set_hubbard_l.f90   
>> files.
>> If not pw.x should stop with an error message like "pseudopotential  
>>  not yet inserted"
>> before causing any segmentation fault. From version 4.1 on, LDA+U   
>> should be working >with any of the transition metal elements. If   
>> you have previous versions, you can >easily get it working   
>> modifying those two files.
>
> I am using the 4.0.5 version of QE. I tried to use the 4.1.1 (since   
> it now suports the LDA+U for all the transition metals as well as   
> for the rare earths), but it does not compile on  my Mac, even using  
>  the same configuration parameters that I used for the compilation  
> of  the 4.0.5 version. So for now, I gave up.

Why does it not compile? The two versions are not much different. Try  
to address this issue (in a separate thread), maybe other Mac users  
have this problem. I will try ASAP to compile on Mac. You need also to  
specify which compiler, which libraries, error messages,...

> About the LDA+U, I did more testing on it both on my PC (using   
> cygwin under WinXP) and on the Mac. The cygwin compilation   
> recognises without problems the V pseudopotential included in the QE  
>  library. The same calculations done on the Mac require first a  
> small  modification of the tabd.f90 file.

Not only! As I said also set_hubbard_l.f90 needs to be modified  
accordingly. For the moment, you can take those two files from 4.1.1  
and put in 4.0.5 version (and recompile). They should work.


After doing that (and recompiling
> pw), no more "pseudopotential not yet inserted" message. However,   
> using on the Mac the same input file that I use on the PC gives the   
> bloody "segmentation fault". However, I found out that the   
> segmentation fault error only appears when I use one Vanadium atom   
> per unit cell and if I label it "V" in the ATOMIC_SPECIES name card.  
>  In this case just fixing lda_plus_u to true triggers the   
> segmentation fault, even if the Hubbard_U is on another atom.
> If I do a calculation in a larger cell with two Vanadium atoms   
> labelled V1 and V2 (pointing to the same pseudopotential file) then   
> I see no segmentation fault.


OK, I think that there was a problem with atomic labels made by one  
single character; it should be fixed in 4.1.x. Retry using V1 in place  
of V even if you have only one Vanadium type, it should work.

> If I use a fictitious alloy system (say MnV or FeV in a symple cubic  
>  cell with the V atom at the 0.5 0.5 0.5 position), then I see no   
> segmentation fault even if I label the Vanadium as "V". But if I   
> want to calculate my system, VS2, then I have the segmentation   
> fault. If I put a second V in the calculation and I use two labels   
> (again V1 and V2) then no problem.

This is strange. Anyway keep in mind that the problem shows up only if  
you put the +U on the single-character named species.

> I thought it was a problem of the xc functional, but it seems it   
> doesn't, using either PZ- or PBE-generated (ultrasoft)   
> pseudopotentials does not solve the problem. I tried to generate the  
>  norm-conserving pseudopotentials using the ld1.x program, but PW   
> does not recognise the pseudopotentials. I think that this last   
> problem is related to a naming problem that Dr. de Gironcoli was   
> explaining in the pw forum archives. I don't think it can be solved   
> without editind the code itself.

Yes it is not a problem of the PP. If you still have problems, after  
replacing those two files of above, or using V1 in place of V, please  
report it.


HTH

GS


>
> Did any other user report on such or similar "segmentation fault" problems?


PS: After all, I'm still a bit surprised that this problem I mentioned  
shows up as a segmentaion fault. Maybe it is something else...

>
>> Please report to us if the problem persists in v4.1 and if it is   
>> reproducible.
>
>> Thanks,
>
>> GS
>
> Thank you very much,
>
>    Mattia Mulazzi
>
> FPR Fellow of RIKEN at Spring8
> Excitation Order Research Team
> 1-1-1 Sayo-cho Sayo-gun, Hyogo
> Japan
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>



----------------------------------------------------------------
   SISSA Webmail https://webmail.sissa.it/
   Powered by Horde http://www.horde.org/