[Pw_forum] LDA+U problem on Mac

[Mulazzi Mattia]

Dear Gabriele,

>>> 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
>> automatic generation of the k-points and I have to supply to the
>> input file a list of k-points covering the whole non-irreducible
>> Brillouin 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.

I am trying a calculation with nosym=.true. and the automatic k-point  
generation. I will then use project_wf.x to actually get the atomic-  
and orbitally-projected density of the states as a function of energy.  
That would be a good way to check the orbital order in my system.

>>> 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,...

Briefly, there are errors on something called 'iotk', not much more  
info. I am soon posting new info about it.

>> 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.

I did not need to modify the set_hubbard_l.f90 file to have the LDA+U  
running, but just the tab_d.f90.

> 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 checked and there is also a segmentation fault when I use the MnS2  
system, and for it also when I do a calculation with one Mn atom per  
cell there is a segmentation fault. On the other hand a calculation  
with two Mn atoms, Mn1 and Mn2, does not give a segmentation fault. So  
the problem is not in the atomic pseudopotential naming.

>> 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.

I did a test after changing from V.pbe-n-van.UPF to V1.pbe-n-van.UPF,  
but I still have the segmentation fault.

> HTH
>
> GS
> 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...
At first I thought about a compiler bug (as suggested in the QE  
troubleshooting pages), but it is quite unlikely it is the case. Why  
should the compiler be buggy only with a one atom per cell system.

Mattia

FPR Fellow of RIKEN at Spring8
Excitation Order Research Team
1-1-1 Sayo-cho Sayo-gun, Hyogo
Japan