[QE-users] QE calculation stops abruptly at 'CG style diagonalization'

2020-02-21 Thread Shivesh Sivakumar
Hello all,

I am trying to run an scf calculation for calculating charge density for my
system (~450 carbon atoms, a massive graphene sheet). But the calculation
always stops at the same point 'CG style diagonalization..' or 'starting
wfcs are randomized' if I used david style diagonalization.I have tried
tweaking parameters but to no avail. I suspect it is not a memory problem
since I have tried running the calculation on high memory cluster. Any help
would be much appreciated.

Best,
Shivesh Sivakumar


OUTPUT
Description: Binary data


INPUT
Description: Binary data
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Missing Hubbard atoms from ATOMIC_POSITIONS card

2020-02-21 Thread Hooman Yaghoobnejad Asl
The two U terms applied to the two crystallographically distinct Mn atoms
(opposite spin arrangement). Still, I'm expecting to get similar values for
both as they are in chemically identical environments, similar to the NiO
reference.
Thanks,
Hooman

On Fri, Feb 21, 2020 at 2:29 PM Manu Hegde  wrote:

> looks like you are applying U twice for Mn atom. what's the difference
> between Mn1 and Mn2 site?. different symmetry?. you may have to think
> about it.
>
> Manu
>
> On Fri, Feb 21, 2020 at 2:45 PM Hooman Yaghoobnejad Asl 
> wrote:
>
>> Dear all,
>> The following must be an easy fix. I just started to use hp.x for LiMnO2
>> (hypothetical structure), which is a magnetic (AFM) insulator. I followed
>> the example02 of the HP code (NiO U parameter) and it worked as expected. I
>> do the same sequence for the above structure (i.e., magnetic metal,
>> magnetic insulator, linear response), but at the last step, hp.x stops with
>> the following error:
>> " WARNING! All Hubbard atoms must be listed first in the
>> ATOMIC_POSITIONS card of PWscf
>>  Stopping..."
>> Any hint to show me what I'm doing wrong is highly appreciated.
>> I'm using QE 6.4.1
>> Input for the second step (magnetic insulator) is pasted below:
>>
>>  
>> ibrav = 0
>> celldm(1) = 10.52955401,
>> nat   = 16
>> ntyp  = 4
>> nbnd  = 72
>>  ecutwfc = 50 ,
>>  ecutrho = 400 ,
>>  occupations = 'fixed' ,
>>  nspin = 2 ,
>> tot_magnetization = 0.00
>> lda_plus_u = .true.,
>> lda_plus_u_kind = 0,
>> U_projection_type = 'ortho-atomic',
>> Hubbard_U(2) = 1.d-8
>> Hubbard_U(3) = 1.d-8
>>  /
>>  
>> electron_maxstep = 500,
>> conv_thr =  1.d-15
>> mixing_beta = 0.7 ,
>> startingpot = 'file'
>> startingwfc = 'file'
>>  /
>> ATOMIC_SPECIES
>> O   15.99 O.pbe-n-kjpaw_psl.0.1.upf
>> Mn1 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
>> Mn2 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
>> Li   6.94100  Li.pbe-s-kjpaw_psl.0.2.1.upf
>> ATOMIC_POSITIONS {crystal}
>> O0.138178100   0.392913471   0.233700489
>> O0.361767139   0.106848852   0.766122199
>> Mn1  0.0   0.0   0.0
>> Li   0.250095079   0.250498471   0.500248603
>> O0.138177233   0.892913211   0.233699914
>> O0.361766394   0.606847636   0.766121721
>> Mn2 -0.0   0.5  -0.0
>> Li   0.250092166   0.750492217   0.500245834
>> O0.638233606   0.393152364   0.233878279
>> O0.861822767   0.107087789   0.766300086
>> Mn2  0.5   0.0   0.0
>> Li   0.749907834   0.249508783   0.499754166
>> O0.638233861   0.893152148   0.233877801
>> O0.861822900   0.607086529   0.766299511
>> Mn1  0.5   0.5   0.0
>> Li   0.749905921   0.749501529   0.499751397
>> CELL_PARAMETERS (alat)
>>0.994008748   0.006054947   0.149445159
>>   -0.494775805   0.989385379  -0.097973510
>>0.114248343  -0.030106079   0.902638553
>> K_POINTS automatic
>> 4 4 5   0 0 0
>>
>> --
>>
>> *Hooman Yaghoobnejad *
>>
>> *PhD, Department of Chemistry *
>>
>> *Missouri University of Science and Technology *
>>
>> *Rolla, MO 65409 *
>> *USA*
>>
>

-- 

*Hooman Yaghoobnejad*

*PhD, Department of Chemistry*

*Missouri University of Science and Technology*

*Rolla, MO 65409*
*USA*
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Missing Hubbard atoms from ATOMIC_POSITIONS card

2020-02-21 Thread Manu Hegde
looks like you are applying U twice for Mn atom. what's the difference
between Mn1 and Mn2 site?. different symmetry?. you may have to think
about it.

Manu

On Fri, Feb 21, 2020 at 2:45 PM Hooman Yaghoobnejad Asl 
wrote:

> Dear all,
> The following must be an easy fix. I just started to use hp.x for LiMnO2
> (hypothetical structure), which is a magnetic (AFM) insulator. I followed
> the example02 of the HP code (NiO U parameter) and it worked as expected. I
> do the same sequence for the above structure (i.e., magnetic metal,
> magnetic insulator, linear response), but at the last step, hp.x stops with
> the following error:
> " WARNING! All Hubbard atoms must be listed first in the
> ATOMIC_POSITIONS card of PWscf
>  Stopping..."
> Any hint to show me what I'm doing wrong is highly appreciated.
> I'm using QE 6.4.1
> Input for the second step (magnetic insulator) is pasted below:
>
>  
> ibrav = 0
> celldm(1) = 10.52955401,
> nat   = 16
> ntyp  = 4
> nbnd  = 72
>  ecutwfc = 50 ,
>  ecutrho = 400 ,
>  occupations = 'fixed' ,
>  nspin = 2 ,
> tot_magnetization = 0.00
> lda_plus_u = .true.,
> lda_plus_u_kind = 0,
> U_projection_type = 'ortho-atomic',
> Hubbard_U(2) = 1.d-8
> Hubbard_U(3) = 1.d-8
>  /
>  
> electron_maxstep = 500,
> conv_thr =  1.d-15
> mixing_beta = 0.7 ,
> startingpot = 'file'
> startingwfc = 'file'
>  /
> ATOMIC_SPECIES
> O   15.99 O.pbe-n-kjpaw_psl.0.1.upf
> Mn1 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
> Mn2 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
> Li   6.94100  Li.pbe-s-kjpaw_psl.0.2.1.upf
> ATOMIC_POSITIONS {crystal}
> O0.138178100   0.392913471   0.233700489
> O0.361767139   0.106848852   0.766122199
> Mn1  0.0   0.0   0.0
> Li   0.250095079   0.250498471   0.500248603
> O0.138177233   0.892913211   0.233699914
> O0.361766394   0.606847636   0.766121721
> Mn2 -0.0   0.5  -0.0
> Li   0.250092166   0.750492217   0.500245834
> O0.638233606   0.393152364   0.233878279
> O0.861822767   0.107087789   0.766300086
> Mn2  0.5   0.0   0.0
> Li   0.749907834   0.249508783   0.499754166
> O0.638233861   0.893152148   0.233877801
> O0.861822900   0.607086529   0.766299511
> Mn1  0.5   0.5   0.0
> Li   0.749905921   0.749501529   0.499751397
> CELL_PARAMETERS (alat)
>0.994008748   0.006054947   0.149445159
>   -0.494775805   0.989385379  -0.097973510
>0.114248343  -0.030106079   0.902638553
> K_POINTS automatic
> 4 4 5   0 0 0
>
> --
>
> *Hooman Yaghoobnejad *
>
> *PhD, Department of Chemistry *
>
> *Missouri University of Science and Technology *
>
> *Rolla, MO 65409 *
> *USA*
>
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Missing Hubbard atoms from ATOMIC_POSITIONS card

2020-02-21 Thread Hooman Yaghoobnejad Asl
Dear all,
The following must be an easy fix. I just started to use hp.x for LiMnO2
(hypothetical structure), which is a magnetic (AFM) insulator. I followed
the example02 of the HP code (NiO U parameter) and it worked as expected. I
do the same sequence for the above structure (i.e., magnetic metal,
magnetic insulator, linear response), but at the last step, hp.x stops with
the following error:
" WARNING! All Hubbard atoms must be listed first in the
ATOMIC_POSITIONS card of PWscf
 Stopping..."
Any hint to show me what I'm doing wrong is highly appreciated.
I'm using QE 6.4.1
Input for the second step (magnetic insulator) is pasted below:

 
ibrav = 0
celldm(1) = 10.52955401,
nat   = 16
ntyp  = 4
nbnd  = 72
 ecutwfc = 50 ,
 ecutrho = 400 ,
 occupations = 'fixed' ,
 nspin = 2 ,
tot_magnetization = 0.00
lda_plus_u = .true.,
lda_plus_u_kind = 0,
U_projection_type = 'ortho-atomic',
Hubbard_U(2) = 1.d-8
Hubbard_U(3) = 1.d-8
 /
 
electron_maxstep = 500,
conv_thr =  1.d-15
mixing_beta = 0.7 ,
startingpot = 'file'
startingwfc = 'file'
 /
ATOMIC_SPECIES
O   15.99 O.pbe-n-kjpaw_psl.0.1.upf
Mn1 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
Mn2 54.93805  Mn.pbe-spn-kjpaw_psl.0.3.1.UPF
Li   6.94100  Li.pbe-s-kjpaw_psl.0.2.1.upf
ATOMIC_POSITIONS {crystal}
O0.138178100   0.392913471   0.233700489
O0.361767139   0.106848852   0.766122199
Mn1  0.0   0.0   0.0
Li   0.250095079   0.250498471   0.500248603
O0.138177233   0.892913211   0.233699914
O0.361766394   0.606847636   0.766121721
Mn2 -0.0   0.5  -0.0
Li   0.250092166   0.750492217   0.500245834
O0.638233606   0.393152364   0.233878279
O0.861822767   0.107087789   0.766300086
Mn2  0.5   0.0   0.0
Li   0.749907834   0.249508783   0.499754166
O0.638233861   0.893152148   0.233877801
O0.861822900   0.607086529   0.766299511
Mn1  0.5   0.5   0.0
Li   0.749905921   0.749501529   0.499751397
CELL_PARAMETERS (alat)
   0.994008748   0.006054947   0.149445159
  -0.494775805   0.989385379  -0.097973510
   0.114248343  -0.030106079   0.902638553
K_POINTS automatic
4 4 5   0 0 0

-- 

*Hooman Yaghoobnejad*

*PhD, Department of Chemistry*

*Missouri University of Science and Technology*

*Rolla, MO 65409*
*USA*
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] use of blas from amd-optimized libflame 2.1 causes test failures in epw tests

2020-02-21 Thread Tobias Kloeffel

Another note, there seem to be problems using FFTW interface of MKL

export MKL_DEBUG_CPU_TYPE=5

with  AMD cpus. To get around this problem, one hast to additionally set

export MKL_CBWR=AUTO

Kind regards,
Tobias


On 2/3/20 8:46 AM, Tobias Kloeffel wrote:
Recently I played around with some AMD EPYC cpus and the bad thing is 
that I also saw some strange numbers when using libflame/aocl 2.1.


The 'workaround' is probably to just use Intel's MKL. Since version 
2020 the MKL performs rather well when using AMD cpus, however, if you 
want to get the best performance you have to additionally set:


export MKL_DEBUG_CPU_TYPE=5

which gives an additional 10-20% speedup with MKL 2020, while for 
earlier versions the speedup is greater than 200%


Kind regards,
Tobias

On 2/2/20 10:57 PM, Paolo Giannozzi wrote:
On Sun, Feb 2, 2020 at 10:23 PM Evgeny Permyakov > wrote:


sidenote: I had to set  **orte_execute_quiet = true** in
~/.openmpi/mca-params.conf so mpi didn't mess with extra messages


thank you for  this useful piece of information: I got rid of those 
annoying messages


I don't use epw in my work and pwscf tests work just fine, but
the fact that some tests failed bother me. Should I investigate
it further and how? I'm not versed in QE code, I'm a humble user.

investigating further would be a good thing, but it is not easy: one 
has to figure out which piece of code fails, then why. Even if one 
succeeds, very often the problem is in the library itself and  there 
is nothing that can be done.


Frequent offenders are complex-valued routines (e.g. zdotc) that seem 
to follow two different incompatible conventions, but the symptom is 
a hard crash, not a wrong number.


Paolo
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing listus...@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users



--
M.Sc. Tobias Klöffel
===
HPC (High Performance Computing) group
Erlangen Regional Computing Center(RRZE)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 1
91058 Erlangen

Room: 1.133
Phone: +49 (0) 9131 / 85 - 20101

===

E-mail:tobias.kloef...@fau.de

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users



--
M.Sc. Tobias Klöffel
===
HPC (High Performance Computing) group
Erlangen Regional Computing Center(RRZE)
Friedrich-Alexander-Universität Erlangen-Nürnberg
Martensstr. 1
91058 Erlangen

Room: 1.133
Phone: +49 (0) 9131 / 85 - 20101

===

E-mail: tobias.kloef...@fau.de

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] forcing cubic symmetry for a slab

2020-02-21 Thread José Carlos Conesa Cegarra

Dear Julien,

A slab can never be cubic. At most it can be forced to remain 
tetragonal. But I see that your perovskite contains formamidinium 
cations. Even if you force the dimensions of the bulk cell to remain 
cubic, the internal symmetry after relaxation will not be cubic; those 
organic cations lack threefold symmetry, which is the condition for a 
structure to be cubic by symmetry. This said, a correct arrangement of 
the formamidinium ions might allow having tetragonal symmetry, both in 
the bulk and in the slab.


José C. Conesa

El 21/02/2020 a las 13:13, Julien Barbaud escribió:


Dear users,


I am trying to simulate the surface of a perovskite. If I let vc-relax 
do its job on my system, it ends up yielding  a monoclinic unit cell. 
However, the phase of interest for my purposes has a cubic symmetry 
(actually becomes stable only at at higher temperatures). When it 
comes to bulk calculations, this is no problem, because we can easily 
constrain the system to a cubic symmetry and let it relax (constrained 
vc-relax, or Birch fit method). And I do get very good agreement with 
experimental lattice constants.


When I try to simulate a slab of a few atomic layers, however, the 
vacuum thickness left in the unit cell allows for one more degree of 
freedom for the slab. This results in my atomic slab "tilting" during 
the relax calculation, effectively mimicking the monoclinic result 
(without the actual fictitious "slab cell" changing, of course). I am 
afraid this description might not be clear, so I attached an 
illustration of the problem I get after a relax run on an initially 
cubic slab.


My question boils down to this:*Is there a good method force a slab to 
remain cubic, even though it has this additional freedom?*


This sounds like a basic question, but I couldn't find an answer so 
far. I thought of limiting the relaxation the the z-axis only, but I 
believe that would not be satisfying for the physics of my system 
(mostly because my material is made of organic cations encaged in an 
inorganic framework, and the orientation/rotation of those cations 
usually are relevant. If I don't allow any movement in the x-y 
directions, I won't be able to observe potential re-orientation of the 
cations at the surface)


Let me know if you need any more information!


Thanks for your attention,

Julien


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@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
Tel. 915854766
Madrid, Spain

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] speed up the phonon calculation of large cells

2020-02-21 Thread sha.liu

Dear experts and developers,

I am calculating the phonon DOS of several large cells (30~90 atoms per 
unit cell). I found the calculation took too much time and if there is 
anything wrong, I need to wait at least I got some results. Could you 
give me some advice on how to speed up the calculation? Also, I found 
for most cases, the phonon calculation can not reach the convergence. 
One of my scf input and ph input is like this:



title = 'Mg2Zn11',
prefix = 'Mg2Zn11',
calculation = 'vc-relax',
restart_mode = 'from_scratch',
pseudo_dir = '../',
outdir = './tmp',
forc_conv_thr = 1d-5,
nstep = 300,
/

ecutwfc = 80.0,
ibrav = 1,
celldm(1) = 16.1581354,
nat = 39,
ntyp = 2,
occupations = 'smearing',
smearing = 'gaussian',
degauss = 0.011,
use_all_frac = .true.
/

/

/

/
ATOMIC_SPECIES
 Mg  24.305  Mg.pbe-spnl-rrkjus_psl.1.0.0.UPF
 Zn  65.409  Zn.pbe-dnl-rrkjus_psl.1.0.0.UPF

ATOMIC_POSITIONS crystal
  Mg0.302470  0.00  0.50
  Mg0.50  0.302470  0.00
  Mg0.00  0.50  0.302470
  Mg0.50  0.697530  0.00
  Mg0.00  0.50  0.697530
  Mg0.697530  0.00  0.50
  Zn0.50  0.50  0.50
  Zn0.229963  0.00  0.00
  Zn0.00  0.229963  0.00
  Zn0.00  0.00  0.229963
  Zn0.00  0.770037  0.00
  Zn0.00  0.00  0.770037
  Zn0.770037  0.00  0.00
  Zn0.159837  0.50  0.00
  Zn0.00  0.159837  0.50
  Zn0.50  0.00  0.159837
  Zn0.00  0.840163  0.50
  Zn0.50  0.00  0.840163
  Zn0.840163  0.50  0.00
  Zn0.218205  0.218205  0.218205
  Zn0.781795  0.781795  0.218205
  Zn0.218205  0.781795  0.781795
  Zn0.218205  0.781795  0.781795
  Zn0.781795  0.218205  0.781795
  Zn0.781795  0.781795  0.781795
  Zn0.218205  0.218205  0.781795
  Zn0.781795  0.218205  0.218205
  Zn0.218205  0.781795  0.218205
  Zn0.50  0.235252  0.341765
  Zn0.341765  0.50  0.235252
  Zn0.235252  0.341765  0.50
  Zn0.764748  0.658235  0.50
  Zn0.341765  0.50  0.764748
  Zn0.764748  0.341765  0.50
  Zn0.658235  0.50  0.235252
  Zn0.658235  0.50  0.764748
  Zn0.235252  0.658235  0.50
  Zn0.50  0.764748  0.658235
  Zn0.50  0.235252  0.658235
  Zn0.50  0.764748  0.341765

K_POINTS automatic
  8 8 8 1 1 1



  tr2_ph=1.0d-16,
  prefix='Mg2Zn11',
  amass(1)= 24.305,
  amass(1)= 65.409,
  outdir='./tmp',
  fildyn='Mg2Zn11.dyn',
  ldisp=.true.,
  nq1=4, nq2=4, nq3=4,
 /


Regards,
Sha Liu
IMDEA Materials Institute
C/Eric Kandel 2, Getafe 28906-Madrid, Spain


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


Re: [QE-users] More Questions About SCF "Atom Charges"

2020-02-21 Thread Paolo Giannozzi
On Thu, Feb 20, 2020 at 4:03 PM Victor Bermudez 
wrote:

 My question is this: How can the NO2 "charge" decrease from 7.8 to
> <1.0
>

Have you tried to do a SCF calculation for a snapshot with small charges?
If you do not get the same (or at least, very similar) numbers, there is
something not right. Atomic "charges" are not used in any calculations to
the best of my knowledge, so a bug may go unnoticed.

Paolo
-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users