date:20170207

Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault

2017-02-07 Thread Yasser Fowad AlWahedi

Thanks for your kind words. The library mkl_gf_lp64 was caught by the 
configuration script after sourcing the mkl libraries. 

Yasser

-Original Message-
From: pw_forum-boun...@pwscf.org [mailto:pw_forum-boun...@pwscf.org] On Behalf 
Of Davide Ceresoli
Sent: Monday, January 30, 2017 3:04 PM
To: PWSCF Forum 
Subject: Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault

Dear Yasser,
 I'm glad it works! notwithstanding that you link the gfortran MKL 
(mkl_gf_lp64), zdotc still need a workaround, interesting!
It seems to me that you are already using FFT from MKL (-D__DFTI).

Best,
 Davide



On 01/29/2017 04:21 PM, Yasser Fowad AlWahedi wrote:
> Dear Paolo and Davide,
>
> Thank you so much for your kind help.  I have tested solutions 1,2 and 4 
> since the 3 was not applicable.  Two solutions of the suggested ones worked. 
> For the sake of record; I have put below the details of my trials and the 
> outcomes I got as to help any one who might be facing this problem in the 
> future.
>
>
> My GNU compilers versions is: GNU Fortran (Ubuntu 
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>
> the successful make.inc file is attached.
>
>
> Solution 1 (failed):  I modified the greenfunction.f90 in the src under gipaw 
> to:
>
> eprec (ibnd) = 1.35d0 * sum(conjg(evq(1:npw,ibnd))*work(1:npw)) !zdotc 
> (npw, evq (1, ibnd), 1, work, 1)
>
> recompiled gipaw.x and tested again, here I got the following error
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
>
> Backtrace for this error:
> #0  0x7F6A0A0A6E08
> #1  0x7F6A0A0A5F90
> #0  0x7F2817102E08
> #2  0x7F6A095BB4AF
> #1  0x7F2817101F90
> #2  0x7F28166174AF
> #3  0x7F6A0CF5B2CD
> #3  0x7F2819FB72CD
> #0  0x7FB0AF7DBE08
> #0  0x7F334BB99E08
> #0  0x7FCA597BCE08
> #1  0x7FB0AF7DAF90
> #1  0x7F334BB98F90
> #1  0x7FCA597BBF90
> #2  0x7FCA58CD14AF
> #2  0x7FB0AECF04AF
> #3  0x#2  0x7F334B0AE4AF
> #3  0x7FCA5C6712CD
> 7FB0B26902CD
> #3  0x7F334EA4E2CD
> #0  0x7FAB00A1DE08
> #1  0x7FAB00A1CF90
> #0  0x7F9E42A5DE08
> #2  0x7FAAFFF324AF
> #3  0x7FAB038D22CD
> #1  0x7F9E42A5CF90
> #2  0x7F9E41F724AF
> #3  0x7F9E459122CD
> #0  0x7F6E3302AE08
> #1  0x7F6E33029F90
> #2  0x7F6E3253F4AF
> #3  0x7F6E35EDF2CD
> #0  0x7F7F133A2E08
> #0  0x7F1935284E08
> #1  0x7F7F133A1F90
> #1  0x7F1935283F90
> #2  0x7F7F128B74AF
> #2  0x7F19347994AF
> #3  0x7F7F162572CD
> #3  0x7F19381392CD
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #4  0x412E66 in cgsolve_all_ at cgsolve_all.f90:148 (discriminator 2)
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routi

Re: [Pw_forum] A possible bug in epsilon.f90

2017-02-07 Thread Marton

Thanks, indeed! Apparently, I only used epsilon.x with nspin=1 :) I agree
that your suggestion fixes the nspin=2 case but I think it does not cover
the nspin=4 case, so I believe the check on the bands from PW/src/setup.f90
would be more general:

  USE constants, ONLY : degspin

...

 IF ( nbnd <= NINT( nelec / degspin ) ) &
CALL errore( 'epsilon', 'too few bands', 1 )
 IF ( nbnd <= NINT( nelec ) .AND. nspin==4 ) &
CALL errore( 'epsilon', 'too few bands', 1 )

degspin is set to 2 in Modules/constants.f90 and I guess it is recommended
to use for clarity. I'm not sure whether testing for nspin==4 or noncolin
is favored by the developers.

Marton

On Tue, Feb 7, 2017 at 11:45 AM, Jia Chen  wrote:

> Dear Marton Voros,
>
> I attached a simple example to this email. And epsilon calculation ended
> with "bad band number" error. QE version is 6.0.
>
> Cheers
>
> On Tue, Feb 7, 2017 at 10:48 AM, Marton  wrote:
>
>> Can you please be more specific? Do you have an example that you expect
>> to work but has problems?
>>
>> Marton
>>
>> On Feb 6, 2017 11:09 PM, "Jia Chen"  wrote:
>>
>>> Hi Marton,
>>>
>>> Yes, I am aware of that. I think there is a issue with nspin=2, nspin=1
>>> is totally fine.
>>>
>>> On Mon, Feb 6, 2017 at 11:15 PM, Marton  wrote:
>>>
 Hi Jia,

 I don't think there is a bug there. If you go a few lines above in the
 same file, you find, for example:

  IF ( nspin == 1) full_occ = 2.0d0

 which means that full_occ takes care of the occupations.

 HTH

 Marton Voros

 --
 Aneesur Rahman Fellow
 Materials Science Division
 Argonne National Laboratory


 On Mon, Feb 6, 2017 at 3:27 PM, Jia Chen  wrote:

> Dear All,
>
> I am suspicious that a bud exit in epsilon.f90 qe-6.0. The check of
> nbnd:
> ===
> IF ( REAL(nbnd,DP)*full_occ <= nelec ) CALL errore('epsilon', 'bad
> band number', 1)
> ===
> I think it should be:
> REAL(nbnd,DP)*full_occ <= nelec/2.0
>
> Let me know if I missed something...
>
> Cheers
> Jia
>
> ___
> 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

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

[Pw_forum] QE 6 compilation

2017-02-07 Thread Mofrad, Amir Mehdi (MU-Student)

Dear QE users and developers,


I have been trying to compile QE 6.0 on a cluster for a couple of times but not 
have been successful yet. At first, I was getting the PZUNMTR parameter number 
error that I think I fixed it using

./configure --with-scalapack=openmpi

However, in my error file I get the following error that don't know what it is 
about:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PC   
  RoutineLineSource
pw.x   00CC3265   
Unknown   Unknown  Unknown
pw.x   00CC0E87   
Unknown   Unknown  Unknown
pw.x   00C5B374
Unknown   Unknown  Unknown
pw.x   00C5B186
Unknown   Unknown  Unknown
pw.x   00BE3B46
Unknown   Unknown  Unknown
pw.x   00BEABE0   
Unknown   Unknown  Unknown
libc.so.6  2B1DBD61A250  
Unknown   Unknown  Unknown
libmpi.so.20   2B1DBCCEEFC5 Unknown 
  Unknown  Unknown
libmkl_blacs_inte  2B1DB9601E09  Unknown
   Unknown  Unknown
libmkl_blacs_inte  2B1DB960044D  Unknown
   Unknown  Unknown
libmkl_blacs_inte  2B1DB95F19CC Unknown 
  Unknown  Unknown
libmkl_blacs_inte  2B1DB95F1391   Unknown   
Unknown  Unknown
pw.x   00838CAB  mp_diag_mp_mp_sta  78  mp_diag.f90
pw.x   0083A2DB  mp_global_mp_mp_s  96  
mp_global.f90
pw.x   0040D2B2  MAIN__ 24  pwscf.f90
pw.x   0040D25E  
Unknown   Unknown  Unknown
libc.so.6  2B1DBD606B35
Unknown   Unknown  Unknown
pw.x   0040D169
Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
pw.x   00CC3265   
Unknown   Unknown  Unknown
pw.x   00CC0E87   
Unknown   Unknown  Unknown
pw.x   00C5B374   
Unknown   Unknown  Unknown
pw.x   00C5B186  Unknown   Unknown  Unknown
pw.x   00BE3B46  Unknown   Unknown  Unknown
pw.x   00BEABE0  Unknown   Unknown  Unknown
libc.so.6  2B514C9CE250  Unknown   Unknown  Unknown
libmpi.so.20   2B514C0A2FC5  Unknown   Unknown  Unknown
libmkl_blacs_inte  2B51489B5E09  Unknown   Unknown  Unknown
libmkl_blacs_inte  2B51489B444D  Unknown   Unknown  Unknown
libmkl_blacs_inte  2B51489A59CC  Unknown   Unknown  Unknown
libmkl_blacs_inte  2B51489A5391  Unknown   Unknown  Unknown
pw.x   00838CAB  mp_diag_mp_mp_sta  78  mp_diag.f90
pw.x   0083A2DB  mp_global_mp_mp_s  96  
mp_global.f90
pw.x   0040D2B2  MAIN__ 24  pwscf.f90
pw.x   0040D25E  Unknown   Unknown  Unknown
libc.so.6  2B514C9BAB35  Unknown   Unknown  Unknown
pw.x   0040D169  Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
pw.x   00CC3265  Unknown   Unknown  Unknown



Any help would be appreciated.


Best,


Amir M. Mofrad

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

Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

2017-02-07 Thread Louis Fry-Bouriaux

Hi Lorenzo,


   Thank you for speedy reply!


Interesting, I will try that, I will add that I tried the calculation with 
lelfield=.true. and all efield_cart values to zero and it gives me the same 
error. I also reduced the number of auto k points to speed up testing (auto: 6 
2 2 0 0 0/ nppstr=6, which takes ~160s). I may take a look at the code maybe 
there is something that can be done if I identify what is going on :/


Thanks!

Louis


From: pw_forum-boun...@pwscf.org  on behalf of 
Lorenzo Paulatto 
Sent: 07 February 2017 18:08:35
To: PWSCF Forum
Subject: Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation 
in trigonal cell


To be honest I do not remember, what I rmember is that if the field is not

along z (or the third axis) then it will have (had?) a huge bottleneck in

parallel which will make it unusable with more than a couple of cpus.

hth



On Tuesday, February 7, 2017 5:09:03 PM CET Louis Fry-Bouriaux wrote:

> Hi there,

>

> I am trying to perform a berry phase calculation with a homogeneous electric 
> field (lelfield=.true.) however I receive the "wrong k-strings?" in c_phase 
> error while running in parallel with OpenMPI on 4 processors:

> >From the documentation, if K_POINTS is automatic, then field strength

> >should be specified in cartesian coordinates (efield_cart(i)) and 'efield'

> >is not used, however reading the berry phase documentation says that the

> >direction of the efield is taken along gdir when a homogeneous electric

> >field is applied.

> Must I still specify efield_cart values when gdir is specified (it would

> seem so)? The code doesn't complain until after bandstructure computation.

> I have tried efield calculation with the following specification (see below

> for input file used):

>

>

> efield_cart(1) = 0.0001,

>

> efield_cart(2) = 0,

>

> efield_cart(3) = 0,

>

>

> which results in the electric field existing in two directions in crystal

> reference system, but the error is the same whether I do or do not include

> these fields and leave efield=0.0001

>

>

> My process is as follows:

>

> - scf calculation of trigonal alpha-Al2O3 cell (input crystal is correct)

>

> - band structure calculation

>

> - Berry phase calculation *without* electric field (this works and output

> is correct) with input:

>

>

> &CONTROL

> title = 'alpha-Alumina' ,

> calculation = 'nscf' ,

> outdir = '${PWD}' ,

> pseudo_dir = '${PWD}/pseudo/' ,

> verbosity = 'high' ,

> prefix = 'run_${RUN_NUMBER}',

> lberry = .true.,

> gdir = 1,

> nppstr = 10,

> lelfield = .false.,

> nberrycyc = 1

> /

> &SYSTEM

> ibrav = 5,

> A = 5.136,

> cosAB = 0.56956647115,

> nat = 10,

> ntyp = 2,

> occupations = 'fixed',

> ecutwfc = 50,

> ecutrho = 350,

> nbnd = 48

> /

> &ELECTRONS

> conv_thr = 1d-8,

> diagonalization = 'cg',

> mixing_beta = 0.7,

> electron_maxstep = 200,

> efield = 0,

> efield_phase = 'write'

> /

> ATOMIC_SPECIES

> O 15.99900 O.pbe-van_ak.UPF

> Al 26.98200 Al.pbe-n-van.UPF

> ATOMIC_POSITIONS crystal

> O 0.55600 0.94400 0.25000

> O 0.44400 0.05600 0.75000

> O 0.25000 0.55600 0.94400

> O 0.75000 0.44400 0.05600

> O 0.94400 0.25000 0.55600

> O 0.05600 0.75000 0.44400

> Al 0.35200 0.35200 0.35200

> Al 0.64800 0.64800 0.64800

> Al 0.14800 0.14800 0.14800

> Al 0.85200 0.85200 0.85200

> K_POINTS automatic

> 10 4 4 0 0 0

>

> - Then Berry phase calculation *with* electric field:

>

>

> &CONTROL

> title = 'alpha-Alumina' ,

> calculation = 'nscf' ,

> outdir = '${PWD}' ,

> pseudo_dir = '${PWD}/pseudo/' ,

> verbosity = 'high' ,

> prefix = 'run_${RUN_NUMBER}',

> lberry = .true.,

> gdir = 1,

> nppstr = 10,

> lelfield = .true.,

> nberrycyc = 1

> /

> &SYSTEM

> ibrav = 5,

> A = 5.136,

> cosAB = 0.56956647115,

> nat = 10,

> ntyp = 2,

> occupations = 'fixed',

> ecutwfc = 50,

> ecutrho = 350,

> nbnd = 48,

> nosym = .false.

> /

> &ELECTRONS

> conv_thr = 1d-8,

> diagonalization = 'cg',

> mixing_beta = 0.7,

> electron_maxstep = 200,

> efield = 0.0001,

> efield_phase = 'read'

> /

> ATOMIC_SPECIES

> O 15.99900 O.pbe-van_ak.UPF

> Al 26.98200 Al.pbe-n-van.UPF

> ATOMIC_POSITIONS crystal

> O 0.55600 0.94400 0.25000

> O 0.44400 0.05600 0.75000

> O 0.25000 0.55600 0.94400

> O 0.75000 0.44400 0.05600

> O 0.94400 0.25000 0.55600

> O 0.05600 0.75000 0.44400

> Al 0.35200 0.35200 0.35200

> Al 0.64800 0.64800 0.64800

> Al 0.14800 0.14800 0.14800

> Al 0.85200 0.85200 0.85200

> K_POINTS automatic

> 10 4 4 0 0 0

>

> My last thought is that when the electric field is specified in cartesian

> coordinates as above, the fact that the field in the crystal reference

> system is along two directions causes the problem, I ha

Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

2017-02-07 Thread Lorenzo Paulatto

To be honest I do not remember, what I rmember is that if the field is not 
along z (or the third axis) then it will have (had?) a huge bottleneck in 
parallel which will make it unusable with more than a couple of cpus. 
hth

On Tuesday, February 7, 2017 5:09:03 PM CET Louis Fry-Bouriaux wrote:
> Hi there,
> 
> I am trying to perform a berry phase calculation with a homogeneous 
> electric 
field (lelfield=.true.) however I receive the "wrong k-strings?" in c_phase 
error while 
running in parallel with OpenMPI on 4 processors:
> >From the documentation, if K_POINTS is automatic, then field strength
> >should be specified in cartesian coordinates (efield_cart(i)) and 'efield'
> >is not used, however reading the berry phase documentation says that the
> >direction of the efield is taken along gdir when a homogeneous electric
> >field is applied.
> Must I still specify efield_cart values when gdir is specified (it would
> seem so)? The code doesn't complain until after bandstructure computation.
> I have tried efield calculation with the following specification (see below
> for input file used):
> 
> 
> efield_cart(1) = 0.0001,
> 
> efield_cart(2) = 0,
> 
> efield_cart(3) = 0,
> 
> 
> which results in the electric field existing in two directions in crystal
> reference system, but the error is the same whether I do or do not include
> these fields and leave efield=0.0001
> 
> 
> My process is as follows:
> 
>  - scf calculation of trigonal alpha-Al2O3 cell (input crystal is correct)
> 
>  - band structure calculation
> 
>  - Berry phase calculation *without* electric field (this works and output
> is correct) with input:
> 
> 
>  &CONTROL
>title = 'alpha-Alumina' ,
>  calculation = 'nscf' ,
>   outdir = '${PWD}' ,
>   pseudo_dir = '${PWD}/pseudo/' ,
>verbosity = 'high' ,
>   prefix = 'run_${RUN_NUMBER}',
>   lberry = .true.,
> gdir = 1,
>   nppstr = 10,
> lelfield = .false.,
>nberrycyc = 1
>  /
>  &SYSTEM
>ibrav = 5,
>A = 5.136,
>cosAB = 0.56956647115,
>  nat = 10,
> ntyp = 2,
>  occupations = 'fixed',
>  ecutwfc = 50,
>  ecutrho = 350,
> nbnd = 48
>  /
>  &ELECTRONS
> conv_thr = 1d-8,
>  diagonalization =  'cg',
>  mixing_beta = 0.7,
> electron_maxstep = 200,
>   efield = 0,
> efield_phase = 'write'
>  /
> ATOMIC_SPECIES
> O   15.99900   O.pbe-van_ak.UPF
>Al   26.98200   Al.pbe-n-van.UPF
> ATOMIC_POSITIONS crystal
> O  0.556000.944000.25000
> O  0.444000.056000.75000
> O  0.250000.556000.94400
> O  0.750000.444000.05600
> O  0.944000.250000.55600
> O  0.056000.750000.44400
>Al  0.352000.352000.35200
>Al  0.648000.648000.64800
>Al  0.148000.148000.14800
>Al  0.852000.852000.85200
> K_POINTS automatic
>   10 4 4   0 0 0
> 
> - Then Berry phase calculation *with* electric field:
> 
> 
>  &CONTROL
>title = 'alpha-Alumina' ,
>  calculation = 'nscf' ,
>   outdir = '${PWD}' ,
>   pseudo_dir = '${PWD}/pseudo/' ,
>verbosity = 'high' ,
>   prefix = 'run_${RUN_NUMBER}',
>   lberry = .true.,
> gdir = 1,
>   nppstr = 10,
> lelfield = .true.,
>nberrycyc = 1
>  /
>  &SYSTEM
>ibrav = 5,
>A = 5.136,
>cosAB = 0.56956647115,
>  nat = 10,
> ntyp = 2,
>  occupations = 'fixed',
>  ecutwfc = 50,
>  ecutrho = 350,___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] A possible bug in epsilon.f90

2017-02-07 Thread Jia Chen

Dear Marton Voros,

I attached a simple example to this email. And epsilon calculation ended
with "bad band number" error. QE version is 6.0.

Cheers

On Tue, Feb 7, 2017 at 10:48 AM, Marton  wrote:

> Can you please be more specific? Do you have an example that you expect to
> work but has problems?
>
> Marton
>
> On Feb 6, 2017 11:09 PM, "Jia Chen"  wrote:
>
>> Hi Marton,
>>
>> Yes, I am aware of that. I think there is a issue with nspin=2, nspin=1
>> is totally fine.
>>
>> On Mon, Feb 6, 2017 at 11:15 PM, Marton  wrote:
>>
>>> Hi Jia,
>>>
>>> I don't think there is a bug there. If you go a few lines above in the
>>> same file, you find, for example:
>>>
>>>  IF ( nspin == 1) full_occ = 2.0d0
>>>
>>> which means that full_occ takes care of the occupations.
>>>
>>> HTH
>>>
>>> Marton Voros
>>>
>>> --
>>> Aneesur Rahman Fellow
>>> Materials Science Division
>>> Argonne National Laboratory
>>>
>>>
>>> On Mon, Feb 6, 2017 at 3:27 PM, Jia Chen  wrote:
>>>
 Dear All,

 I am suspicious that a bud exit in epsilon.f90 qe-6.0. The check of
 nbnd:
 ===
 IF ( REAL(nbnd,DP)*full_occ <= nelec ) CALL errore('epsilon', 'bad band
 number', 1)
 ===
 I think it should be:
 REAL(nbnd,DP)*full_occ <= nelec/2.0

 Let me know if I missed something...

 Cheers
 Jia

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


scf.in
Description: Binary data


epsilon.in
Description: Binary data
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

2017-02-07 Thread Louis Fry-Bouriaux

Hi there,


I am trying to perform a berry phase calculation with a homogeneous 
electric field (lelfield=.true.) however I receive the "wrong k-strings?" in 
c_phase error while running in parallel with OpenMPI on 4 processors:


>From the documentation, if K_POINTS is automatic, then field strength should 
>be specified in cartesian coordinates (efield_cart(i)) and 'efield' is not 
>used, however reading the berry phase documentation says that the direction of 
>the efield is taken along gdir when a homogeneous electric field is applied.


Must I still specify efield_cart values when gdir is specified (it would seem 
so)? The code doesn't complain until after bandstructure computation. I have 
tried efield calculation with the following specification (see below for input 
file used):


efield_cart(1) = 0.0001,

efield_cart(2) = 0,

efield_cart(3) = 0,


which results in the electric field existing in two directions in crystal 
reference system, but the error is the same whether I do or do not include 
these fields and leave efield=0.0001


My process is as follows:

 - scf calculation of trigonal alpha-Al2O3 cell (input crystal is correct)

 - band structure calculation

 - Berry phase calculation *without* electric field (this works and output is 
correct) with input:


 &CONTROL
   title = 'alpha-Alumina' ,
 calculation = 'nscf' ,
  outdir = '${PWD}' ,
  pseudo_dir = '${PWD}/pseudo/' ,
   verbosity = 'high' ,
  prefix = 'run_${RUN_NUMBER}',
  lberry = .true.,
gdir = 1,
  nppstr = 10,
lelfield = .false.,
   nberrycyc = 1
 /
 &SYSTEM
   ibrav = 5,
   A = 5.136,
   cosAB = 0.56956647115,
 nat = 10,
ntyp = 2,
 occupations = 'fixed',
 ecutwfc = 50,
 ecutrho = 350,
nbnd = 48
 /
 &ELECTRONS
conv_thr = 1d-8,
 diagonalization =  'cg',
 mixing_beta = 0.7,
electron_maxstep = 200,
  efield = 0,
efield_phase = 'write'
 /
ATOMIC_SPECIES
O   15.99900   O.pbe-van_ak.UPF
   Al   26.98200   Al.pbe-n-van.UPF
ATOMIC_POSITIONS crystal
O  0.556000.944000.25000
O  0.444000.056000.75000
O  0.250000.556000.94400
O  0.750000.444000.05600
O  0.944000.250000.55600
O  0.056000.750000.44400
   Al  0.352000.352000.35200
   Al  0.648000.648000.64800
   Al  0.148000.148000.14800
   Al  0.852000.852000.85200
K_POINTS automatic
  10 4 4   0 0 0

- Then Berry phase calculation *with* electric field:


 &CONTROL
   title = 'alpha-Alumina' ,
 calculation = 'nscf' ,
  outdir = '${PWD}' ,
  pseudo_dir = '${PWD}/pseudo/' ,
   verbosity = 'high' ,
  prefix = 'run_${RUN_NUMBER}',
  lberry = .true.,
gdir = 1,
  nppstr = 10,
lelfield = .true.,
   nberrycyc = 1
 /
 &SYSTEM
   ibrav = 5,
   A = 5.136,
   cosAB = 0.56956647115,
 nat = 10,
ntyp = 2,
 occupations = 'fixed',
 ecutwfc = 50,
 ecutrho = 350,
nbnd = 48,
   nosym = .false.
 /
 &ELECTRONS
conv_thr = 1d-8,
 diagonalization =  'cg',
 mixing_beta = 0.7,
electron_maxstep = 200,
  efield = 0.0001,
efield_phase = 'read'
 /
ATOMIC_SPECIES
O   15.99900   O.pbe-van_ak.UPF
   Al   26.98200   Al.pbe-n-van.UPF
ATOMIC_POSITIONS crystal
O  0.556000.944000.25000
O  0.444000.056000.75000
O  0.250000.556000.94400
O  0.750000.444000.05600
O  0.944000.250000.55600
O  0.056000.750000.44400
   Al  0.352000.352000.35200
   Al  0.648000.648000.64800
   Al  0.148000.148000.14800
   Al  0.852000.852000.85200
K_POINTS automatic
  10 4 4   0 0 0

My last thought is that when the electric field is specified in cartesian 
coordinates as above, the fact that the field in the crystal reference system

Re: [Pw_forum] A possible bug in epsilon.f90

2017-02-07 Thread Marton

Can you please be more specific? Do you have an example that you expect to
work but has problems?

Marton

On Feb 6, 2017 11:09 PM, "Jia Chen"  wrote:

> Hi Marton,
>
> Yes, I am aware of that. I think there is a issue with nspin=2, nspin=1 is
> totally fine.
>
> On Mon, Feb 6, 2017 at 11:15 PM, Marton  wrote:
>
>> Hi Jia,
>>
>> I don't think there is a bug there. If you go a few lines above in the
>> same file, you find, for example:
>>
>>  IF ( nspin == 1) full_occ = 2.0d0
>>
>> which means that full_occ takes care of the occupations.
>>
>> HTH
>>
>> Marton Voros
>>
>> --
>> Aneesur Rahman Fellow
>> Materials Science Division
>> Argonne National Laboratory
>>
>>
>> On Mon, Feb 6, 2017 at 3:27 PM, Jia Chen  wrote:
>>
>>> Dear All,
>>>
>>> I am suspicious that a bud exit in epsilon.f90 qe-6.0. The check of nbnd:
>>> ===
>>> IF ( REAL(nbnd,DP)*full_occ <= nelec ) CALL errore('epsilon', 'bad band
>>> number', 1)
>>> ===
>>> I think it should be:
>>> REAL(nbnd,DP)*full_occ <= nelec/2.0
>>>
>>> Let me know if I missed something...
>>>
>>> Cheers
>>> Jia
>>>
>>> ___
>>> 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
>>
>
>
> ___
> 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] degauss opt

2017-02-07 Thread Nicola Marzari



Thanks Pietro!

I was going to say that there is an extensive tutorial on this on
theossrv1.epfl.ch, but the machine will be down for 2-3 days (once
is back up, Mohammad can check it).

One small correction - "-TS" is negative (in the limit of small smearing,
that is always the case in our calculations) for gaussian or
fermi-dirac smearing, but can have either sign for cold smearing or
methfessel-paxton - since it's related to the first (or higher)
derivative of the density of states with respect to the energy,
at the Fermi energy (see de Gironcoli PRB 1995).


nicola


On 07/02/2017 10:10, Pietro Delugas wrote:
> Dear Mohammad
>
> When you perform a calculation with smearing your  variational total
> energy  has an additional term which in the final PW summary of
> contributions to total energies is labeled  (-TS).
>
> This term is expected to be negative, and proportional to the value
> of degauss you are using. Which is what you  are observing.
>
> The appropriate value for degauss depends on the precision you need
> for total energy and on how many k-points you can afford  to use in
> your calculation.
>
> You should chose a value of degauss for which the absolute value of
> the -TS contribution is smaller than the precision you need to
> achieve.  On the other hand the smaller the value of  degauss you
> use, the denser will be the needed k-point mesh to reach
> convergence.
>
> greetings - pietro
>
>
> On 07/02/2017 08:31, mohammadreza hosseini wrote:
>>
>> Dear all
>>
>> I am performing optimization of degauss for a MOF structure. As I
>> decrease degauss, The total energy increases. What is the problem?
>> Is it possible describe how to obtain proper number for degauss?
>>
>>
>> Best
>>
>> -Original Message- From: pw_forum-requ...@pwscf.org To:
>> pw_forum@pwscf.org Date: Mon, 06 Feb 2017 12:00:03 +0100 Subject:
>> Pw_forum Digest, Vol 115, Issue 6
>>
>> 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. Re: installation error: linking to Fortran libraries from C
>> fails (Amel Alhassan)
>>
>>
>> --
>>
>>
>>
Message: 1
>> Date: Mon, 6 Feb 2017 00:23:35 +0300 From: Amel Alhassan
>> mailto:alhassan.amel%40gmail.com>>
>> Subject: Re: [Pw_forum] installation error: linking to Fortran
>> libraries from C fails To: PWSCF Forum > > Message-ID:
>>
>> >
>>
>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> I downloaded colorgcc from here
>>
>> http://packages.ubuntu.com/precise/all/colorgcc/download
>>
>> Then, I was able to run ./configure successfully.
>>
>> Then
>>
>> $ make all
>>
>>
>> ran for quiet some time and ended with
>>
>> gfortran -o xspectra.x  xspectra.o ./xspectra_mod.o ./radin_mod.o
>>> ./mygetK.o ./ipoolscatter.o ./lr_sm1_psi.o ./orthoUatwfc_k.o
>>> ./read_k_points.o ./reset_k_points_and_reinit.o ./paw_gipaw.o
>>> ./gipaw_module.o ./init_gipaw_1.o ./init_gipaw_2.o \
>>
>> ../../PW/src/libpw.a  ../../Modules/libqemod.a -g -pthread
>>> ../../iotk/src/libiotk.a ../../flib/flib.a ../../clib/clib.a
>>> ../../flib/ptools.a  -llapack  -lblas  -lfftw3  -lblas
>>
>> ( cd ../../bin ; ln -fs ../XSpectra/src/xspectra.x . )
>>
>> make[3]: Leaving directory
>> `/home/amel/espresso-5.1.1/XSpectra/src'
>>
>> make[2]: Leaving directory `/home/amel/espresso-5.1.1/XSpectra'
>>
>> touch make-xspectra
>>
>> make[1]: Leaving directory `/home/amel/espresso-5.1.1/install'
>>
>>
>>
>>
>> I assume there is nothing wrong; unless make[ ] means an error(?!)
>>
>> I guess I am equipped to do some simulations now :-)
>>
>> Thank you very much Paolo and Phanikumar Pentyala
>>
>> Best regards, Amel
>>
>> On Sat, Feb 4, 2017 at 8:47 PM, Amel Alhassan
>> mailto:alhassan.amel%40gmail.com>>
>> wrote:
>>
>>> Thank you Paolo for translation :D I couldn't get what was the
>>> error actually.
>>>
>>> Ok, now checking for gcc and colorgcc, it seems like there is
>>> gcc installed but no colorgcc and I can't even install it.
>>>
>>> running
>>>
 $ sudo apt-get install colorgcc
>>>
>>> I get
>>>
 E: Package 'colorgcc' has no installation candidate
>>>
>>>
>>> Can I make espresso use gcc instead? How?
>>>
>>> Kind regards, Amel
>>>
>>>
>>> On Sat, Feb 4, 2017 at 7:14 PM, Paolo Giannozzi
>> mailto:p.giannozzi%40gmail.com>>
>>> wrote:
>>>
 Out of the hundreds of lines you pos

Re: [Pw_forum] degauss opt

2017-02-07 Thread Pietro Delugas


Dear Mohammad

When you perform a calculation with smearing your  variational total 
energy  has an additional term which in the final PW summary of 
contributions to total energies is labeled  (-TS).


This term is expected to be negative, and proportional to the value of 
degauss you are using. Which is what you  are observing.


The appropriate value for degauss depends on the precision you need for 
total energy and on how many k-points you can afford  to use in your 
calculation.


You should chose a value of degauss for which the absolute value of the 
-TS contribution is smaller than the precision you need to achieve.  On 
the other hand the smaller the value of  degauss you use, the denser 
will be the needed k-point mesh to reach convergence.


greetings - pietro


On 07/02/2017 08:31, mohammadreza hosseini wrote:

Dear all
I am performing optimization of degauss for a MOF structure. As I 
decrease degauss, The total energy increases. What is the problem?

Is it possible describe how to obtain proper number for degauss?
Best

-Original Message-
From: pw_forum-requ...@pwscf.org
To: pw_forum@pwscf.org
Date: Mon, 06 Feb 2017 12:00:03 +0100
Subject: Pw_forum Digest, Vol 115, Issue 6
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. Re: installation error: linking to Fortran libraries from C
  fails (Amel Alhassan)


--

Message: 1
Date: Mon, 6 Feb 2017 00:23:35 +0300
From: Amel Alhassan mailto:alhassan.amel%40gmail.com>>
Subject: Re: [Pw_forum] installation error: linking to Fortran
   libraries from C fails
To: PWSCF Forum mailto:pw_forum%40pwscf.org>>
Message-ID:
 
 
>
Content-Type: text/plain; charset="utf-8"

Hello,

I downloaded colorgcc from here

http://packages.ubuntu.com/precise/all/colorgcc/download

Then, I was able to run ./configure successfully.

Then

$ make all


ran for quiet some time and ended with

gfortran -o xspectra.x  xspectra.o ./xspectra_mod.o ./radin_mod.o
> ./mygetK.o ./ipoolscatter.o ./lr_sm1_psi.o ./orthoUatwfc_k.o
> ./read_k_points.o ./reset_k_points_and_reinit.o ./paw_gipaw.o
> ./gipaw_module.o ./init_gipaw_1.o ./init_gipaw_2.o \

../../PW/src/libpw.a  ../../Modules/libqemod.a -g -pthread
> ../../iotk/src/libiotk.a ../../flib/flib.a ../../clib/clib.a
> ../../flib/ptools.a  -llapack  -lblas  -lfftw3  -lblas

( cd ../../bin ; ln -fs ../XSpectra/src/xspectra.x . )

make[3]: Leaving directory `/home/amel/espresso-5.1.1/XSpectra/src'

make[2]: Leaving directory `/home/amel/espresso-5.1.1/XSpectra'

touch make-xspectra

make[1]: Leaving directory `/home/amel/espresso-5.1.1/install'




I assume there is nothing wrong; unless make[ ] means an error(?!)

I guess I am equipped to do some simulations now :-)

Thank you very much Paolo and Phanikumar Pentyala

Best regards,
Amel

On Sat, Feb 4, 2017 at 8:47 PM, Amel Alhassan
mailto:alhassan.amel%40gmail.com>>
wrote:

> Thank you Paolo for translation :D I couldn't get what was the error
> actually.
>
> Ok, now checking for gcc and colorgcc, it seems like there is gcc
> installed but no colorgcc and I can't even install it.
>
> running
>
>> $ sudo apt-get install colorgcc
>
> I get
>
>>  E: Package 'colorgcc' has no installation candidate
>
>
> Can I make espresso use gcc instead? How?
>
> Kind regards,
> Amel
>
>
> On Sat, Feb 4, 2017 at 7:14 PM, Paolo Giannozzi
mailto:p.giannozzi%40gmail.com>>
> wrote:
>
>> Out of the hundreds of lines you posted, the only relevant ones:
>>
>> >> /usr/bin/colorgcc -O3 -D__GFORTRAN -D__STD_F95 -D__FFTW3
>> -I../include  -c customize_signals.c
>> >>
>> >> make[1]: /usr/bin/colorgcc: Command not found
>>
>> clearly show that you are trying to use "/usr/bin/colorgcc" as C
>> compiler, and that there is no "/usr/bin/colorgcc" in your system
>>
>> Paolo
>> ___
>> Pw_forum mailing list
>> Pw_forum@pwscf.org 
>> http://pwscf.org/mailman/listinfo/pw_forum
>>
>
>
>
> --
> Amel Shamseldeen Ali A

Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault

Re: [Pw_forum] A possible bug in epsilon.f90

[Pw_forum] QE 6 compilation

Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

Re: [Pw_forum] A possible bug in epsilon.f90

[Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell

Re: [Pw_forum] A possible bug in epsilon.f90

Re: [Pw_forum] degauss opt

Re: [Pw_forum] degauss opt

10 matches

Site Navigation

Mail list logo

Footer information