[QE-users] problem with hq.x

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


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



More information about the users mailing list