[QE-users] Electron-phonon calculations stopped and exited

[Jibiao Li]

Dear All, 



I try to perform el-ph calculations using ph.x (current developer version) with 
the input below, but the calculations stopped and exited just before the 
initiation of electron-phonon interaction calculations. Is this a bug of 
ph.x ? Any solution to this issue? I look forward to receiving your answers.



... ...



  q = (  0.0  0.0  
0.0 ) 

**
  freq (  1) =  -12.236460 
[THz] =  -408.164367 [cm-1]
  freq (  2) =  -12.236460 
[THz] =  -408.164367 [cm-1]
  freq (  3) =  -12.236460 
[THz] =  -408.164367 [cm-1]
  freq (  4) =  
0.279927 [THz] =  9.337362 [cm-1]
  freq (  5) =  
0.279927 [THz] =  9.337362 [cm-1]
  freq (  6) =  
0.279927 [THz] =  9.337362 [cm-1]
  freq (  7) =  
9.332407 [THz] =  311.295591 [cm-1]
  freq (  8) =  
9.332407 [THz] =  311.295591 [cm-1]
  freq (  9) =  
9.332407 [THz] =  311.295591 [cm-1]
  freq (  10) =  25.786128 
[THz] =  860.132635 [cm-1]
  freq (  11) =  25.786128 
[THz] =  860.132635 [cm-1]
  freq (  12) =  25.786128 
[THz] =  860.132635 [cm-1]
  freq (  13) =  31.282119 
[THz] =  1043.459172 [cm-1]
  freq (  14) =  31.282119 
[THz] =  1043.459172 [cm-1]
  freq (  15) =  31.282119 
[THz] =  1043.459172 [cm-1]
  freq (  16) =  38.547065 
[THz] =  1285.791689 [cm-1]
  freq (  17) =  38.547065 
[THz] =  1285.791689 [cm-1]
  freq (  18) =  38.547065 
[THz] =  1285.791689 [cm-1]
  freq (  19) =  47.476599 
[THz] =  1583.648886 [cm-1]
  freq (  20) =  47.476599 
[THz] =  1583.648886 [cm-1]
  freq (  21) =  47.476599 
[THz] =  1583.648886 [cm-1]
  freq (  22) =  48.297068 
[THz] =  1611.016770 [cm-1]
  freq (  23) =  48.297068 
[THz] =  1611.016770 [cm-1]
  freq (  24) =  48.297068 
[THz] =  1611.016770 [cm-1]
**


  electron-phonon interaction ...

forrtl: severe (24): end-of-file during read, unit 40, file 
/home/jibiaoli/calc/cubic/pres_exp/Tc/./bulk.a2Fsave
Image  
PC
  Routine  
Line  
Source  
ph.x 
 014D6D1B 
Unknown 
 Unknown Unknown
ph.x 
 0151119F 
Unknown 
 Unknown Unknown
ph.x 
 0043F1CE 
elphsum_
  806 elphon.f90
ph.x 
 004161B6 
do_phonon_
  143 do_phonon.f90
ph.x 
 0041047E 
MAIN__
  87 phonon.f90
ph.x 
 004103B2 
Unknown 
 Unknown Unknown
libc-2.27.so  7F1F306D3B97 
__libc_start_main  Unknown Unknown
ph.x 
 0041029A 
Unknown 
 Unknown Unknown
--
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.




Phonon for bulk 
inputph
 tr2_ph=1.0d-14,
 alpha_mix(1)=0.3,
 prefix='bulk',
 fildvscf='bulk.dv',
 amass(1)=1.00794,
 amass(2)=32.065,
 outdir='./',
 fildyn='bulk.dyn',
 electron_phonon='interpolated',
 el_ph_sigma=0.005,
 el_ph_nsigma=10,
 trans=.true.,
 ldisp=.true.,
 nq1=8, nq2=8, nq3=8,
 search_sym=.false.,
/




Dr. Jibiao Li, 
Department of Material Science and Engineering
Yangtze Normal University
Juxian Dadao 16#, Fuling, Chongqing, China
Email: jibia...@yznu.edu.cn, jibia...@foxmail.com, jibiao...@hotmail.com
Homepage: https://www.researchgate.net/profile/Jibiao_Li___
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

[QE-users] pseudopotential file reading error in 6.6a2-gpu

[Zeeshan Ahmad]

Hi,

I obtain the following error (only in the gpu version) when I change my ONCV 
pseudopotential to fully relativistic:

FIO-F-225/list-directed read/internal file/lexical error-- unknown token type.
 In source file xmltools.f90, at line number 107

It seems to be due to the pseudopotential file reading error, similar to 
https://www.vasp.at/forum/viewtopic.php?t=330 


The pseudopotentials are SG15 ONCV downloaded from 
http://www.quantum-simulation.org/potentials/sg15_oncv/ 
 
(sg15_oncv_upf_2020-02-06.tar.gz 
)

The input file which gives the error is:
(works fine for me when Pb_ONCV_PBE_FR-1.0.upf is replaced with 
Pb_ONCV_PBE-1.2.upf)


   title = '9009114.cif'
 calculation = 'scf'
restart_mode = 'from_scratch'
  outdir = 'scf'
  pseudo_dir = './'
  prefix = '9009114'
 disk_io = 'none'
   nstep = 400
 /
 
   ibrav = 4
   celldm(1) =8.60770253529410
   celldm(3) =1.53172338090011
 nat = 3
ntyp = 2
 ecutwfc = 70
 /
 
electron_maxstep = 200
conv_thr = 1.0D-10
 mixing_beta = 0.7
 diagonalization = 'david'
 /

ATOMIC_SPECIES
   Pb  207.20  Pb_ONCV_PBE_FR-1.0.upf
I  126.904000  I_ONCV_PBE-1.2.upf
ATOMIC_POSITIONS crystal
Pb  0.0  0.0  0.0
I   0.3  0.7  0.26500
I   0.7  0.4  0.73500
K_POINTS automatic
8  8  6   0 0 0


Thanks,
Zeeshan




--
Zeeshan Ahmad
Postdoctoral Researcher
Pritzker School of Molecular Engineering
University of Chicago

___
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

[QE-users] data/workflows positions at epfl

[Nicola Marzari]

Dear all,

in case it can be of interest, we have 2 positions at EPFL on data 
analytics, data integration, and simulation/machine-learning workflows - 
QE experience would be particularly precious. All info on applications 
(deadline Nov 6) at the link below.


nicola


https://psi-k.net/jobs/two-4-year-postdoctoral-positions-marzariepfl-o/


--
--
Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
Director, National Centre for Competence in Research NCCR MARVEL, EPFL
http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project
___
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] mesh mismatch

[Holzwarth, Natalie]

>From the ATOMPAW side,I will be very happy to adjust the output for
Quantum Espresso as necessary to accommodate any new UPF formatting.
   Thanks, Natalie
N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Thu, Oct 22, 2020 at 11:29 AM Paolo Giannozzi 
wrote:

> On Thu, Oct 22, 2020 at 5:16 PM Sergey Lisenkov 
> wrote:
>
> I encountered a problem with my PAW pseudopotentials from ATOMPAW:
>>
>> mismatch mesh
>>
>> that comes from upflib/read_upf_new.f90
>>
>> I checked my UPF file and I see that meshes are different in some places
>> of the file, however v.6.6 is OK with that.
>>
>> Was something changed in the code as well?
>>
>
> yes, the code reading the pseudopotentials has changed a lot, but it
> should read files exactly as before. Please provide the pseudopotential
> file.
>
> Paolo
>
>
>>
>> Thanks,
>>  Sergey
>>
>> USF
>> ___
>> 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
>
>
>
> --
> 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
___
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] mesh mismatch

[Paolo Giannozzi]

On Thu, Oct 22, 2020 at 5:16 PM Sergey Lisenkov  wrote:

I encountered a problem with my PAW pseudopotentials from ATOMPAW:
>
> mismatch mesh
>
> that comes from upflib/read_upf_new.f90
>
> I checked my UPF file and I see that meshes are different in some places
> of the file, however v.6.6 is OK with that.
>
> Was something changed in the code as well?
>

yes, the code reading the pseudopotentials has changed a lot, but it should
read files exactly as before. Please provide the pseudopotential file.

Paolo


>
> Thanks,
>  Sergey
>
> USF
> ___
> 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



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

[QE-users] mesh mismatch

[Sergey Lisenkov]

Dear all, I noticed that in developing version of QE several bugs related to DFT+U were fixed so I tried to use the latest snapshot. However, I encountered a problem with my PAW pseudopotentials from ATOMPAW: mismatch mesh that comes from upflib/read_upf_new.f90 I checked my UPF file and I see that meshes are different in some places of the file, however v.6.6 is OK with that. Was something changed in the code as well? Thanks, Sergey USF
___
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-GPU] nscf calculation problem

[Paolo Giannozzi]

On Thu, Oct 22, 2020 at 4:36 PM lorenzo bastonero <
lorenzo.baston...@edu.unito.it> wrote:


> I need to calculate several bands (i.e. 8000) for GW calculations.


it's not "several bands", it's "a lot of bands". QE is not optimized for
such a case (and I don't think it will ever be).
The printout of the amount of RAM is not meant to give a reliable estimate
but just an order of magnitude

Paolo


> Running on 2 nodes with npool 2, the dynamical RAM per process is above
> 16Gb. I tried out with npool 1, but I encountered the error "S matrix not
> positive definite”. I decided then to try with 4 nodes and npool 2 with the
> option diago_david_ndim='2', then the dyn RAM/process is 14.97Gb, so it has
> to work now. But the calculation stops without the “CRASH” file and in the
> output I got "2 total processes killed (some possibly by mpirun during
> cleanup)”. In the slurm-output there are several segmentation fault error
> messages.
> I also discussed the problem with my supervisor but we are puzzled.
>
> Any suggestions on what to do?
>
> You’ll find attached the main outputs.
>
> Thanks for your precious time.
>
> Kind regards,
>
> Lorenzo Bastonero
>
>
> --
> 
>
>
>
> Indirizzo istituzionale di posta elettronica
> degli studenti e dei laureati dell'Università degli Studi di
> TorinoOfficial
> University of Turin email address for students and graduates
> ___
> 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



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

[QE-users] [QE-GPU] nscf calculation problem

[lorenzo bastonero]

Hi,

I’m currently running on Marconi100 nscf calculations (qe v 6.6) for the 
interface of two monolayers (which I already studied separately and got no 
issues). 
I need to calculate several bands (i.e. 8000) for GW calculations. Running on 2 
nodes with npool 2, the dynamical RAM per process is above 16Gb. I tried out 
with npool 1, but I encountered the error "S matrix not positive definite”. I 
decided then to try with 4 nodes and npool 2 with the option 
diago_david_ndim='2', then the dyn RAM/process is 14.97Gb, so it has to work 
now. But the calculation stops without the “CRASH” file and in the output I got 
"2 total processes killed (some possibly by mpirun during cleanup)”. In the 
slurm-output there are several segmentation fault error messages. 
I also discussed the problem with my supervisor but we are puzzled. 

Any suggestions on what to do?  

You’ll find attached the main outputs.

Thanks for your precious time.

Kind regards,

Lorenzo Bastonero


-- 




Indirizzo istituzionale di posta elettronica 
degli studenti e dei laureati dell'Università degli Studi di TorinoOfficial 
University of Turin email address for students and graduates 


slurm-1280351.out
Description: Binary data


hetero.PdPt.AA.2L.soc.nscf.out
Description: Binary data
___
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

[QE-users] B3LYD

[Mohamed Ahmed Abd-Elati]

Dear all
I am so sorry for this trivial question.
I am using the quantum Espresso.6.4 (turbo_laczos.x program)  for studying
the optical properties of graphene quantum dots. Is the list of functionals
available for PWscf on the QE home page include B3LYP  hybrid potentials.
Also , what is the difference between TDDFPT and TD-B3LYP .
Thanks
*Mohammed A. Abdelati*
*Assistant Lecturer*
Laser Applications in Metrology Photochemistry and Agriculture (LAMPA)
Department, National Institute of Laser Enhanced Sciences (NILES), Cairo
University, Giza, Egypt.
Mobile   +20 1009752922
Home+201152605076
E-mailma198...@yahoo.com
___
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] Calculating U parameter for Ni in LiNiO2 using hp.x

[Hongyi Zhao]

On Thu, Oct 22, 2020 at 6:23 PM Timrov Iurii  wrote:
>
> > Is it possiable for me to iterate on the result of the first solution
> > to achieve more precise results?
>
> I do not understand your question.

Sorry for my unclear/erroneous/misleading description.

You said the following,

> The second solution is faster but maybe less accurate. The first solution is 
> longer but more accurate.

So, it would be better if we can further refine the result obtained by
the second solution by some technical post-processing. This is just
what I mean.


> Please do not forget to add your affiliation.

In fact, the affiliation is automatically added as the signature. But
the very long quoted messages may make it more difficult to discover
it.

Regards,
-- 
Assoc. Prof. Hongyi Zhao 
Theory and Simulation of Materials, Xingtai Polytechnic College
NO. 552 North Gangtie Road, Xingtai, China
___
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] NEB : path length is increasing

[Omer Mutasim]

 Thanks a lot Dr. Antoine Jay for your help.
I've went through your paper, r-ART is by far more faster & precise than NEB, i 
will try it. 
On Wednesday, October 21, 2020, 11:48:33 PM GMT+4, Antoine Jay 
 wrote:  
 
 Dear Omar,
After your pre-converged step, you can copy all the intermediate images from 
the .crd file.
This is a very standard procedure for heavy systems.
Do not worry about the size of the path: it can only increase because the 
initial path is the linear interpolation between first and last images, so the 
smallest that is possible.
A CI (=auto or suggested by the user) also increases the  velocity of the 
convergeance and the precision.

To be even faster (10times) and accurate (10times), you can use ARTn that has 
been coupled with QE this year and have shown formidable efficiencies (DOI: 
10.1021/acs.jctc.0c00541)

Regards,

Antoine Jay
LAAS CNRS
Toulouse, France

Le Mercredi, Octobre 21, 2020 21:04 CEST, Omer Mutasim  
a écrit:
 
 
Very helpful ideas.But after pre-converging with inexpensive parameters, i will 
get first & last image that are different than my actual images with higher 
parameters ( k-pointss, cutoff,..)So then how i can use this pre-converged path 
for my actual settings? 

Sent from Yahoo Mail for iPhone
 
On Wednesday, October 21, 2020, 3:06 PM, Tamas Karpati  
wrote:

Dear Omar, Hope it helps, just some ideas:- I could tell more if you would 
attach the whole input file (ie. thestructures).- Without knowing the 
structures only I can give some hints:  -- Try using smaller PW basis and lower 
ecutwfc, ecutrho to speed upyour simulation.  -- When you obtain something more 
reliable result, you can changeback to the higher basis.  -- Try leaving 
opt_scheme at its default value.  -- For such a reaction (dissociation of such 
a polarized molecule) you should    expect a barrier, therefore CI_scheme 
should be anything except for no-CI.  -- The best is if you can specify the CI 
manually in theCLIMBING_IMAGES section    (choose the CI_scheme 
accordingly).Bests,  t On Tue, Oct 20, 2020 at 6:53 PM Omer Mutasim 
 wrote:>> Dear All> I'm doning NEB for dissociation 
reaction of SO2 to SO +O. But it is not converging for more than a week, and 
the path length is increasing.> Please tell me what is wrong in my input 
file:>> below is the input & output files:>> Input file:>> BEGIN> 
BEGIN_PATH_INPUT> >  restart_mode      = 'restart'>  string_method    = 
'neb',>  nstep_path        = 800,>  ds                = 1.D0,>  opt_scheme      
  = "broyden",>  num_of_images    = 7,>  CI_scheme        = 'no-CI',>  path_thr 
         = 0.05D0,>> /> END_PATH_INPUT> BEGIN_ENGINE_INPUT> >    
calculation  = "relax"> prefix = 'SO2_neb'>    outdir = './outdir'>    
pseudo_dir = '/home/yQE-test/pseudo/'> restart_mode = 'from_scratch'>    
forc_conv_thr =  1.0e-03> etot_conv_thr = 1e-04>    nstep        = 200>    
!tefield = .TRUE> !dipfield = .TRUE> />> > ibrav = 0>    ecutrho         
         =  270>    ecutwfc                  =  45>    nat                      
= 111>    ntyp                      = 4> 
occupations='smearing',smearing='gaussian',degauss=0.005> vdw_corr = 'DFT-D2'> 
!edir = 3 , emaxpos = 0.6808, eopreg = 0.08 , eamp = 0.001,>    nspin = 2> 
starting_magnetization(1)=  0.01>> /> >    conv_thr        = 1e-06>   
 electron_maxstep = 200> mixing_mode ='local-TF'>    mixing_beta      =  0.3>> 
/>> > />> K_POINTS {automatic}> 3 3 1 0 0 1>> ATOMIC_SPECIES> Ni 58.69340 
Ni.pbe-n-rrkjus_psl.0.1.UPF> P 30.97376 P.pbe-n-rrkjus_psl.1.0.0.UPF> S 32.065  
    S.pbe-n-rrkjus_psl.1.0.0.UPF> O 15.    O.pbe-n-rrkjus_psl.1.0.0.UPF> 
CELL_PARAMETERS {angstrom}>        11.765383541833        0.00        
0.00>        -5.88269177091652        10.1891210324947    0.00> 
       0.00        0.00        30.9938690567585> 
BEGIN_POSITIONS> FIRST_IMAGE> ATOMIC_POSITIONS (angstrom)> S      -1.181561037  
6.155418563  12.124345096> O      -1.100425541  4.672437254  11.356300976> O    
    0.190308001  6.839217965  11.448732238> Ni      -2.738525121  4.763450297  
0.239145520> Ni      3.139579474  1.358483744  0.232252034> Ni      3.135766403 
 8.150575392  0.235327906> Ni      -4.673593720  8.104467836  1.780118367> .> 
.> .> .>> output file:>> Program NEB v.6.4.1 starts on 16Oct2020 at 11:35:32>>  
    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);>          "P. Giannozzi et al., J. 
Phys.:Condens. Matter 29 465901 (2017);>          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), running on 
   80 processors>>      MPI processes distributed on    5 nodes>      R & G 
space division:  proc/nbgrp/npool/nimage =      80>>      parsing_file_name: 
input.in>      Reading 

Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x

[Timrov Iurii]

> Is it possiable for me to iterate on the result of the first solution
> to achieve more precise results?


I do not understand your question.


Please do not forget to add your affiliation.


Iurii


--
Dr. Iurii TIMROV
Postdoctoral Researcher
STI - IMX - THEOS and NCCR - MARVEL
Swiss Federal Institute of Technology Lausanne (EPFL)
CH-1015 Lausanne, Switzerland
+41 21 69 34 881
http://people.epfl.ch/265334

From: users  on behalf of Hongyi Zhao 

Sent: Thursday, October 22, 2020 11:49:52 AM
To: Quantum ESPRESSO users Forum
Subject: Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x

On Thu, Oct 22, 2020 at 4:41 PM Timrov Iurii  wrote:
>
> Dear Mohammad,
>
>
> > Is it related to the diagonalization algorithm?
>
>
> No
>
>
> The problem is in the postprocessing step of the HP calculation. In your 
> calculation you perturbed only one Ni atom, and then the HP code tries to 
> reconstruct the whole response matrix chi [see Eq. (21) in PRB 98, 085127 
> (2018)] using the data for the perturbed Ni atom and by comparing interatomic 
> distances between Ni atoms. The problem is that the interatomic distances 
> variations are larger than the hardcoded threshold of 6.d-4 Bohr. So there 
> are two possible solutions:
>
> Better relax the structure. Which convergence thresholds for energy and 
> forces did you use (etot_conv_thr and forc_conv_thr)? Try to reduce these 
> thresholds. In your current DFT+U-relaxed structure I think that the atomic 
> positions (in particular of Ni atoms) are not very accurate, and hence the 
> Ni-Ni distances have large variations, and hence the HP code stops. In fact, 
> if you perform the HP calculation without specifying "perturb_only_atom(1) = 
> .true." I think that the code will detect that more than one Ni atom must be 
> perturbed.
> Adjust the parameter eps_dist in PW/src/ldaU.f90 to a larger value (I think 
> in your case the value of 4.d-3 Bohr should be fine, based on your data, but 
> please check), recompile the pw.x and hp.x codes, and re-run the last step of 
> the HP calculation using "hp_compute_hp.in".
>
>
> The second solution is faster but maybe less accurate. The first solution is 
> longer but more accurate.

Is it possiable for me to iterate on the result of the first solution
to achieve more precise results?

Sincerely,
HY

>
> Greetings,
> Iurii
>
>
> --
> Dr. Iurii TIMROV
> Postdoctoral Researcher
> STI - IMX - THEOS and NCCR - MARVEL
> Swiss Federal Institute of Technology Lausanne (EPFL)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
> http://people.epfl.ch/265334
> 
> From: users  on behalf of Mohammad 
> Moaddeli 
> Sent: Wednesday, October 21, 2020 7:28:29 PM
> To: Quantum ESPRESSO users Forum
> Subject: Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x
>
> Dear Iurii,
>
> I appreciate all your considerations. I could handle the HP run and the U 
> parameter for Ni is calculated. Based on your suggestions on pw_forum, all 
> atomic positions were fully relaxed with the new U parameter in order to 
> perform a self-consistent loop calculation and compute the U parameter again 
> until no meaningful difference between two consecutive computed "U"s was 
> observed. Since I encountered the " problems computing cholesky " error, PARO 
> diagonalization was used. Although hp.x went well for all q points, there was 
> an error in computing U. Is it related to the diagonalization algorithm?
>
> Order of calculations:
> =-=
> pw.x -input scf.in > scf.out
> hp.x -input hp1.in > hp1.out   # for q point number 1
> hp.x -input hp2.in > hp2.out
> hp.x -input hp3.in > hp3.out
> hp.x -input hp4.in > hp4.out
> hp.x -input hp_sum.in > hp_sum.out
> hp.x -input hp_compute_hp.in > hp_compute_hp.out
> =-=
>
> A google drive link is provided as following:
> https://drive.google.com/file/d/1SCNNOfcJGZPAM4gpgXThkTvsibv-ijNv/view?usp=sharing
>
> With best regards,
>
> Mohammad
> ShirazU
>
>
>
> On Tue, Oct 13, 2020 at 2:32 PM Timrov Iurii  wrote:
>>
>> Dear Mohammad,
>>
>>
>> > There are 4 q points in hp.out:
>>
>>
>> Ok. I was looking at the old files that you shared and there were 6 q 
>> points. Probably you have changed something in your PW input, and now you 
>> have more symmetries and hence fewer q points.
>>
>>
>> To solve the convergence problem for the q point #4 I suggest to use 
>> conv_thr_chi = 3.0d-5 instead of conv_thr_chi = 1.0d-5. Indeed, the residue 
>> for q#4 is below 3.d-5 after 25 iterations:
>>
>>
>>   atom #  1   q point #   4   iter #  25
>>   chi:   1  -0.0982377516   residue:0.065024
>>   chi:   2  -0.089671   residue:0.205352
>>   chi:   3  -0.484762   residue:0.067400
>>   chi:   4  -0.00   residue:0.00
>>   chi:   5 

Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x

[Hongyi Zhao]

On Thu, Oct 22, 2020 at 4:41 PM Timrov Iurii  wrote:
>
> Dear Mohammad,
>
>
> > Is it related to the diagonalization algorithm?
>
>
> No
>
>
> The problem is in the postprocessing step of the HP calculation. In your 
> calculation you perturbed only one Ni atom, and then the HP code tries to 
> reconstruct the whole response matrix chi [see Eq. (21) in PRB 98, 085127 
> (2018)] using the data for the perturbed Ni atom and by comparing interatomic 
> distances between Ni atoms. The problem is that the interatomic distances 
> variations are larger than the hardcoded threshold of 6.d-4 Bohr. So there 
> are two possible solutions:
>
> Better relax the structure. Which convergence thresholds for energy and 
> forces did you use (etot_conv_thr and forc_conv_thr)? Try to reduce these 
> thresholds. In your current DFT+U-relaxed structure I think that the atomic 
> positions (in particular of Ni atoms) are not very accurate, and hence the 
> Ni-Ni distances have large variations, and hence the HP code stops. In fact, 
> if you perform the HP calculation without specifying "perturb_only_atom(1) = 
> .true." I think that the code will detect that more than one Ni atom must be 
> perturbed.
> Adjust the parameter eps_dist in PW/src/ldaU.f90 to a larger value (I think 
> in your case the value of 4.d-3 Bohr should be fine, based on your data, but 
> please check), recompile the pw.x and hp.x codes, and re-run the last step of 
> the HP calculation using "hp_compute_hp.in".
>
>
> The second solution is faster but maybe less accurate. The first solution is 
> longer but more accurate.

Is it possiable for me to iterate on the result of the first solution
to achieve more precise results?

Sincerely,
HY

>
> Greetings,
> Iurii
>
>
> --
> Dr. Iurii TIMROV
> Postdoctoral Researcher
> STI - IMX - THEOS and NCCR - MARVEL
> Swiss Federal Institute of Technology Lausanne (EPFL)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
> http://people.epfl.ch/265334
> 
> From: users  on behalf of Mohammad 
> Moaddeli 
> Sent: Wednesday, October 21, 2020 7:28:29 PM
> To: Quantum ESPRESSO users Forum
> Subject: Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x
>
> Dear Iurii,
>
> I appreciate all your considerations. I could handle the HP run and the U 
> parameter for Ni is calculated. Based on your suggestions on pw_forum, all 
> atomic positions were fully relaxed with the new U parameter in order to 
> perform a self-consistent loop calculation and compute the U parameter again 
> until no meaningful difference between two consecutive computed "U"s was 
> observed. Since I encountered the " problems computing cholesky " error, PARO 
> diagonalization was used. Although hp.x went well for all q points, there was 
> an error in computing U. Is it related to the diagonalization algorithm?
>
> Order of calculations:
> =-=
> pw.x -input scf.in > scf.out
> hp.x -input hp1.in > hp1.out   # for q point number 1
> hp.x -input hp2.in > hp2.out
> hp.x -input hp3.in > hp3.out
> hp.x -input hp4.in > hp4.out
> hp.x -input hp_sum.in > hp_sum.out
> hp.x -input hp_compute_hp.in > hp_compute_hp.out
> =-=
>
> A google drive link is provided as following:
> https://drive.google.com/file/d/1SCNNOfcJGZPAM4gpgXThkTvsibv-ijNv/view?usp=sharing
>
> With best regards,
>
> Mohammad
> ShirazU
>
>
>
> On Tue, Oct 13, 2020 at 2:32 PM Timrov Iurii  wrote:
>>
>> Dear Mohammad,
>>
>>
>> > There are 4 q points in hp.out:
>>
>>
>> Ok. I was looking at the old files that you shared and there were 6 q 
>> points. Probably you have changed something in your PW input, and now you 
>> have more symmetries and hence fewer q points.
>>
>>
>> To solve the convergence problem for the q point #4 I suggest to use 
>> conv_thr_chi = 3.0d-5 instead of conv_thr_chi = 1.0d-5. Indeed, the residue 
>> for q#4 is below 3.d-5 after 25 iterations:
>>
>>
>>   atom #  1   q point #   4   iter #  25
>>   chi:   1  -0.0982377516   residue:0.065024
>>   chi:   2  -0.089671   residue:0.205352
>>   chi:   3  -0.484762   residue:0.067400
>>   chi:   4  -0.00   residue:0.00
>>   chi:   5  -0.333051   residue:0.117502
>>   chi:   6  -0.089671   residue:0.205352
>>   chi:   7   0.0032070938   residue:0.015134
>>   chi:   8  -0.089671   residue:0.205352
>>   chi:   9  -0.333051   residue:0.117502
>>   chi:  10   0.00   residue:0.00
>>   chi:  11  -0.484762   residue:0.067400
>>   chi:  12  -0.089671   residue:0.205352
>>   Average number of iter. to solve lin. system:   30.0
>>   Total CPU time : 85250.2 s
>>
>>
>> Greetings,
>>
>> Iurii
>>
>>
>> --
>> Dr. Iurii TIMROV
>> Postdoctoral 

Re: [QE-users] pp.x does not seem to finish

[Pietro Delugas]

sorry I thought the execution of PW went fine.

It seems you have compiled the program for serial execution and then 
linked to parallel libraries.


you should configure for parallel execution and recompile the codes.

if it doesn't work, could you send me the make.inc file for checking  ?

Pietro


On 22/10/20 10:16, Thanh-Nam Huynh wrote:

Dear Pietro and Marcelo Albuquerque,

I followed your instructions and the job has done greatly. However. 
there is something weird in the output file. When I set 
OMP_NUM_THREADS=64 and ran

mpirun -np 2 ...
in the output, the first lines were printed out twice.
Meanwhile, when I set OMP_NUM_THREADS=1 and ran
mpirun -np 40 ...
every line was printed out 40 times in the output file.
Something like this:
     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     1934.7 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2017.0 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2027.3 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2062.5 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2062.5 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2069.4 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2070.5 secs

     Self-consistent Calculation

     iteration #  1     ecut=    50.00 Ry     beta= 0.30
     Davidson diagonalization with overlap

     total cpu time spent up to now is     2089.3 secs

I am not sure whether it affects the calculation time (I think it 
may), but it is really annoying. Do you have any idea about this 
problem and how to solve it? Thank you very much!

--
*Huynh Thanh-Nam*
Department of Materials Science and Engineering, Chungnam National 
University

Yuseong-gu, Daejeon 34134, Korea
Tel: (+82) 010 5719 1521

___
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
___
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] Calculating U parameter for Ni in LiNiO2 using hp.x

[Timrov Iurii]

Dear Mohammad,


> Is it related to the diagonalization algorithm?


No


The problem is in the postprocessing step of the HP calculation. In your 
calculation you perturbed only one Ni atom, and then the HP code tries to 
reconstruct the whole response matrix chi [see Eq. (21) in PRB 98, 085127 
(2018)] using the data for the perturbed Ni atom and by comparing interatomic 
distances between Ni atoms. The problem is that the interatomic distances 
variations are larger than the hardcoded threshold of 6.d-4 Bohr. So there are 
two possible solutions:

  1.  Better relax the structure. Which convergence thresholds for energy and 
forces did you use (etot_conv_thr and forc_conv_thr)? Try to reduce these 
thresholds. In your current DFT+U-relaxed structure I think that the atomic 
positions (in particular of Ni atoms) are not very accurate, and hence the 
Ni-Ni distances have large variations, and hence the HP code stops. In fact, if 
you perform the HP calculation without specifying "perturb_only_atom(1) = 
.true." I think that the code will detect that more than one Ni atom must be 
perturbed.
  2.  Adjust the parameter eps_dist in PW/src/ldaU.f90 to a larger value (I 
think in your case the value of 4.d-3 Bohr should be fine, based on your data, 
but please check), recompile the pw.x and hp.x codes, and re-run the last step 
of the HP calculation using "hp_compute_hp.in".

The second solution is faster but maybe less accurate. The first solution is 
longer but more accurate.

Greetings,
Iurii


--
Dr. Iurii TIMROV
Postdoctoral Researcher
STI - IMX - THEOS and NCCR - MARVEL
Swiss Federal Institute of Technology Lausanne (EPFL)
CH-1015 Lausanne, Switzerland
+41 21 69 34 881
http://people.epfl.ch/265334

From: users  on behalf of Mohammad 
Moaddeli 
Sent: Wednesday, October 21, 2020 7:28:29 PM
To: Quantum ESPRESSO users Forum
Subject: Re: [QE-users] Calculating U parameter for Ni in LiNiO2 using hp.x

Dear Iurii,

I appreciate all your considerations. I could handle the HP run and the U 
parameter for Ni is calculated. Based on your suggestions on pw_forum, all 
atomic positions were fully relaxed with the new U parameter in order to 
perform a self-consistent loop calculation and compute the U parameter again 
until no meaningful difference between two consecutive computed "U"s was 
observed. Since I encountered the " problems computing cholesky " error, PARO 
diagonalization was used. Although hp.x went well for all q points, there was 
an error in computing U. Is it related to the diagonalization algorithm?

Order of calculations:
=-=
pw.x -input scf.in > scf.out
hp.x -input hp1.in > hp1.out   # for q point number 1
hp.x -input hp2.in > hp2.out
hp.x -input hp3.in > hp3.out
hp.x -input hp4.in > hp4.out
hp.x -input hp_sum.in > hp_sum.out
hp.x -input hp_compute_hp.in > hp_compute_hp.out
=-=

A google drive link is provided as following:
https://drive.google.com/file/d/1SCNNOfcJGZPAM4gpgXThkTvsibv-ijNv/view?usp=sharing

With best regards,

Mohammad
ShirazU



On Tue, Oct 13, 2020 at 2:32 PM Timrov Iurii 
mailto:iurii.tim...@epfl.ch>> wrote:

Dear Mohammad,


> There are 4 q points in hp.out:


Ok. I was looking at the old files that you shared and there were 6 q points. 
Probably you have changed something in your PW input, and now you have more 
symmetries and hence fewer q points.


To solve the convergence problem for the q point #4 I suggest to use 
conv_thr_chi = 3.0d-5 instead of conv_thr_chi = 1.0d-5. Indeed, the residue for 
q#4 is below 3.d-5 after 25 iterations:


  atom #  1   q point #   4   iter #  25
  chi:   1  -0.0982377516   residue:0.065024
  chi:   2  -0.089671   residue:0.205352
  chi:   3  -0.484762   residue:0.067400
  chi:   4  -0.00   residue:0.00
  chi:   5  -0.333051   residue:0.117502
  chi:   6  -0.089671   residue:0.205352
  chi:   7   0.0032070938   residue:0.015134
  chi:   8  -0.089671   residue:0.205352
  chi:   9  -0.333051   residue:0.117502
  chi:  10   0.00   residue:0.00
  chi:  11  -0.484762   residue:0.067400
  chi:  12  -0.089671   residue:0.205352
  Average number of iter. to solve lin. system:   30.0
  Total CPU time : 85250.2 s


Greetings,

Iurii


--
Dr. Iurii TIMROV
Postdoctoral Researcher
STI - IMX - THEOS and NCCR - MARVEL
Swiss Federal Institute of Technology Lausanne (EPFL)
CH-1015 Lausanne, Switzerland
+41 21 69 34 881
http://people.epfl.ch/265334

From: users 
mailto:users-boun...@lists.quantum-espresso.org>>
 on 

Re: [QE-users] pp.x does not seem to finish

[Paolo Giannozzi]

On Thu, Oct 22, 2020 at 10:17 AM Thanh-Nam Huynh 
wrote:


> When I set OMP_NUM_THREADS=64 and ran
> mpirun -np 2 ...
> in the output, the first lines were printed out twice.
>
Meanwhile, when I set OMP_NUM_THREADS=1 and ran
> mpirun -np 40 ...
> every line was printed out 40 times in the output file.
>

your executable is compiled for serial execution (that is: no MPI). You are
running N independent copies of the same executable, one copy per processor.

Paolo

>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 1934.7 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2017.0 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2027.3 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2062.5 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2062.5 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2069.4 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2070.5 secs
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=50.00 Ry beta= 0.30
>  Davidson diagonalization with overlap
>
>  total cpu time spent up to now is 2089.3 secs
>
> I am not sure whether it affects the calculation time (I think it may),
> but it is really annoying. Do you have any idea about this problem and how
> to solve it? Thank you very much!
> --
> *Huynh Thanh-Nam*
> Department of Materials Science and Engineering, Chungnam National
> University
> Yuseong-gu, Daejeon 34134, Korea
> Tel: (+82) 010 5719 1521
> ___
> 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



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

Re: [QE-users] pp.x does not seem to finish

[Thanh-Nam Huynh]

Dear Pietro and Marcelo Albuquerque,

I followed your instructions and the job has done greatly. However. there
is something weird in the output file. When I set OMP_NUM_THREADS=64 and ran
mpirun -np 2 ...
in the output, the first lines were printed out twice.
Meanwhile, when I set OMP_NUM_THREADS=1 and ran
mpirun -np 40 ...
every line was printed out 40 times in the output file.
Something like this:
 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 1934.7 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2017.0 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2027.3 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2062.5 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2062.5 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2069.4 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2070.5 secs

 Self-consistent Calculation

 iteration #  1 ecut=50.00 Ry beta= 0.30
 Davidson diagonalization with overlap

 total cpu time spent up to now is 2089.3 secs

I am not sure whether it affects the calculation time (I think it may), but
it is really annoying. Do you have any idea about this problem and how to
solve it? Thank you very much!
-- 
*Huynh Thanh-Nam*
Department of Materials Science and Engineering, Chungnam National
University
Yuseong-gu, Daejeon 34134, Korea
Tel: (+82) 010 5719 1521
___
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