[QE-users] problem with hq.x

José Carlos Conesa Cegarra jcconesa at icp.csic.es
Tue Aug 4 17:53:23 CEST 2020


Dear Timrov,

Thanks for the clarification. I thought that it was enough specifying 
Hubbard_U(*) and putting the atom types involved in first place.  And 
it's true, the Warning message mentions ATOMIC_POSITIONS - I should have 
paid better attention to it. The reference to forrtl file 0 did 
completely upset me.

And yes, I want to put U also on the N atom. With the said composition, 
Cu would be in (+4) redox state, which is nearly impossible; it is 
likely that there will be holes in some of the N atoms. I know of some 
other cases in which U values are assigned to the N atom, even if it is 
seemingly of nitride type.

Thanks again,

José C. Conesa


El 04/08/2020 a las 17:24, Timrov Iurii escribió:
>
> Dear José,
>
>
> The code is called "hp.x" and not "hq.x" - there is a mistake in the 
> title.
>
>
> > WARNING! All Hubbard atoms must be listed first in the
> > ATOMIC_POSITIONS card of PWscf
>
>
> This message explains what is the problem.
>
>
> In your case you put Hubbard U on Cu and N (do you really want to put 
> U on N?), so all Cu and N atoms must be listed first in the 
> ATOMIC_POSITIONScard.
>
>
> HTH
>
>
> Cheers,
>
> Iurii
>
>
> --
> Dr. Iurii Timrov
> Postdoctoral Researcher
> STI - IMX - THEOSand NCCR - MARVEL
> Swiss Federal Institute of Technology Lausanne (EPFL)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
> http://people.epfl.ch/265334
> ------------------------------------------------------------------------
> *From:* users <users-bounces at lists.quantum-espresso.org> on behalf of 
> José Carlos Conesa Cegarra <jcconesa at icp.csic.es>
> *Sent:* Tuesday, August 4, 2020 5:02:06 PM
> *To:* users at lists.quantum-espresso.org
> *Subject:* [QE-users] problem with hq.x
> Dear colleagues,
>
> I have found a problem when running hp.x after a pw.x calculation on a
> nitride. The input to pw.x was the following:
>
> ....................
>
> &CONTROL
>     title = 'calc CuGeSnN4'
>     calculation = 'scf'
>     restart_mode = 'from_scratch'
>     prefix = 'CuGeSnN4'
>     outdir = './tmp'
>     etot_conv_thr = 1.0D-5
>     pseudo_dir = '..'
> /
>
> &SYSTEM
>     space_group = 47
>     A=4.3628, B=4.1528, C=4.3120
>     nat= 7, ntyp= 4
>     ecutwfc = 50.0
>     nspin = 2
>     occupations ='smearing'
>     degauss= 0.003
>     starting_magnetization(1)=1
>     lda_plus_u = .TRUE.
>     Hubbard_U(1)=0.01
>     Hubbard_U(2)=0.01
> /
>
> &ELECTRONS
>      diagonalization='david'
>      electron_maxstep = 100
>      mixing_mode = 'plain'
>      mixing_beta = 0.7
>      conv_thr =  1.0d-8
> /
>
> ATOMIC_SPECIES
>    Cu  63.5    Cu_pbe_v1.2.uspp.F.UPF
>     N  14.0    N.pbe.theos.UPF
>    Ge  72.6    Ge.pbe-dn-kjpaw_psl.1.0.0.UPF
>    Sn 118.7    Sn_pbe_v1.uspp.F.UPF
>
> ATOMIC_POSITIONS crystal_sg
> Ge       0.50000    0.50000    0.00000
> Cu       0.50000    0.00000    0.50000
> Sn       0.00000    0.50000    0.50000
> N        0.50000    0.50000    0.50000
> N        0.50000    0.00000    0.00000
> N        0.00000    0.50000    0.00000
> N        0.00000    0.00000    0.50000
>
> K_POINTS  automatic
>
>     6  6  6   0 0 0
> ....................
>
> The run proceeded seemingly smoothly. Then I undertook a hp.x
> calculation using the following input:
>
> ....................
>
> &INPUTHP
>    prefix = 'CuGeSnN4'
>    outdir = './tmp'
>    iverbosity = 2
>    nq1 = 4, nq2 = 4, nq3 = 4
> /
> ....................
>
> and found the following result in stderr:
>
> forrtl: Operation not permitted   (repeated as many times as cores were
> used)
>
> and
>
> forrtl: severe (28): CLOSE error, unit 0, file "Unknown"
> followed by several references on errors in hp.x (all these lines
> repeated as well as many times as cores were used)
>
> The output of hp.x just contained at the end this line:
>
>   WARNING! All Hubbard atoms must be listed first in the
> ATOMIC_POSITIONS card of PWscf
>
> But since this was the case I do not think that this may be the cause of
> the problem.
>
> I have been told that unit 0 is stderr; but how can this be, since these
> lines appeared in the stderr output itself? I have been using qe-6.5
> (for both pw.x and hp.x) and the SLURM queuing system
>
> Please give advice.
>
> Regards,
>
> -- 
> José C. Conesa
> Research Professor
> Instituto de Catálisis y Petroleoquímica, CSIC
> Marie Curie, 2; Campus de Cantoblanco
> 28028 Madrid (Spain)
> Telef. +34 915854766
>
> _______________________________________________
> Quantum ESPRESSO is supported by MaX 
> (www.max-centre.eu/quantum-espresso 
> <http://www.max-centre.eu/quantum-espresso>)
> users mailing list users at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>
> _______________________________________________
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users

-- 
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20200804/8f314fb6/attachment.html>


More information about the users mailing list