Re: [Pw_forum] Fwd: bands calculation in QE

[Manjusha Chugh]

Thank you Prof. Paolo


Manjusha


On Thu, Feb 4, 2016 at 12:04 PM, Paolo Giannozzi 
wrote:

> On Thu, Feb 4, 2016 at 1:32 PM, Manjusha Chugh 
> wrote:
>
> I want to calculate the band structure of a semiconductor, only in the
>> vicinity of the Fermi Level. Basically, I want to reduce the value of the
>> parameter 'nbnd'. I am interested to see the bands near the Fermi Energy,
>> not the complete band structure. Is there a way to do the same in QE?
>>
>
> no
>
> Secondly, 'bands' calculation in QE generates a huge amount of data. (Yes,
>> I also have a fairly large system, but still the data stored in 'outdir' is
>> large.) Is there a way to reduce the storage need of data for 'bands' and
>> then bands.x calculations?
>>
>
> You may use disk_io = 'none' if you do not not need to store wavefunctions
> for later usage
>
> 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
>
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] FM relaxed to AFM!

[Jaret Qi]

Well, this only noticed when I introduced a vacuum. Maybe the reason was I run 
nspin=2 with calculation='scf'. I will try it with calculation='relax'. 
Thank you Stefano.

On Thursday, February 4, 2016 9:50 PM, Stefano de Gironcoli 
 wrote:
 

 Starting_magnetization defines the initial magnetic configuration of your 
calculation but does not constrain the nature of the scf solution. Apparently 
your system likes more to be AFM 

stefano (sent from my phone)
On 05 Feb 2016, at 01:23, Jaret Qi  wrote:


Dear QE users,
I run a ferromagnetic input where I used starting_magnetization(i)=1. But when 
I get the magnetization for all i type atoms, one of the atoms give a negative 
magnetic moment which means I got an antiferromagnetic system. This is totally 
confusing since I run the system as a ferromagnetic not antiferromagnetic.Any 
help?part of the input: /
 
    ibrav=0
    celldm(1)=7.540006694
    nat=55
    ntyp=7
    ecutwfc = 30 ,
    ecutrho=300
    occupations='smearing'
    degauss=0.02
    nspin=2
    starting_magnetization(3) = 1 
    lda_plus_u = .true.
    Hubbard_U(3)= 2
    Hubbard_J0(3)=0.7
 /
 
    mixing_beta=0.3,
    electron_maxstep=500
/
ATOMIC_SPECIES
  Sr    87.62  Sr.pbe-nsp-van.UPF
  La   138.90547   La.pbe-nsp-van.UPF
  Mn   54.938050   Mn.pbe-sp-van.UPF
  O    15.999400    O.pbe-n-rrkjus_psl.0.1.UPF
  Ti    47.867 Ti.pbe-sp-van_ak.UPF
  Pb   207.2   Pb.pbe-dn-rrkjus_psl.0.2.2.UPF
  Zr    91.224 Zr.pbe-nsp-van.UPF

--
Thank you in advance!
-JaretASU
 

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


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

Re: [Pw_forum] Fwd: bands calculation in QE

[Paolo Giannozzi]

On Thu, Feb 4, 2016 at 1:32 PM, Manjusha Chugh 
wrote:

I want to calculate the band structure of a semiconductor, only in the
> vicinity of the Fermi Level. Basically, I want to reduce the value of the
> parameter 'nbnd'. I am interested to see the bands near the Fermi Energy,
> not the complete band structure. Is there a way to do the same in QE?
>

no

Secondly, 'bands' calculation in QE generates a huge amount of data. (Yes,
> I also have a fairly large system, but still the data stored in 'outdir' is
> large.) Is there a way to reduce the storage need of data for 'bands' and
> then bands.x calculations?
>

You may use disk_io = 'none' if you do not not need to store wavefunctions
for later usage

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
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] question on the lplot_drho variable of turbo_davidson

[xiaochuan Ge]

​Dear Giuseppe,

Sorry for the delay. That might be some bugs in the plot_drho calculation,
but I do not have your input file for the ground state calculation, so I
cannot reproduce your error. I tried to do this calculation with another
system, everything works fine. Can you follow the example and double check
your input? If it still doesn't work please send me all your input files.

Regarding the response density, I am afraid you do have a misunderstanding.
Since we are using the linear response approach, the response density is
|H+L|^2 -|H|^2 ~= 2H*L
which means you should take the product of Homo and Lumo. If you plot both
the Homo and Lumo, what you should expect for the response density if a
product of these two orbitals, instead of charge depletion and charge
accumulation. If you would like to know details of how the response density
is defined in TDDFT@QE, I suggest you to read this paper:
J. Chem. Phys. 128, 154105 (2008)

I wish my answer helps, please do not hesitate to let me know if you want
to discuss more.

Best,

On 29 January 2016 at 10:52, Giuseppe Mattioli  wrote:

> Neither I in the case of a symmetric water molecule. I was only trying to
> say that the plotted quantity could not be the total density of the S1*
> state because it contains a negative and a positive part. In a "naif" view
> I would say that if a given electronic transition is almost totally
> projected on the HOMO-->LUMO vector, then the lplot_drho plot should show
> charge depletion on the HOMO and charge accumulation on the LUMO
>



===
Dr. Xiaochuan Ge (Giovanni)
Center for Functional Nanomaterials
Brookhaven national laboratory
===
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] possible i/o bug in turbo_lanczos.x and turbo_davidson.x 5.3.0

[Giuseppe Mattioli]

Silent crash on bluegene with 5.2.1 (I have no time to compile 5.3.0 now. I may 
try tomorrow if you think it is important).


 Program turboTDDFT v.5.2.1 starts on  4Feb2016 at 17:56:55

 This program is part of the open-source Quantum ESPRESSO suite
 for quantum simulation of materials; please cite
 "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
  URL http://www.quantum-espresso.org;,
 in publications or presentations arising from this work. More details at
 http://www.quantum-espresso.org/quote

 Parallel version (MPI & OpenMP), running on2048 processor cores
 Number of MPI processes:   512
 Threads/MPI process: 4
 R & G space division:  proc/nbgrp/npool/nimage = 512

 Reading data from directory:
 /gpfs/scratch/userexternal/gmattiol/test/tddft/run/tmp/././l0-5.3.0.save

   Info: using nr1, nr2, nr3 values from input

   Info: using nr1, nr2, nr3 values from input

 IMPORTANT: XC functional enforced from input :
 Exchange-correlation  =  SLA  PW   PBE  PBE ( 1  4  3  4 0 0)
 Any further DFT definition will be discarded
 Please, verify this is what you really want


 Parallelization info
 
 sticks:   dense  smooth PW G-vecs:dense   smooth  PW
 Min  78  38  812054 4220 492
 Max  80  40 1012104 4300 550
 Sum   40733   20369   5097  6186431  2186841  273425
 Tot   20367   10185   2549


 negative rho (up, down):  9.597E-02 0.000E+00

 Subspace diagonalization in iterative solution of the eigenvalue problem:
 scalapack distributed-memory algorithm (size of sub-group: 16* 16 procs)


 Warning: There are virtual states in the input file, trying to disregard 
in response calculation

 Ultrasoft (Vanderbilt) Pseudopotentials

 Normal read

 Gamma point algorithm
2016-02-04 17:57:18.063 (WARN ) [0x4ee8d50] :7014845:ibm.runjob.client.Job: 
terminated by signal 6
2016-02-04 17:57:18.065 (WARN ) [0x4ee8d50] :7014845:ibm.runjob.client.Job: 
abnormal termination by signal 6 from rank 295
On Thursday, February 04, 2016 03:46:10 PM Timrov Iurii wrote:
> Dear Giuseppe,
> 
> As far as I understand the code crashes when it tries to write the vectors 
> "d0psi" to the disc. First thing to do, I think, is to check that you
> have enough space on the disc. If this is not the issue, then let's continue 
> looking for a reason.
> 
> You may want to look in the routine TDDFPT/src/lr_solve_e.f90 at lines 
> 110-138 where the code writes vectors to the disc in parallel. Please make
> sure that the "outdir" is the same in PWscf and in Lanczos/Davidson (and 
> don't specify wfcdir). If this does not solve the problem, could you
> report please also the output of Lanczos/Davidson (better Lanczos)?
> 
> HTH
> 
> Best regards,
> Iurii Timrov
> Post-doctoral researcher
> THEOS - École Polytechnique Fédérale de Lausanne
> Lausanne, Switzerland
> 
> 
> 
> From: pw_forum-boun...@pwscf.org  on behalf of 
> Giuseppe Mattioli 
> Sent: Thursday, February 4, 2016 11:34 AM
> To: pw_forum@pwscf.org
> Subject: [Pw_forum] possible i/o bug in turbo_lanczos.x and turbo_davidson.x  
>   5.3.0
> 
> Dear All
> I'm having problems when performing nontrivial runs of turbo_davidson.x and 
> turbo_lanczos.x with 5.2.1 and 5.3.0 versions of QE.
> Let me say first that "trivial" runs (CH4 molecule with same pseudopotentials 
> and cutoffs but a smaller 30 a.u.^3 cubic cell) work fine with all the
> tested versions.
> However, the input files for a nontrivial case that leads to crash should run 
> on a decent pc in about 1 hr, so they provide a significant but not
> huge test. *Note* that if I run the same input files with the 5.1.1 version 
> (compiled against the very same environment) everything goes (more
> slowly but) fine! The 5.3.0 (and 5.2.1) crashes have been reproduced on two 
> different machines (intel 8 cores 16GB RAM, amd 32 cores 64 GB RAM), so
> they should not be considered as erratic.
> 
> here is the pw.x run. The PPs are quite old and can be found in the online 
> library (or provided by me on demand).
> 
>  
> calculation = 'scf'
> restart_mode='from_scratch',
> prefix='l0-5.3.0',
> pseudo_dir = '/home/mattioligi/PP_UPF/',
> outdir='/home/mattioligi/cocat/test_tddft/5.2.1/l0/5.3.0/run/tmp/',
> nstep=300,
> max_seconds=8,
> disk_io='low',
> tprnfor=.true.,
>  /
>  
> ibrav=1, celldm(1)=40.00,
> nat=42, ntyp=4, nbnd=75,
> ecutwfc = 40.0,
> ecutrho = 320.0,
> nspin=1,
>  /
>  
> diagonalization='david',
> mixing_mode='plain'
> mixing_beta=0.1
> conv_thr=1.0d-8
> electron_maxstep=100
>  /
>  
>  /
> ATOMIC_SPECIES
> O15.999

Re: [Pw_forum] possible i/o bug in turbo_lanczos.x and turbo_davidson.x 5.3.0

[Giuseppe Mattioli]

Dear Iurii
Thanks for your help.

> First thing to do, I think, is to check that you
> have enough space on the disc.

Yes, there is

> You may want to look in the routine TDDFPT/src/lr_solve_e.f90 at lines 
> 110-138 where the code writes vectors to the disc in parallel.

I've checked that the lines are very similar (substantially identical?) in 
5.3.0 and 5.1.1. So it is very strange that the latter works when the 
former does not.

> Please make
> sure that the "outdir" is the same in PWscf and in Lanczos/Davidson (and 
> don't specify wfcdir).

Done, I've also tried to place "outdir" in local or distributed filesystem: 
always same results

> If this does not solve the problem, could you
> report please also the output of Lanczos/Davidson (better Lanczos)?

Lanczos output attached

I'm sending the same test to the fermi@cineca bluegene machine to see if the 
xlf compilers like my scripts more than the intel compilers...

Best Wishes
Giuseppe

On Thursday, February 04, 2016 03:46:10 PM Timrov Iurii wrote:
> Dear Giuseppe,
> 
> As far as I understand the code crashes when it tries to write the vectors 
> "d0psi" to the disc. First thing to do, I think, is to check that you
> have enough space on the disc. If this is not the issue, then let's continue 
> looking for a reason.
> 
> You may want to look in the routine TDDFPT/src/lr_solve_e.f90 at lines 
> 110-138 where the code writes vectors to the disc in parallel. Please make
> sure that the "outdir" is the same in PWscf and in Lanczos/Davidson (and 
> don't specify wfcdir). If this does not solve the problem, could you
> report please also the output of Lanczos/Davidson (better Lanczos)?
> 
> HTH
> 
> Best regards,
> Iurii Timrov
> Post-doctoral researcher
> THEOS - École Polytechnique Fédérale de Lausanne
> Lausanne, Switzerland
> 
> 
> 
> From: pw_forum-boun...@pwscf.org  on behalf of 
> Giuseppe Mattioli 
> Sent: Thursday, February 4, 2016 11:34 AM
> To: pw_forum@pwscf.org
> Subject: [Pw_forum] possible i/o bug in turbo_lanczos.x and turbo_davidson.x  
>   5.3.0
> 
> Dear All
> I'm having problems when performing nontrivial runs of turbo_davidson.x and 
> turbo_lanczos.x with 5.2.1 and 5.3.0 versions of QE.
> Let me say first that "trivial" runs (CH4 molecule with same pseudopotentials 
> and cutoffs but a smaller 30 a.u.^3 cubic cell) work fine with all the
> tested versions.
> However, the input files for a nontrivial case that leads to crash should run 
> on a decent pc in about 1 hr, so they provide a significant but not
> huge test. *Note* that if I run the same input files with the 5.1.1 version 
> (compiled against the very same environment) everything goes (more
> slowly but) fine! The 5.3.0 (and 5.2.1) crashes have been reproduced on two 
> different machines (intel 8 cores 16GB RAM, amd 32 cores 64 GB RAM), so
> they should not be considered as erratic.
> 
> here is the pw.x run. The PPs are quite old and can be found in the online 
> library (or provided by me on demand).
> 
>  
> calculation = 'scf'
> restart_mode='from_scratch',
> prefix='l0-5.3.0',
> pseudo_dir = '/home/mattioligi/PP_UPF/',
> outdir='/home/mattioligi/cocat/test_tddft/5.2.1/l0/5.3.0/run/tmp/',
> nstep=300,
> max_seconds=8,
> disk_io='low',
> tprnfor=.true.,
>  /
>  
> ibrav=1, celldm(1)=40.00,
> nat=42, ntyp=4, nbnd=75,
> ecutwfc = 40.0,
> ecutrho = 320.0,
> nspin=1,
>  /
>  
> diagonalization='david',
> mixing_mode='plain'
> mixing_beta=0.1
> conv_thr=1.0d-8
> electron_maxstep=100
>  /
>  
>  /
> ATOMIC_SPECIES
> O15.999O_pbe.van.UPF
> N14.007N.pbe-van_bm.UPF
> C12.011C_pbe.van.UPF
> H 1.008H_pbe.van.UPF
> ATOMIC_POSITIONS {angstrom}
> C4.815369179  12.355337788   8.111406911
> C5.639537337  12.072210478   7.018248617
> C6.373883049  10.886794669   6.974735758
> H5.707874252  12.778745273   6.179910928
> C4.734413944  11.441350355   9.166316558
> H4.235443595  13.287281698   8.140567718
> C6.304598307   9.97703   8.041477142
> H7.012644682  10.659891408   6.32336
> C5.477180541  10.260422385   9.138835842
> H4.092409998  11.653694694  10.031778418
> H5.418528381   9.546881383   9.971310698
> N7.058612774   8.759574945   8.006208499
> C6.384981399   7.544139013   8.340645249
> C6.997532612   6.588483316   9.168188787
> C5.084708421   7.308024697   7.864810575
> C6.325550737   5.410241765   9.493833204
> H8.006262126   6.776794433   9.557919083
> C4.414663626   6.134355690   8.210976959
> H4.597637090   8.055249046   7.224770074
> C5.030975670   5.176070562   9.02077
> H6.819890970   4.670618768  10.138154855
> H3.397721512   5.964689741   7.832306200
> H4.503298572   

[Pw_forum] Fwd: bands calculation in QE

[Manjusha Chugh]

Dear QE users

I have a couple of doubts.
I want to calculate the band structure of a semiconductor, only in the
vicinity of the Fermi Level. Basically, I want to reduce the value of the
parameter 'nbnd'. I am interested to see the bands near the Fermi Energy,
not the complete band structure. Is there a way to do the same in QE?

Secondly, 'bands' calculation in QE generates a huge amount of data. (Yes,
I also have a fairly large system, but still the data stored in 'outdir' is
large.) Is there a way to reduce the storage need of data for 'bands' and
then bands.x calculations?

Thanks in advance.

Regards
Manjusha
Research Scholar
IIT Kanpur, India
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] quantum-espresso RPMS in Fedora/EPEL

[Filippo SPIGA]

On Jan 26, 2016, at 1:42 PM, Marcin Dulak  wrote:
> 3. it would be convenient if the pseudos used by the test-suite are provided 
> as a separate tarball on downloads.

test-suite is a separate tar.gz in 5.3.0. it is a recently introduced 
"feature", still in progress. 


> 4. it seems like parallel make did not work (make -j), when trying the 5.2.1 
> version.
> Please help to clarify this.

Well... if something is broken in the previous 5.2.1 the only thing we can do 
is make sure in the future versions the problem is solved.


> 5. a minor detail in test-suite/run-*.sh scripts: they should use source 
> instead of include:
> sed -i "s#include #source #" test-suite/run-cp.sh
> sed -i "s#include #source #" test-suite/run-pw.sh

But if I do that then test-suite stops working. I need to change as well what 
is in the file ENVIRONMENT. At the moment it is safe to keep include, it 
works...


> 6. there are some tests failures, e.g. on EPEL6 x86_64, with openmpi 171 out 
> of 197 tests passed (2 unknown):
> https://kojipkgs.fedoraproject.org//work/tasks/8858/12648858/build.log
> Search for the first occurence of "171" in this file.
> Some of these seem to be related to vdw part, maybe the files the presence of
> which is assumed for the tests are not created properly?

Those 2 "unknown" are due to the fact that the test cases does not generate any 
specific output that can be compared with previously stored reference outputs. 
The script which extract numerical quantities needs to be extended and it is 
something in the TODO list.

HTH

--
Mr. Filippo SPIGA, M.Sc.
Quantum ESPRESSO Foundation
http://www.quantum-espresso.org ~ skype: filippo.spiga

*
Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and 
may be privileged or otherwise protected from disclosure. The contents are not 
to be disclosed to anyone other than the addressee. Unauthorized recipients are 
requested to preserve this confidentiality and to advise the sender immediately 
of any error in transmission."


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

Re: [Pw_forum] Pw_forum Digest, Vol 103, Issue 4

[chaitanya varma]

Thank you sirI will try.
regards Chaitanya Varma M   

On Thursday, 4 February 2016 4:32 PM, "pw_forum-requ...@pwscf.org" 
<pw_forum-requ...@pwscf.org> wrote:
 

 Send Pw_forum mailing list submissions to
    pw_forum@pwscf.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://pwscf.org/mailman/listinfo/pw_forum
or, via email, send a message with subject or body 'help' to
    pw_forum-requ...@pwscf.org

You can reach the person managing the list at
    pw_forum-ow...@pwscf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pw_forum digest..."


Today's Topics:

  1. ACBN0 pseudopotentil - regarding (chaitanya varma)
  2. Germanium bulk band structure (Michael Schofield)
  3. Re: ACBN0 pseudopotentil - regarding (Matteo Cococcioni)
  4. possible i/o bug in turbo_lanczos.x and turbo_davidson.x
      5.3.0 (Giuseppe Mattioli)
  5. Re: Germanium bulk band structure (Giuseppe Mattioli)


--

Message: 1
Date: Thu, 4 Feb 2016 05:43:58 + (UTC)
From: chaitanya varma <chva...@yahoo.co.in>
Subject: [Pw_forum] ACBN0 pseudopotentil - regarding
To: PWSCF Forum <pw_forum@pwscf.org>
Message-ID:
    <975949975.1277567.1454564638372.javamail.ya...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

Respected Sir,I have seen in one paper Phys Rev X 5, 011006 (2015) that when 
ACBN0 pp is used for calculating band gap of ZnO with Hubbard U values UZn = 
12.8eV and UO = 6.7eV, they got almost good value for band gap (2.91eV).I would 
like to know how to get ACBN0 pp for Mn, W and O for calculating electronic 
structure of MnWO4.
Thank you
regards?Chaitanya Varma M ?Assistant ProfessorDept of PhysicsGITGITAM 
UniversityVisakhapatnam, India
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20160204/cc17389b/attachment-0001.html
 

--

Message: 2
Date: Thu, 4 Feb 2016 12:12:32 +0530
From: Michael Schofield <fwhite...@gmail.com>
Subject: [Pw_forum] Germanium bulk band structure
To: pw_forum@pwscf.org
Message-ID:
    <cap7upmjydl8fsvfeobytjnyqu1ggqsveyrk6ghustnmnk+u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear sir/madam,

I am trying to calculate the bulk band structure for Germanium using GGA
exchange-correlation with PAW basis, but the band gap is coming out to be
almost zero. I know DFT underestimates the band gap but it is coming almost
zero (~0.03eV). Is there any means by which I can get more accurate band
gap.

My input script is here:



 calculation = 'nscf',
 verbosity = 'high',
 restart_mode = 'from_scratch',
 prefix = 'Ge_bulk_nscf',
 tstress = .false.,
 tprnfor = .false.,
 pseudo_dir = '/home/Software/QE/pseudopotentials/upf_files/',
 outdir = './output/'
/


 ibrav=2,
 celldm(1) = 10.690937,
 nat=2, ntyp=1,
 nbnd = 12,
 ecutwfc=60,
 ecutrho= 600,
/


 diagonalization='david',
 mixing_mode = 'plain',
 mixing_beta = 0.7,
 conv_thr =  1.0d-6,
 electron_maxstep = 500,
/

ATOMIC_SPECIES
 Ge 72.64 Ge.pbe-kjpaw.UPF

ATOMIC_POSITIONS crystal
 Ge 0.00 0.00 0.00
 Ge 0.25 0.25 0.25

K_POINTS crystal_b
6
0.0  0.0    0.0  100
0.0  0.5    0.0  100
0.0  0.375 -0.375 100
-0.25 0.25  -0.5  100
-0.5  0.0  -0.5  100
0.0  0.0    0.0  1
 -
PFA the band structure I am getting from it.

Any help/suggestions will be helpful.




Thanks
Priyank
Dept. of EE
IIT Kanpur, India
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20160204/55df8d0d/attachment-0001.html
 
-- next part --
A non-text attachment was scrubbed...
Name: Ge_bulk_GGA_BS.pdf
Type: application/pdf
Size: 40188 bytes
Desc: not available
Url : 
http://pwscf.org/pipermail/pw_forum/attachments/20160204/55df8d0d/attachment-0001.pdf
 

--

Message: 3
Date: Thu, 4 Feb 2016 09:26:36 +0100
From: Matteo Cococcioni <mat...@umn.edu>
Subject: Re: [Pw_forum] ACBN0 pseudopotentil - regarding
To: chaitanya varma <chva...@yahoo.co.in>, PWSCF Forum
    <pw_forum@pwscf.org>
Message-ID:
    <camzasge82ofinypnbau_vwvwfjqe1nhxv4g3c2h8djx17we...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear Varma

you may have to ask the authors of the paper for a more consistent help. As
far as I know/understand from the paper you mention, the ACBN0 is a method
to compute the value of the Hubbard U (based on an ancillary calculation
performed on a gaussian basis set) but does not modifies the
pseudopotential. So I guess it can work with any kind of PP (just like the
normal LDA+U does, independently on how you choose U). However, the value
of U has to be determined with the same PP you plan to use

Re: [Pw_forum] Germanium bulk band structure

[Giuseppe Mattioli]

Dear Priyank
Short answer: use an hybrid functional such as HSE. Bulk Ge is a metal with 
every flavour of GGA.
HTH
Giuseppe


On Thursday, February 04, 2016 12:12:32 PM Michael Schofield wrote:
> Dear sir/madam,
> 
> I am trying to calculate the bulk band structure for Germanium using GGA
> exchange-correlation with PAW basis, but the band gap is coming out to be
> almost zero. I know DFT underestimates the band gap but it is coming almost
> zero (~0.03eV). Is there any means by which I can get more accurate band
> gap.
> 
> My input script is here:
> 
> 
> 
>  calculation = 'nscf',
>  verbosity = 'high',
>  restart_mode = 'from_scratch',
>  prefix = 'Ge_bulk_nscf',
>  tstress = .false.,
>  tprnfor = .false.,
>  pseudo_dir = '/home/Software/QE/pseudopotentials/upf_files/',
>  outdir = './output/'
> /
> 
> 
>  ibrav=2,
>  celldm(1) = 10.690937,
>  nat=2, ntyp=1,
>  nbnd = 12,
>  ecutwfc=60,
>  ecutrho= 600,
> /
> 
> 
>  diagonalization='david',
>  mixing_mode = 'plain',
>  mixing_beta = 0.7,
>  conv_thr =  1.0d-6,
>  electron_maxstep = 500,
> /
> 
> ATOMIC_SPECIES
>  Ge 72.64 Ge.pbe-kjpaw.UPF
> 
> ATOMIC_POSITIONS crystal
>  Ge 0.00 0.00 0.00
>  Ge 0.25 0.25 0.25
> 
> K_POINTS crystal_b
> 6
> 0.0   0.00.0   100
> 0.0   0.50.0   100
> 0.0   0.375 -0.375 100
> -0.25 0.25  -0.5   100
> -0.5  0.0   -0.5   100
> 0.0   0.00.0   1
>  -
> PFA the band structure I am getting from it.
> 
> Any help/suggestions will be helpful.
> 
> 
> 
> 
> Thanks
> Priyank
> Dept. of EE
> IIT Kanpur, India


- Article premier - Les hommes naissent et demeurent
libres et égaux en droits. Les distinctions sociales
ne peuvent être fondées que sur l'utilité commune
- Article 2 - Le but de toute association politique
est la conservation des droits naturels et 
imprescriptibles de l'homme. Ces droits sont la liberté,
la propriété, la sûreté et la résistance à l'oppression.


   Giuseppe Mattioli
   CNR - ISTITUTO DI STRUTTURA DELLA MATERIA   
   v. Salaria Km 29,300 - C.P. 10
   I 00015 - Monterotondo Stazione (RM), Italy
   Tel + 39 06 90672836 - Fax +39 06 90672316
   E-mail: 
   http://www.ism.cnr.it/english/staff/mattiolig
   ResearcherID: F-6308-2012

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

[Pw_forum] possible i/o bug in turbo_lanczos.x and turbo_davidson.x 5.3.0

[Giuseppe Mattioli]

Dear All
I'm having problems when performing nontrivial runs of turbo_davidson.x and 
turbo_lanczos.x with 5.2.1 and 5.3.0 versions of QE.
Let me say first that "trivial" runs (CH4 molecule with same pseudopotentials 
and cutoffs but a smaller 30 a.u.^3 cubic cell) work fine with all the 
tested versions.
However, the input files for a nontrivial case that leads to crash should run 
on a decent pc in about 1 hr, so they provide a significant but not huge 
test. *Note* that if I run the same input files with the 5.1.1 version 
(compiled against the very same environment) everything goes (more slowly but) 
fine! The 5.3.0 (and 5.2.1) crashes have been reproduced on two different 
machines (intel 8 cores 16GB RAM, amd 32 cores 64 GB RAM), so they should not 
be considered as erratic.

here is the pw.x run. The PPs are quite old and can be found in the online 
library (or provided by me on demand).

 
calculation = 'scf'
restart_mode='from_scratch',
prefix='l0-5.3.0',
pseudo_dir = '/home/mattioligi/PP_UPF/',
outdir='/home/mattioligi/cocat/test_tddft/5.2.1/l0/5.3.0/run/tmp/',
nstep=300,
max_seconds=8,
disk_io='low',
tprnfor=.true.,
 /
 
ibrav=1, celldm(1)=40.00,
nat=42, ntyp=4, nbnd=75,
ecutwfc = 40.0,
ecutrho = 320.0,
nspin=1,
 /
 
diagonalization='david',
mixing_mode='plain'
mixing_beta=0.1
conv_thr=1.0d-8
electron_maxstep=100
 /
 
 /
ATOMIC_SPECIES
O15.999O_pbe.van.UPF
N14.007N.pbe-van_bm.UPF
C12.011C_pbe.van.UPF
H 1.008H_pbe.van.UPF
ATOMIC_POSITIONS {angstrom}
C4.815369179  12.355337788   8.111406911
C5.639537337  12.072210478   7.018248617
C6.373883049  10.886794669   6.974735758
H5.707874252  12.778745273   6.179910928
C4.734413944  11.441350355   9.166316558
H4.235443595  13.287281698   8.140567718
C6.304598307   9.97703   8.041477142
H7.012644682  10.659891408   6.32336
C5.477180541  10.260422385   9.138835842
H4.092409998  11.653694694  10.031778418
H5.418528381   9.546881383   9.971310698
N7.058612774   8.759574945   8.006208499
C6.384981399   7.544139013   8.340645249
C6.997532612   6.588483316   9.168188787
C5.084708421   7.308024697   7.864810575
C6.325550737   5.410241765   9.493833204
H8.006262126   6.776794433   9.557919083
C4.414663626   6.134355690   8.210976959
H4.597637090   8.055249046   7.224770074
C5.030975670   5.176070562   9.02077
H6.819890970   4.670618768  10.138154855
H3.397721512   5.964689741   7.832306200
H4.503298572   4.249946635   9.284425745
C8.412602212   8.773905175   7.652414992
C9.197305040   9.938168667   7.841458619
C9.043381168   7.634703664   7.098599788
C   10.533008285   9.972397555   7.486007356
H8.740413757  10.828552107   8.290447985
C   10.383506998   7.674400214   6.758021800
H8.466388332   6.717306584   6.931252215
C   11.175184928   8.838234071   6.927523312
H   11.098162573  10.894629696   7.663657304
H   10.849606517   6.778483121   6.322529487
C   12.554045113   8.768090174   6.529797787
C   13.538745611   9.729179498   6.474718127
H   12.882286114   7.769870632   6.203237321
C   13.338246843  11.096686263   6.810664645
N   13.160471613  12.223162736   7.083088078
C   14.914360413   9.407055683   6.034105289
O   15.832284936  10.221452163   5.956798921
O   15.091537629   8.085358800   5.710801225
H   16.043983143   8.016066678   5.436328923
K_POINTS {gamma}

And here are the turbo_lanczos.x and turbo davidson.x input files

lanczos

_input
prefix="l0-5.3.0",
outdir='/state/partition1/mattioligi/34339',
wfcdir='/state/partition1/mattioligi/34339',
restart_step=6,
restart=.false.
/
_control
itermax=12,
ipol=4,
/

davidson

_input
prefix="l0-5.3.0",
outdir='/state/partition1/mattioligi/34340',
restart=.false.
/
_dav
num_eign=2
num_init=4
num_basis_max=10
residue_conv_thr=1.0E-4
start=0.1
finish=1.5
step=0.0002
broadening=0.005
reference=0.2
p_nbnd_occ=5
p_nbnd_virt=5
poor_of_ram=.false.
poor_of_ram2=.false.
/

In both cases and on both machines the CRASH report is something like

 %%
 task # 1
 from davcio : error #20
 error while writing from file 
"/state/partition1/mattioligi/34340/l0-5.3.0.d0psi.32"
 %%

I suppose that it is some kind of I/O error, but I warmly require your 
opinion...:-)
Thank you in advance
Giuseppe


- Article premier - Les hommes naissent et demeurent
libres et égaux en droits. Les distinctions sociales
ne 

Re: [Pw_forum] ACBN0 pseudopotentil - regarding

[Matteo Cococcioni]

Dear Varma

you may have to ask the authors of the paper for a more consistent help. As
far as I know/understand from the paper you mention, the ACBN0 is a method
to compute the value of the Hubbard U (based on an ancillary calculation
performed on a gaussian basis set) but does not modifies the
pseudopotential. So I guess it can work with any kind of PP (just like the
normal LDA+U does, independently on how you choose U). However, the value
of U has to be determined with the same PP you plan to use it with, for a
good numerical consistency.

Regards,

Matteo

On Thu, Feb 4, 2016 at 6:43 AM, chaitanya varma  wrote:

> Respected Sir,
> I have seen in one paper Phys Rev X 5, 011006 (2015) that when ACBN0 pp is
> used for calculating band gap of ZnO with Hubbard U values UZn = 12.8eV and
> UO = 6.7eV, they got almost good value for band gap (2.91eV).
> I would like to know how to get ACBN0 pp for Mn, W and O for calculating
> electronic structure of MnWO4.
>
> Thank you
>
> regards
>
> Chaitanya Varma M
>  Assistant Professor
> Dept of Physics
> GIT
> GITAM University
> Visakhapatnam, India
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum