[Pw_forum] LDA+U problem on Mac

Tue Nov 3 16:05:10 CET 2009

Hello to all,

I think that part of the problem in QE compilation on Mac (Snow  
Leopard 10.6 using gfortran-4.0 in serial) can be related to what  
enlightened by Giannozzi in his email of the Oct 25 suggesting this

***
in include/c_defs.h, there should be two lines (produced by "configure")
that look like
#define F77_FUNC(name,NAME) name ## _
#define F77_FUNC_(name,NAME) name ## _
***

Writing this two lines of c_defs.h solved the problem for me.

m.

On 3 Nov 2009, at 9:40, Gabriele Sclauzero wrote:

> 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/
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

*******************************************************
Marino Vetuschi Zuccolini
zucco at dipteris.unige.it
Researcher / Geochemist
Laboratory of Geochemistry

DIPartimento per lo studio della TErra e delle sue RISorse -  
Università  di Genova
Tel. ++39 010 3538136 Fax. ++39 010 352169
Corso Europa 26, 16132 - Genova - Italy