Re: [QE-users] Incorrect identification+generations of atoms in specialpositions (space_group options used).

[José C . Conesa]

Thanks, Paolo. I will try whay you say. Still, a similar thing might 
happen with other structures... I will try to tweak the last decimal(s), 
if I see any problem.


El 12/11/2020 a las 17:50, Paolo Giannozzi escribió:
On Thu, Nov 12, 2020 at 1:34 PM José Carlos Conesa Cegarra 
mailto:jccon...@icp.csic.es>> wrote:


Last 11th of september I sent a similar question, but the answer,
provided by Paolo Giannozzi, did not clarify much. I can say that
in that occasion I was using qe-6.5. Should I use qe -6.6?


not necessarily so: the Wyckoff machinery is unchanged since two 
years, to the best of my knowledge. Instead you should have read my 
unclear answer again, or just the last sentence: /I suspect that one 
or more of the Ge positions are not exact Wyckoff positions but very 
close to them/, and verified it. There are just three Wyckoff Ge 
positions, and since atomic positions are expanded in the order they 
are provided, the problematic one seems to be the second:

  Ge   0.0   -0.49511   -0.50488
that looks almost like (0,-x,x). Almost. With 0.0 -0.49511 
-0.50489 you get 56 atoms. not 59.


Paolo
//

Regards,

    José C. Conesa

El 12/11/2020 a las 11:30, Pietro Delugas escribió:


Hi

 which version of the code are you using ?

with qe-6.6 using  your parameters I got two positions

  site n. atom  positions (alat units)

 1   Zn tau(   1) = (   0.4873906   2.5406690
1.4472625  )

 2   Zn tau(   2) = (   0.3343454   0.8468897
0.4736359  )

With alat = 11.5468  a.u.

alat = 11.5468  a.u.

ibrav=-12

hope it helps

greetings  - Pietro

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
for Windows 10

*From: *Michal Husak <mailto:michal.hu...@vscht.cz>
*Sent: *Thursday, November 12, 2020 10:34 AM
*To: *users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
*Subject: *[QE-users] Incorrect identification+generations of
atoms in specialpositions (space_group options used).

I


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu  
<http://www.max-centre.eu>)
users mailing listus...@lists.quantum-espresso.org  
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users  
<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

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




--
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)
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, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

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

Re: [QE-users] qe 6.5 seemingly cannot use libxc 5.0.0

[José C . Conesa]

Hi,

Certainly I was already using libxc 4.3.4 with qe-6.5; I just wanted to 
use the new libxc 5.0.0. And concerning developers version: I prefer to 
use stable ones.


Thanks anyway,

José Carlos

El 28/05/2020 a las 8:38, Kamel Demmouche escribió:

Hi josé,

libxc 4.3.4 works nicely with qe-6.5. Please  use the 
last developers version of QE available on GitLab since some minor 
corrections have been made for metagga.


Kamel


Am Mi., 27. Mai 2020 um 22:39 Uhr schrieb José C. Conesa 
mailto:jccon...@icp.csic.es>>:


Hi,

I tried using libxc v. 5.0.0 with qe-6.5 and was unable to do it.
Seemingly libxc 5.00 no longer contains the library libxcf03,
while funct.f90 requires the associated module xc_f03_lib_m.mod.
This should be solved in a new version of qe.

Best regards,

-- 
    José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+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@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

___
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] qe 6.5 seemingly cannot use libxc 5.0.0

[José C . Conesa]

Hi,

I tried using libxc v. 5.0.0 with qe-6.5 and was unable to do it. 
Seemingly libxc 5.00 no longer contains the library libxcf03, while 
funct.f90 requires the associated module xc_f03_lib_m.mod. This should 
be solved in a new version of qe.


Best regards,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

___
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] Ce19O32 cluster does not convergence

[José C . Conesa]

   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   1.   1.   1.   1.   1.   1.
  1.   1.   0.   0.   0.   0.   0.   0.


--
Best regards,
Dr. Andrey Chibisov, Ph.D.
Senior Researcher,
Laboratory of Numerical Methods in Mathematical Physics,
Computing Center of the Russian Academy of Sciences.
Khabarovsk, Russia
Web page: https://www.researchgate.net/profile/A_Chibisov
https://www.linkedin.com/in/andrey-chibisov-98625355/

___
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
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

___
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] Crystallographic group determination

[José C . Conesa]

Hi,

The primitive cell has always the same symmetry as the conventional one. 
You may specify all the atoms in the primitive cell, and give all cell 
dimensions and angles, as if the cell were of P1 symmetry; but the 
program will cleverly find out the correct space group.


JC Conesa

El 31/03/2019 a las 18:55, Ankit Sharma escribió:

Hi,
I am working with Gallium Oxide which has a 20 atom conventional cell 
with the space group of *C2/m *and a 10 atom primitive cell with space 
group of *P1 *(materials project): 
https://materialsproject.org/materials/mp-886/#.


When I run scf calculations on conventional cell the output clearly 
states as *C2/m *symmetry, but for the primitive cell too, the output 
is again *C2/m*.
I am unable to figure out the reason for it. Am I missing something? 
Any help in this regard will be greatly appreciated. Attached is the 
cif file from the materials project for reference for both the 
conventional and the primitive unit cells and the input and output 
files for the fake run to determine the symmetry.


Thank You,
Ankit Sharma
University at Buffalo

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] 答复: 答复: WEST CODE 3.0

[José C . Conesa]

Hi,

In any case, the most recent version of West seems to be 3.1.1. Maybe 
the problem does not appear with it. You might try.


JC Conesa


El 28/02/2019 a las 17:24, Zhou Jianqiang escribió:
I just have a quick look at the WEST manual, the GW on HES06 should be 
correctly implemented... Sorry for my previous fast reply.


Sky

/--/
/Jianqiang (Sky) ZHOU/
/European Theoretical Spectroscopy Facility
Institut des NanoSciences de Paris (INSP)
//


  Sorbonne Université - Case 840 - 4 place Jussieu

//
Barre 2232, étage 2, pièce 11
75005 PARIS
/
/http://etsf.polytechnique.fr/People/Sky 
<https://theory.polytechnique.fr/squirrelmail/src/compose.php?send_to=gaelle.bruant%40polytechnique.edu>/

/tel : +33 (0)1 69 33 44 85/

*发件人:* users  代表 Zhou 
Jianqiang 

*发送时间:* 2019年2月28日 15:54
*收件人:* Lucas Nicolás Lodeiro Moraga; Quantum Espresso users Forum
*主题:* [QE-users] 答复: WEST CODE 3.0
Hi Lucas,

Normally GW is done on top of KS-LDA. You want to do GW on top of 
hybrid functionals whose validity needs to be carefully checked, 
because of double counting in the two approximations. I am not aware 
of the WEST code maybe their GW implementation already takes into 
account the exchange included in different hybrid functionals like 
HSE06. If not this might explain the discrepancies in your benchmark.


Cheers,

Sky

/--/
/Jianqiang (Sky) ZHOU/
/European Theoretical Spectroscopy Facility
Institut des NanoSciences de Paris (INSP)
//


  Sorbonne Université - Case 840 - 4 place Jussieu

//
Barre 2232, étage 2, pièce 11
75005 PARIS
/
/http://etsf.polytechnique.fr/People/Sky 
<https://theory.polytechnique.fr/squirrelmail/src/compose.php?send_to=gaelle.bruant%40polytechnique.edu>/

/tel : +33 (0)1 69 33 44 85/

*发件人:* users  代表 Lucas 
Nicolás Lodeiro Moraga 

*发送时间:* 2019年2月28日 15:44
*收件人:* users@lists.quantum-espresso.org
*主题:* [QE-users] WEST CODE 3.0
Hello community.

I want to do a G0W0 calculation over HSE06 and PBE0 calculation, with 
WEST code (version 3.0), but I'm facing some difficulties and 
discrepancies.


After I have done a G0W0 over PBEsol and PBE calculation over the same 
structure (system) and the required time to complete the calculation 
it is around 24 hrs, but in hybrid case the time is absurdly greater. 
Is this normal?.
On the other hand, I have done a benchmark for an simple system, and i 
found discrepances in the quasi-particle energy (about 0.1 and 1.0 eV) 
between Gamma and GammaComplex (Kpoints = Gamma and Kpoints = 
Automatic 1 1 1 0 0 0 respectively).


I read the Govoni's papers, and send to him some doubts, but he did 
not answer to me, for that I ask here. There are somebody with 
experience in WEST code?

I need someone with whom I can talk about these issues and give feedback.

Regards!

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] CONTCAR to QE-input

[José C . Conesa]

Dear Naseem Hassan,

If you specify cell dimensions with celldm(*), the units are a.u., not 
angstroms, independently from the units (which probably should not be 
inserted in curly brackets) used in ATOMIC_POSITIONS. Note also that if 
you specify ATOMIC_POSITIONS crystal you do not need to convert the data 
from the CONTCAR coordinates. On the other hand, if you write ibrav=0 
the cell dimensions must be given with keyword CELL_PARAMETERS, not with 
celldm(*).


JC Conesa

El 16/02/2019 a las 14:53, Naseem Hassan escribió:


Dear All !

Would be grateful if somebody can help in converting VASP CONTCAR file 
to Quantum Espresso input file. I have already tried using ibrav=0 and 
ibrav=6 but getting error. I am attaching down below both CONTCAR and 
my attempted input file. Kindly point out mistake wherever possible


………

VASP input file

……..

Vasp-file

1.00

2.86569538771406580.000.0

0.002.86569539547028420.0

0.000.014.5687674940416922

**

533

Direct

0.1926926895120.193149041301 -0.0253111824898425

0.5715021387210.5713286225210.065890491135

0.0065858608850.0058345903120.1666816777950017

0.5455131319050.5442946049460.2674877725929466

0.1410205226400.1394580871780.3586520540557601

0.4490827039680.4438833411080.5110114048024905

0.0293864338170.0304123472710.640608352582

0.5077051087290.5137330718730.8222013593108685

-0.107135629075 -0.1109273906690.5146809763675351

0.49998455242556320.49998462204434150.859792830676

-0.061006705978 -0.0565162484970.8186883904105440

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

0.E+000.E+000.E+00

….

Quantum Espresso Input File

….



calculation='vc-relax'

title='zQ'

prefix='zQ'

verbosity='high'

restart_mode='from_scratch'

nstep=1000

iprint=1

tprnfor=.true.

outdir='./'

disk_io='default'

tstress=.true.

pseudo_dir = './'

wf_collect=.true.,

! forc_conv_thr=1.0d-4

! etot_conv_thr=1.0d-5

/



ibrav = 6,

celldm(1) = 3,

celldm(3)=5.2,

nat = 11,

ntyp = 3,

nspin= 2

ecutwfc = 50.0 ,

ecutrho = 250.0 ,

! input_DFT = 'PBE' ,

occupations = 'smearing' ,

degauss = 0.005 ,

smearing = 'methfessel-paxton' ,

starting_magnetization(1) = 0.1

vdw_corr='Grimme-D2'

lda_plus_u = .true.

Hubbard_U(1) = 3.0d0

/



electron_maxstep = 100,

! conv_thr = 1.0d-10 ,

mixing_mode = 'plain' ,

! mixing_beta = 0.3d0 ,

/



ion_dynamics='bfgs'

! upscale=100

/



! press_conv_thr = 0.5D0

! press = 0.D0

! cell_dynamics = 'bfgs',

! cell_dofree = '2Dxy'

! cell_factor = 1.5D0

/

ATOMIC_SPECIES

**.UPF

**.UPF

**.UPF

ATOMIC_POSITIONS{Angstrom}

**0.550.5514.200015

**1.4328681.4328680.959943

**0.000.002.428347

**1.4328611.4328603.896967

**0.400.405.225119

**1.4328331.4328327.444807

**0.080.099.712474

**1.4328501.43285211.978460

**-0.31-0.327.498268

**1.4328041.4328049.712793

**-0.17-0.1611.927280

K_POINTS automatic

5 5 1 0 0 0


Best Regards

Naseem



___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] on the use of tb09 functional from libxc

[José C . Conesa]

Dear QE developers,

I wish to use in Quantum Espresso the tb09 potential-only meta-GGA 
functional (from Tran & Blaha, PRL 102, 2009, 226401) which is available 
in libxc. I downloaded the libxc library and compiled successfully 
qe-6.2.1 with it. Then I see in Modules/funct.f90 that the instruction 
to use this functional is equivalent to specifying


input_dft="sla+pw+tb09+tb09"

But as far as I know, the tb09 functional gives only the exchange part, 
and gives it in full (not as a correction to another expression for the 
exchange), while sla is a LDA exchange form (and pw a LDA correlation 
form). Should one conclude that exchange is being introduced twice? And, 
is a gradient correction to the correlation term not included? From 
these considerations, I would have thought that using something like


input_dft="pw+pbc+tb09+tb09"

(where I hope that the tb09 exchange functional is not included twice), 
i.e. the correlation part of PBE plus the Tran & Blaha exchange 
functional, would be the proper way to proceed.


Can you please comment on this?

I also would add that it would be good to be able to adjust the A and B 
parameters of the tb09 functional. This has been proposed in (Koller, 
Tran & Blaha, PRB 85, 2012, 155109) to obtain better bandgaps in certain 
families of semiconductors.


All the best,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Metal-substituted semiconductor: treat as metal or insulator for phonons

[José C . Conesa]

Hi,

GGA is certainly inadequate to sytudy this system. My recommendation 
would be to carry out a hybrid functional calculation, e.g. with HSE. 
This cell has not too may atoms, it should be feasible. Use at least a 
4x4x4 Brillouin zone sampling. Displacing Fe from the symmetry position 
is of course necessary, then the structure should be relaxed. And a 
spin-polarized calculation will be necessary as well. I find likely that 
the system will have in the end a low spin configuration, with all 
Fe(3d) electrons filling the t(2g) manifold which would be well 
separated from the e(g) manifold, therefore having a clear nonmetallic 
behaviour.


Good luck,

JC Conesa


El 04/03/2018 a las 9:51, Pietro Delugas escribió:
If the band is flat or almost flat maybe one could try to use LDA+U, ( 
or some hybrid functional with exact exchange if the cell size is  
feasible ) displace Fe a little if it is in a  too symmetric position, 
relax and see if it is possible to split Fe impurity levels. If so one 
can  compute Fe Born Charges by finite differences.



Il 04 mar 2018 9:27 AM, Paolo Giannozzi <p.gianno...@gmail.com> ha 
scritto:


The problem is that the true system is not metallic, but in a band
picture it is, even for a supercell of 1m side. Maybe one might
compute phonons as for a metal, then use dielectirc constant and
effective charges of the insulating host crystal. Not sure what
one can use for the effective charges of Fe, though.

Paolo

On Sun, Mar 4, 2018 at 8:39 AM, Pietro Delugas <pdelu...@sissa.it
<mailto:pdelu...@sissa.it>> wrote:

Hello Chris

If the system is metallic, no matter how bad a conductor it
can be, in a finite time it will be able to screen any
constant electric field. This  is as to say that the static
dielectric constant is infinite.

Regards Pietro


Il 04 mar 2018 8:03 AM, Christoph Wolf
<wolf.christoph@qns.science> ha scritto:

Dear all,

I have a fairly general question and I hope I can pick
someone's brain:

If an insulator or semiconductor is doped with a metal
narrow bands determined by the crystal field emerge and
often the fermi level lies within one of the bands, i.e.
the "bands cut the fermi level", which is often called a
characteristic of a conductor but in the bigger picture no
electrons would be able to cross from the VB to the CB,
i.e. the host system is an insulator.

When attempting to calculate the phonons of a Mg7O8Fe
supercell the  dieletric constant (in the case of pure MgO
eps~3.1) cannot be computed

     Electric Fields Calculation
     ik   1 ibnd   0 linter: root not converged 2.635E-07

..

     End of electric fields calculation

          Dielectric constant in cartesian axis

(**  0.000244141      -0.001708984 )
          ( -0.000244141**      0.000244141 )
          ( -0.000732422  0.000732422** )

And I am wondering if that system should be treated as a
metal instead (epsil    = .false.,) during the phonon run?

--

  prefix   = 'MgO',
  epsil    = .true.,
  alpha_mix(1) =0.4
  alpha_mix(2) =0.4
  fildyn   = 'MgO.dyn',
  ldisp    = .true.
  fildvscf = 'dvscf'
  amass(1) = 24.30500
  amass(2) = 15.99900
  amass(3) = 55.84500
  outdir='./',
  nq1=6,
  nq2=6,
  nq3=6,
  tr2_ph   =  1.0d-12,
 /

Any hint is welcome!

Thanks in advance for your help and a nice Sunday everyone!

Chris
-- 
Postdoctoral Researcher

Center for Quantum Nanoscience, Institute for Basic Science
Ewha Womans University, Seoul, South Korea



___
users mailing list
users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>




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




___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)9

Re: [QE-users] Metal-substituted semiconductor: treat as metal or insulator for phonons

[José C . Conesa]

Hi,

GGA is certainly inadequate to sytudy this system. My recommendation 
would be to carry out a hybrid functional calculation, e.g. with HSE. 
This cell has not too may atoms, it should be feasible. Use at least a 
4x4x4 Brillouin zone sampling. Displacing Fe from the symmetry position 
is of course necessary, then the structure should be relaxed. And a 
spin-polarized calculation will be necessary as well. I find likely that 
the system will have in the end a low spin configuration, with all 
Fe(3d) electrons filling the t(2g) manifold which would be well 
separated from the e(g) manifold, therefore having a clear nonmetallic 
behaviour.


Good luck,

JC Conesa


El 04/03/2018 a las 9:51, Pietro Delugas escribió:
If the band is flat or almost flat maybe one could try to use LDA+U, ( 
or some hybrid functional with exact exchange if the cell size is  
feasible ) displace Fe a little if it is in a  too symmetric position, 
relax and see if it is possible to split Fe impurity levels. If so one 
can  compute Fe Born Charges by finite differences.



Il 04 mar 2018 9:27 AM, Paolo Giannozzi <p.gianno...@gmail.com> ha 
scritto:


The problem is that the true system is not metallic, but in a band
picture it is, even for a supercell of 1m side. Maybe one might
compute phonons as for a metal, then use dielectirc constant and
effective charges of the insulating host crystal. Not sure what
one can use for the effective charges of Fe, though.

Paolo

On Sun, Mar 4, 2018 at 8:39 AM, Pietro Delugas <pdelu...@sissa.it
<mailto:pdelu...@sissa.it>> wrote:

Hello Chris

If the system is metallic, no matter how bad a conductor it
can be, in a finite time it will be able to screen any
constant electric field. This  is as to say that the static
dielectric constant is infinite.

Regards Pietro


Il 04 mar 2018 8:03 AM, Christoph Wolf
<wolf.christoph@qns.science> ha scritto:

Dear all,

I have a fairly general question and I hope I can pick
someone's brain:

If an insulator or semiconductor is doped with a metal
narrow bands determined by the crystal field emerge and
often the fermi level lies within one of the bands, i.e.
the "bands cut the fermi level", which is often called a
characteristic of a conductor but in the bigger picture no
electrons would be able to cross from the VB to the CB,
i.e. the host system is an insulator.

When attempting to calculate the phonons of a Mg7O8Fe
supercell the  dieletric constant (in the case of pure MgO
eps~3.1) cannot be computed

     Electric Fields Calculation
     ik   1 ibnd   0 linter: root not converged 2.635E-07

..

     End of electric fields calculation

          Dielectric constant in cartesian axis

(**  0.000244141      -0.001708984 )
          ( -0.000244141**      0.000244141 )
          ( -0.000732422  0.000732422** )

And I am wondering if that system should be treated as a
metal instead (epsil    = .false.,) during the phonon run?

--

  prefix   = 'MgO',
  epsil    = .true.,
  alpha_mix(1) =0.4
  alpha_mix(2) =0.4
  fildyn   = 'MgO.dyn',
  ldisp    = .true.
  fildvscf = 'dvscf'
  amass(1) = 24.30500
  amass(2) = 15.99900
  amass(3) = 55.84500
  outdir='./',
  nq1=6,
  nq2=6,
  nq3=6,
  tr2_ph   =  1.0d-12,
 /

Any hint is welcome!

Thanks in advance for your help and a nice Sunday everyone!

Chris
-- 
Postdoctoral Researcher

Center for Quantum Nanoscience, Institute for Basic Science
Ewha Womans University, Seoul, South Korea



___
users mailing list
users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>




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




___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)9

Re: [Pw_forum] bug: cosAC does not work with (centered) monoclinic groups using unique b axis

[José C. Conesa]

Hi,

Now it runs OK. Thanks!

JC


El 26/01/2018 a las 20:53, Paolo Giannozzi escribió:

"patch -p1 < file"

On Fri, Jan 26, 2018 at 8:08 PM, José C. Conesa <jccon...@icp.csic.es 
<mailto:jccon...@icp.csic.es>> wrote:


It does not work. I get this error:

diff: unrecognized option '--git'

JC

El 26/01/2018 a las 19:34, Paolo Giannozzi escribió:

Please try this patch:
diff --git a/Modules/latgen.f90 b/Modules/latgen.f90
index 39a12f81a..6d00f060a 100644
--- a/Modules/latgen.f90
+++ b/Modules/latgen.f90
@@ -571,7 +571,7 @@ SUBROUTINE abc2celldm ( ibrav,
a,b,c,cosab,cosac,cosbc, celldm )
  celldm(5) = cosac
  celldm(6) = cosab
  !
-  ELSE IF ( ibrav ==-12 ) THEN
+  ELSE IF ( ibrav ==-12 .OR. ibrav ==-13 ) THEN
  !
  ! ... monoclinic P lattice, unique axis b
  !
P.

On Fri, Jan 26, 2018 at 6:51 PM, José C. Conesa
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:

Hi,

Using qe-6.2.1 I was puzzled by some pw.x results obtained
when using an input file containing these lines:



 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    cosAC=-0.70644
...

until I realized that the corresponding output contained
these lines:

 celldm(1)= 27.041981  celldm(2)=   0.442928 celldm(3)=  
0.712753
 celldm(4)=   0.00 celldm(5)=   0.00  celldm(6)=
0.00

That is, the monoclinic angle was not taken into account.
Giving the angle parameter with cosAB or cos BC changed
nothing. I only could obtain the correct resullts using an
input file with these lines:

.
 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    celldm(5)=-0.70644

.

Then I get in output, as expected:

 celldm(1)= 27.041981  celldm(2)=   0.442928 celldm(3)=  
0.712753
 celldm(4)=   0.00 celldm(5)=  -0.706440  celldm(6)=
0.00

If I change the unit cell definition so that the unique axis
is c, and use ibrav=13 (with the default uniqueb=.false.)
then cosAB is read correctly. Not reading cosAC when
ibrav=-13 is obviously a bug that should be corrected. I did
not verify (yet) if the same problem occurs with ibrav=-12,
but I suspect it may occur also. If some problem occurs also
for other negative ibrav values, I do not know.

By the way, when explaining the different ibrav values the
manual should include a mention (now absent) to the
possibility of having ibrav=-13, and when explaining both
ibrav=-12 and ibrav=-13 it should be said, at that same
place, that one must add uniqueb=.true. (although actually
specifying uniqueb should not be necessary, it might be
adopted automatically by the program when these two negative
ibrav values are detected).

    Regards,

-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel.(+34)915854766 <tel:+34%20915%2085%2047%2066>



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Libre de virus. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>



<#m_-3663623957443490427_m_-6946635839658223488_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>




-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,

Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216 <tel:+39%200432%20558216>, fax
+39-0432-558222 <tel:+39%200432%20558222>



___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>


-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel.(+34)915854766 <tel:+34%20915%2085%2047%2066>


___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>

Re: [Pw_forum] bug: cosAC does not work with (centered) monoclinic groups using unique b axis

[José C. Conesa]

It does not work. I get this error:

diff: unrecognized option '--git'

JC
El 26/01/2018 a las 19:34, Paolo Giannozzi escribió:

Please try this patch:
diff --git a/Modules/latgen.f90 b/Modules/latgen.f90
index 39a12f81a..6d00f060a 100644
--- a/Modules/latgen.f90
+++ b/Modules/latgen.f90
@@ -571,7 +571,7 @@ SUBROUTINE abc2celldm ( ibrav, 
a,b,c,cosab,cosac,cosbc, celldm )

  celldm(5) = cosac
  celldm(6) = cosab
  !
-  ELSE IF ( ibrav ==-12 ) THEN
+  ELSE IF ( ibrav ==-12 .OR. ibrav ==-13 ) THEN
  !
  ! ... monoclinic P lattice, unique axis b
  !
P.

On Fri, Jan 26, 2018 at 6:51 PM, José C. Conesa <jccon...@icp.csic.es 
<mailto:jccon...@icp.csic.es>> wrote:


Hi,

Using qe-6.2.1 I was puzzled by some pw.x results obtained when
using an input file containing these lines:



 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    cosAC=-0.70644
...

until I realized that the corresponding output contained these lines:

celldm(1)=  27.041981  celldm(2)=   0.442928 celldm(3)=   0.712753
 celldm(4)=   0.00  celldm(5)=   0.00 celldm(6)=  
0.00

That is, the monoclinic angle was not taken into account. Giving
the angle parameter with cosAB or cos BC changed nothing. I only
could obtain the correct resullts using an input file with these
lines:

.
 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    celldm(5)=-0.70644

.

Then I get in output, as expected:

celldm(1)=  27.041981  celldm(2)=   0.442928 celldm(3)=   0.712753
 celldm(4)=   0.00  celldm(5)=  -0.706440 celldm(6)=  
0.00

If I change the unit cell definition so that the unique axis is c,
and use ibrav=13 (with the default uniqueb=.false.) then cosAB is
read correctly. Not reading cosAC when ibrav=-13 is obviously a
bug that should be corrected. I did not verify (yet) if the same
problem occurs with ibrav=-12, but I suspect it may occur also. If
some problem occurs also for other negative ibrav values, I do not
know.

By the way, when explaining the different ibrav values the manual
should include a mention (now absent) to the possibility of having
ibrav=-13, and when explaining both ibrav=-12 and ibrav=-13 it
should be said, at that same place, that one must add
uniqueb=.true. (although actually specifying uniqueb should not be
necessary, it might be adopted automatically by the program when
these two negative ibrav values are detected).

Regards,

-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel.(+34)915854766 <tel:+34%20915%2085%2047%2066>



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Libre de virus. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>


<#m_-6946635839658223488_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>




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



___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] bug: cosAC does not work with (centered) monoclinic groups using unique b axis

[José C. Conesa]

Hi,

Using qe-6.2.1 I was puzzled by some pw.x results obtained when using an 
input file containing these lines:




 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    cosAC=-0.70644
...

until I realized that the corresponding output contained these lines:

 celldm(1)= 27.041981  celldm(2)=   0.442928  celldm(3)=   0.712753
 celldm(4)=   0.00  celldm(5)=   0.00  celldm(6)= 0.00

That is, the monoclinic angle was not taken into account. Giving the 
angle parameter with cosAB or cos BC changed nothing. I only could 
obtain the correct resullts using an input file with these lines:


.
 
    ibrav=-13,uniqueb=.true.
    space_group=12
    A=14.3100,B=6.3383,C=10.1995
    celldm(5)=-0.70644

.

Then I get in output, as expected:

 celldm(1)=  27.041981  celldm(2)= 0.442928  celldm(3)=   0.712753
 celldm(4)=   0.00  celldm(5)=  -0.706440 celldm(6)=   0.00

If I change the unit cell definition so that the unique axis is c, and 
use ibrav=13 (with the default uniqueb=.false.) then cosAB is read 
correctly. Not reading cosAC when ibrav=-13 is obviously a bug that 
should be corrected. I did not verify (yet) if the same problem occurs 
with ibrav=-12, but I suspect it may occur also. If some problem occurs 
also for other negative ibrav values, I do not know.


By the way, when explaining the different ibrav values the manual should 
include a mention (now absent) to the possibility of having ibrav=-13, 
and when explaining both ibrav=-12 and ibrav=-13 it should be said, at 
that same place, that one must add uniqueb=.true. (although actually 
specifying uniqueb should not be necessary, it might be adopted 
automatically by the program when these two negative ibrav values are 
detected).


Regards,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] ibrav = 13 monoclinic-base-centered unique axis

[José C. Conesa]

Hi,

Indeed, that's what works.

It is a nuisance that ibrav=-13 option is not included in the html 
manual - but is mentioned in uniqueb!


Thanks,

JC Conesa


El 25/01/2018 a las 20:26, Vahid Askarpour escribió:

Hi,

Shouldn’t this be uniqueb instead of unique_b?

Vahid

Vahid Askarpour
Department of Physics and Atmospheric Science
Dalhousie University,
Halifax, NS, Canada

On Jan 25, 2018, at 3:17 PM, José C. Conesa <jccon...@icp.csic.es 
<mailto:jccon...@icp.csic.es>> wrote:


Hi,

This did not work. By including:




    ibrav=-13
    space_group=12
    unique_b=.true.
    A=14.3100,B=6.3383,C=10.1995,cosAC=-0.70644
.

this error appeared:

 %%
 Error in routine  read_namelists (19):
  bad line in namelist : " unique_b=.true." (error could 
be in the previous line)

 %%

What should be done?
Thanks in advance,
JC Conesa

El 25/01/2018 a las 18:12, Paolo Giannozzi escribió:
On Thu, Jan 25, 2018 at 5:34 PM, José Carlos Conesa 
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:



  Input ibrav not compatible with space group number

You may need to specify "unique_b=.true."

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



___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Libre de virus. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum




--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] ibrav = 13 monoclinic-base-centered unique axis

[José C. Conesa]

Hi,

This did not work. By including:




    ibrav=-13
    space_group=12
    unique_b=.true.
    A=14.3100,B=6.3383,C=10.1995,cosAC=-0.70644
.

this error appeared:

 %%
 Error in routine  read_namelists (19):
  bad line in namelist : "    unique_b=.true." (error could 
be in the previous line)

 %%

What should be done?
Thanks in advance,
JC Conesa

El 25/01/2018 a las 18:12, Paolo Giannozzi escribió:
On Thu, Jan 25, 2018 at 5:34 PM, José Carlos Conesa 
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:



  Input ibrav not compatible with space group number

You may need to specify "unique_b=.true."

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



___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] error in compilation of WEST

[José C. Conesa]

Hi,

I found the same error. Which in my opinion is surprising, since the 
full error reads


exx_go.f90(21): error #7002: Error in opening the compiled module file.  
Check INCLUDE paths.   [PARALLEL_INCLUDE]

  USE fft_base,   ONLY : dfftp,dffts
--^

and my compilation of exx_go.f90, where the error occurs, is according 
to the instruction (invoked by make)


mpiifort -O2     -nomodule    ...    -D__FFTW3  -D__MPI    ... 
-I../../Modules    ...    -c exx_go.f90


and, if I give the order ls ../../Modules/fft_base*    from the 
directory containing  file exx_go.f90  , the result is


../../Modules/fft_base.f90 ../../Modules/fft_base.o  
../../Modules/fft_base.mod


I do not understand thus why the fft_base.mod module (which does contain 
the dfftp and dffts types) is not found, since -I../../Modules is 
included in the call to mpiifort.


¿Any help?

Regards,
José C. Conesa

El 28/12/2017 a las 9:17, Paolo Giannozzi escribió:

Hi Eduardo

West uses a lot of code from QE, but it is not distributed together 
with QE, so any change in the latter may break the former I don't know 
which version is compatible with which: please inquire with the 
authors of West, or try previous versions of QE until you find one 
that works


Paolo

On Wed, Dec 27, 2017 at 2:25 PM, Eduardo Menendez <earie...@gmail.com 
<mailto:earie...@gmail.com>> wrote:


Hi,
I have got an error compiling WEST within qe-6.2.1
May be this be caused by using a two years-old compiler
(Intel2015), or due to use   -D__DFTI  instead of -D_FFTW3 ?

exx_go.f90(21): error #7002: Error in opening the compiled module
file.  Check INCLUDE paths. [PARALLEL_INCLUDE]
... and a lot of subsequent errors.

I had no problem making pwall, cp, gwl

Thank you ,

Eduardo Menendez Proupin

___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>




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



___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] version.f90 not found durin installation of qe-6.2

[José C. Conesa]

Dear Paolo,

Well.. indeed I have verified now that file version.f90 is included 
where you say. The point is that after running ./configure the file 
disappears; one does not expect that configure would do such thing.


The remedy is to do, _befor__e r__unning ./configure_, as said in the 
link you mentioned in you first reply. Which obviously I had not 
interpreted well. I had looked not in the tarball but in the result of 
untarring it. I presume that you will modify Modules/Makefile as needed 
one of these days.


But now another problem appears: when compiling Modules/qes_libs.f90 
this error appearsmany times:


 error #6457: This derived type name has not been declared.   [XMLF_T]
   TYPE(xmlf_t)  :: xp

and compilation aborts. What to do?

In any case, if the tarball is -rc maybe I cannot rely on its results...

Best,
José Carlos
El 05/10/2017 a las 19:01, Paolo Giannozzi escribió:
On Thu, Oct 5, 2017 at 4:05 PM, José Carlos Conesa 
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:


I do not understand what you mean by "unlikely"; this qe-6.2
version is available in the normal qe download page. Maybe the -rc
suffix means pre-release; I did not know it.


"rc" = "release candidate" in the jargon of geeks. Note that the 
release hasn't been announced yet. Of course everybody is welcome to 
test it and to report problems.


I could not find any file named version.f90 in the tarball


I could:
$ tar -tzvf qe-6.2.tar.gz qe-6.2/Modules/version.f90
-rw-r--r-- giannozz/giannozz 510 2017-09-26 15:35 
qe-6.2/Modules/version.f90

The file version.f90 is attached

Paolo

, and what should one do otherwise with Modules/Makefile is unclear.
Please tell if one should refrain from using that version while it
has the -rc suffix.
Regards,
José Carlos
El 05/10/2017 a las 13:58, Paolo Giannozzi escribió:

On Thu, Oct 5, 2017 at 1:43 PM, José Carlos Conesa
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:

I have downloaded qe 6.2


unlikely: what is available is a pre-release, for testing

Compilation starts [...] then aborts with the
message that version.f90 cannot be found.


see here:
http://qe-forge.org/pipermail/pw_forum/2017-September/113895.html
<http://qe-forge.org/pipermail/pw_forum/2017-September/113895.html>

Paolo

-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,

Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216 <tel:+39%200432%20558216>, fax
+39-0432-558222 <tel:+39%200432%20558222>



___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum
<http://pwscf.org/mailman/listinfo/pw_forum>



-- 
José C. Conesa

Director
Instituto de Catálisis y Peroleoquímica, CSIC
Campus de Excelencia UAM-CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel.+34-915854766 <tel:+34%20915%2085%2047%2066>Fax+34-915854760 
<tel:+34%20915%2085%2047%2060>


___
Pw_forum mailing list
Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
http://pwscf.org/mailman/listinfo/pw_forum

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



<http://pwscf.org/mailman/listinfo/pw_forum>

<http://pwscf.org/mailman/listinfo/pw_forum>


___________
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] how to judge movement of HOMO and LUMO

["José C. Conesa"]

Dear Rajdeep Banerjee,
In a recent paper of mine (http://dx.doi.org/10.1021/jp306160c) I used 
the van de Walle & Martin's scheme, later used by Pasquarello, to 
compute the band alignment at ZnO/TiO2(anatase) interfaces. The purely 
electrostatic (ionic + Hartree) potential was used as reference. At 
least the results agreed with experimental observations from Gr?tzel's 
group on certain DSSCs. What I would stress here is that one should pay 
attention also (as I did in that work) to the need of obtaining as 
reliable VB and CB positions as possible - which implies at least a good 
reproduction of the bandgap, a well known issue. A way to do so, without 
having to carry out rather expensive GW calculations, may be to use a 
PBE0 hybrid functional with the fraction of HF exchange tuned to the 
optical dielectric constant (a suggestion by Lucia Reining's group); see 
the mentioned paper as well as 
http://dx.doi.org/10.1016/j.cattod.2012.08.039 for details and references.
Good luck,
Jos? Carlos

El 04/06/2014 14:10, Sclauzero Gabriele escribi?:
> Dear Rajdeep Banerjee,
>
>  I think what is used as reference potential is the bare ionic potential 
> + Hartree potential (V_bare + V_H). I kind of justification for that is given 
> in this older paper by van de Walle & Martin 
> (http://journals.aps.org/prb/pdf/10.1103/PhysRevB.35.8154) about band lineups 
> at heterointerfaces.
>
> I agree with Nicola that the problem is subtle, given that a pure bulk 
> calculation for an infinite solid cannot provide absolute energy levels.
> Hopefully someone with clearer ideas than me will be able to suggest 
> alternative solutions.
>
> Best,
>
> GS
>
>
> Dear Sclauzero  Gabriele,
>  I looked at the paper you suggested 
> (http://journals.aps.org/prl/pdf/10.1103/PhysRevLett.101.046405) where it was 
> said that the "common reference level (phi) " is calculated as the "cell 
> average of the local potential originating from the ionic pseudopotentials" 
> which I guess can be calculated from the pseudopotentials used. Can you 
> suggest any functional form for this calculation of phi ? or indicate how to 
> generate it from the pseudopotentials used?
>
> As far as I understand, after defining phi, the CBM and VBM can be described 
> by:
>
>
> CBM = Ec - phi
> VBM = Ev - phi
>
> where Ec and Ev are LUMO and HOMO respectively.
>
> Thank you very much for all the help.
>
> Rajdeep Banerjee
> JNCASR,
> Bangalore, India
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
>
> Dr. Gabriele Sclauzero
> Materials Theory - ETHZ
> ETH Zurich, HIT G 43.2
> Wolfgang-Pauli-Str. 27
> 8093 Z?rich, Switzerland
>
> Phone +41 44 633 94 10
> Fax +41 44 633 14 59
> gabriele.sclauzero at mat.ethz.ch
> www.theory.mat.ethz.ch
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Jos? C. Conesa
Director
Instituto de Cat?lisis y Petroleoqu?mica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid - Spain
Tel. +34-915854766

[Pw_forum] Fail to predict semiconductor

["José C. Conesa"]

Dear Iwan,
In the paper you quote, the Ti:ZnO case has the Ti levels inside the ZnO 
conduction band (see fig. 2) - and this even though the latter band has 
been pushed up by applying an ad hoc shift to the Zn 4s levels, so that 
the correct gap of ZnO is obtained. Thus it does not seem that the 
calculation reported there predicts this system to be a semiconductor. 
Of course, experimentally it may happen that the material prepared, 
especially if it was made in even mildly oxidizing environment, contains 
cation vacancies, possibly located close to the Ti atoms (assuming these 
to be at tetrahedral sites - which is not a preferred coordination for 
Ti) so that it could behave as semiconductor.
In any case computing correctly band gaps and level positions in these 
systems is tricky even with post-DFT treatments. I try to avoid if 
possible DFT+U (treating differently different electrons is not very 
elegant), and to use hybrids instead. One problem with the latter is 
that the fraction of Fock exchange to be used can be questioned. Indeed 
one same fraction is not valid for both TiO2 and ZnO. You can approach 
the situation better if that fraction is tuned to the dielectric 
constant of the material. If you are interested in this specific issue I 
invite you to look at my recent papers J. Phys. Chem. C116 (2012) 18884 
and Catal. Today in press (doi: 10.1016/j.cattod.2012.08.039) where this 
solution is explained better, although its suitability for possibly 
metallic systems like yours can be questioned as well.
Regards,
Jos?-Carlos

El 23/01/2013 15:56, Iwan Darmadi escribi?:
>  Dear Mr.Jose,
>
> Yes, I do. But, as far as I know, transition metal doped zno is 
> semiconductor even theoretically (according for example PRB 79/165202 
> and ). So I assumed that without cation vacancy, Ti doped ZnO might be 
> semiconductor also.
>
> Regards,
> ID
> 
> *
> *Iwan Darmadi*
>  Undergrad.Student - Department of Physics
>  Universitas Indonesia
>
> 
> *From:* Jose C. Conesa 
> *To:* Iwan Darmadi ; PWSCF Forum 
> 
> *Sent:* Wednesday, January 23, 2013 3:09 PM
> *Subject:* Re: [Pw_forum] Fail to predict semiconductor
>
> Dear Iwan,
> Do you know whether the experimentally known Ti doped ZnO contains 
> cation vacancies?
> Good luck,
> Jos? Carlos
>
> El 23/01/2013 6:50, Iwan Darmadi escribi?:
>> Dear all,
>>
>> I have calculated electronic structure of Ti doped ZnO in both GGA 
>> and GGA+U scheme. Both scheme predicts Ti doped ZnO is metallic. In 
>> contrary, Ti doped ZnO is well known as semiconductor experimentally. 
>> At first glance, I thought it was local minimum problem of DFT+U 
>> (like FeO problem in Mr. Himmetoglu's tutorial). Then I try to copy 
>> Mr. Himmetoglu's trick to override a "suspected" fully occupied 
>> orbitals of Ti. Sadly, nothing change,  it's still a metallic.
>>
>> Now, I am confused whether this is a really local minimum problem or 
>> intrinsic limitation of DFT it self.
>>
>> Do anyone here have suggestions so I can get semiconductor Ti doped 
>> ZnO in the calculation ?
>>
>> Ps.
>> I have also attached my input and output file.
>> 
>> *
>> *Iwan Darmadi*
>>  Undergrad.Student - Department of Physics
>>  Universitas Indonesia
>>
>>
>> ___
>> Pw_forum mailing list
>> Pw_forum at pwscf.org  
>> http://pwscf.org/mailman/listinfo/pw_forum
>
>
> -- 
> Jos? C. Conesa
> Instituto de Cat?lisis y Petroleoqu?mica, CSIC
> Marie Curie 2, Cantoblanco
> 28049 Madrid - Spain
> Tel. +34-915854766
>
>

-- 
Jos? C. Conesa
Instituto de Cat?lisis y Petroleoqu?mica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid - Spain
Tel. +34-915854766

-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130125/6df8bce0/attachment-0001.html
 

[Pw_forum] g-tensor with ultrasoft pseudopotential

["José C. Conesa"]

Hi all,
...and it will be great when hybrid functionals can be used as well for it.
Best,
Jos? Carlos

El 22/01/2013 12:41, Jarkko V?h?kangas escribi?:
> Hi Emine,
>
> thank you for your fast response and information. For the present, 
> I'll stay tuned and calculate with norm conserving way. Definitely I 
> am eager to test USSP when that day will come!
>
> thanks, Jarkko
>
>
> On Jan 22, 2013, at 1:02 PM, Kucukbenli Emine 
> mailto:emine.kucukbenli at epfl.ch>>
>  wrote:
>
>> > Hi all,
>> Hi Jarkko
>>
>> > So, is it so that norm conserving way is the only one for g thus far?
>> > If is, why and would it be doable with ultrasoft?
>>
>> Yes, norm conserving is the only way within 'linear response' method 
>> implemented so far.
>> Big part of it is there actually, just needs a careful check on 
>> equations and probably addition of overlap operator 'velocities'..It 
>> is high priority in our todo list. If you want to contribute in 
>> implementation, it would be great. Otherwise, stay tuned!
>>
>> emine kucukbenli, postdoc, theos, epfl, switzerland
>>
>> ps: i believe there is an almost ready to be released "converse 
>> approach" version for g tensor with USPPs. For more on converse, 
>> check the references here:http://code.google.com/p/converse-nmr/
>>
>> ___
>> Pw_forum mailing list
>> Pw_forum at pwscf.org 
>> http://pwscf.org/mailman/listinfo/pw_forum
>
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

-- 
Jos? C. Conesa
Instituto de Cat?lisis y Petroleoqu?mica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid - Spain
Tel. +34-915854766

-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130122/6c7d0bb4/attachment.html
 

[Pw_forum] failure in trying to compute U

["José C. Conesa"]

Hi all,
I am trying to compute U for Mo in a molybdenum bronze, using 
Cococcioni's method. The calculation crashes. A file CRASH results with 
this content:
%%
 task # 9
   reading namelist system
  %%

Standard output shows, after lines
...
  Max number of k-points (npk) =  4
  Max angular momentum in pseudopotentials (lmaxx) =  3
  Waiting for input...
  Reading input from standard input


these lines (repeated as many times as parallel processes involved):
  %%
  Error in routine  read_namelists (17):
   reading namelist system
  %%
  stopping ...

My input file is


title = 'a0.05'
calculation = 'scf'
restart_mode='from_scratch'
verbosity = 'high',
prefix='namo6o17',
etot_conv_thr = 2.0D-6
/

ibrav=14,
celldm(1)= 5.5325, celldm(2)=0.9974, celldm(3)=2.3467,
celldm(4)=0.0, celldm(5)=0.0009076, celldm(6)=-0.49868442,
nat= 24, ntyp= 4,
ecutwfc=30.0, ecutrho=125.0,
nbnd= 150, nspin=2,
starting_magnetization(1)= 0.1,
starting_magnetization(2)=-0.5,
starting_magnetization(3)= 0.0,
starting_magnetization(4)= 0.0,
occupations='smearing', smearing='mp', degauss=0.01,
lda_plus_u = .true.,
Hubbard_U(1)=1.d-8, Hubbard_U(2)=1.d-8, # (values used in the 
previous run)
Hubbard_alpha(1)= 0.0, # this is alpha 0 applied on atom 1 (Mo)
Hubbard_alpha(2)= 0.05, # this is alpha, only applied on atom 2 
(also Mo)
/

 diagonalization='cg'
 startingpot = 'namo6o17'  #
 startingwfc = 'namo6o17' # (the corresponding files from the 
previous run are copied in the main working directory)
 diago_thr_init = 1.59E-10  # (from the previous run)
 mixing_mode = 'plain'
 mixing_beta = 0.7
 conv_thr = 1.0d-9,
/
ATOMIC_SPECIES
  ...(pseudopotentials for all species)
ATOMIC_POSITIONS crystal
(names and coordinates of 24 atoms)
K_POINTS automatic
4 4 4 0 0 0

?Any  hint on the cause of the problem?
Thanks,

-- 
Jos? C. Conesa
Instituto de Cat?lisis y Petroleoqu?mica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid - Spain
Tel. +34-915854766

[Pw_forum] compilation in SGI

[José C. Conesa]

Hi,
I try to compile espresso 3.1 in a SGI Origin 200 system . When 
running configure there appear in the screen some error messages 
within the part of the output related to checking dependencies. This 
part is:

(.)
directory upftools : ok
Cannot open ../iotk/src/iotk_attr+COMP: No such file or directory
pw_export.o : @iotk_module@
WARNING: dependencies not found in directory PP
Cannot open ../iotk/src/iotk_at: No such file or directory
directory PWCOND : ok
Cannot open ../iotk/src/iotk: No such file or directory
directory Gamma : ok
(.)

otherwise, at the end it says "configure: success". But I'm afraid 
something is not runnig well; in particular it seems as if there was 
string truncation in some places, so before going into make all I wish to 
ask the experts whether something should be modified in configure or 
in some of the shell scripts launched by it.

Thanks in advance,




Jose C. Conesa
Instituto de Catalisis y Petroleoquimica, CSIC
Campus de Cantoblanco
28049 Madrid  -  Spain
Phone Nr. 34-91-5854766
Fax Nr. 34-91-5854760

[Pw_forum] titania crystal stucture

[José C. Conesa]

On 9 May 2006 at 8:20, Luke Thulin wrote:

> Hello,
> 
> I'd like to model the band structure of anatase titania, but I'm having 
> more difficulty than I expected just finding the coordinates for the 
> atoms in the unit cell.  So far I've only been able to find out that it 
> has some type of tetragonal or body centered tetragonal structure with a 
> = 3.785A and c=9.514A.  Can anyone help me fill in the rest of what I 
> need to enter the structure into QE so I can get a good visual of it in 
> XCrysDen?  Or for future reference, does anyone know of any resources, 
> online or otherwise, of the crystal structures of some common compounds 
> such as this?
> 
There are a number of crystallography databases where you can search structures 
online. A great one is ICSD, but only a small fraction of the structures is 
available to 
nonsuscribed institutions; even in that case, a good set of the most 
fundamental ones 
can be retrieved freely there through the access at
http://icsdweb.fiz-karlsruhe.de/index.php 
Other interesting structure servers are:

http://rruff.geo.arizona.edu/AMS/amcsd.php
http://cst-www.nrl.navy.mil/lattice/

but surely there are more. Perhaps if yopu look with google for "crystal 
structure 
database" you would find some of them. Of course, knowing how to handle a 
crystal 
description (with space group, taking into account settings, etc.) is quite 
impoertant to 
know what to do with the structure descriptions. For such structure handling, 
and also 
visualization and symmetry operations, a good program is PowderCell for Windows 
(now at version 2.4; free to download), see:
http://www.ccp14.ac.uk/ccp/web-mirrors/powdcell/a_v/v_1/powder/e_cell.html
Good luck,

Jose C. Conesa
Instituto de Catalisis y Petroleoquimica, CSIC
Campus de Cantoblanco
28049 Madrid  -  Spain
Phone Nr. 34-91-5854766
Fax Nr. 34-91-5854760