Re: [Pw_forum] GGA+U
Dear F. Marsusi > Is this what one expected always from +U calculations, As I told you before nothing can be considered as "expected" when you apply the U correction to a strongly hybridized sp2 system such as a pi- conjugated molecule or graphene. In my experience this is not a good idea, because you obtain, for example, a higher ionization energy (and this is right when you correct LDA/GGA delocalization errors, and in agreement with a correction with exact exchange like B3LYP or HSE) but also a lower electron affinity (and this is wrong, and the opposite behavior of a correction with exact exchange). So you are walking in "terra incognita" where nothing can be given for granted. HTH Giuseppe On Friday, February 10, 2017 08:38:37 PM FARAH MARSUSI wrote: > Dear Giuseppe, > > Many thanks for your quick response. As you have correctly guessed, the > system is an organic material (fluorinated graphene). From U=0 to 3.4, M is > increasing gradually up to the expected value, M remains constant till U=3.6 > eV, then by increasing U, again M is reduced very soon to zero. Is > this what one expected always from +U calculations, when goes up further from > the optimum U value? From your answer, it is concluded to be a > strange behavior due to the organic nature of this material. > > Best regards, > F. Marsusi, > > Amirkabir University of Technology.â > > On Fri, 02/10/2017 08:09 PM, Giuseppe Mattioli > wrote: > > Dear F. Marsusi > > First of all you are not providing any detail of your system, so we cannot > > even guess what is "natural" for it. > > However, you are using the Hubbard U correction in a semiempirical way, and > > there is therefore no way to choose the U value but that reproducing > > some measured parameter, and not very much to do if unexpected or strange > > results appear at a given (unphysical?, problematic?) U value. > > In my experience the application of U to organic molecules has been always > > problematic due to the strong hybridization between C 2s and C 2p > > orbitals, and to the application of the correction to 2p orbitals only. > > HTH > > Giuseppe > > > > On Friday, February 10, 2017 07:25:10 PM FARAH MARSUSI wrote: > > > Dear all, > > > > > > By GGA+U as implemented in QE, the correct magnetization (M) and band gap > > > was obtained. The correct U value for each atom was obtained by > > > intensive > > > step by step runs to reach gradually the experimental M value, and > > > therefore band gap. All results are OK till now (the U value itself also= > > > 3.4 > > > eV > > > for carbon and fluorine is acceptable ). However, by enlarging the > > > obtained U value a bit (to 3.7 eV), the predicted M come back to that of > > > pure > > > GGA. Is it natural, or a problem exist? > > > > > > > > > Best regards, > > > F. Marsusi, > > > > > > - 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 90672342 - Fax +39 06 90672316 > >E-mail: " target="_blank"> > >http://www.ism.cnr.it/en/staff/giuseppe-mattioli/ > >ResearcherID: F-6308-2012 > > > > ___ > > Pw_forum mailing list > > Pw_forum@pwscf.org > > http://pwscf.org/mailman/listinfo/pw_forum > > > > -- > > This email was Anti Virus checked by Astaro Security Gateway. > > http://www.sophos.com - 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 90672342 - Fax +39 06 90672316 E-mail: http://www.ism.cnr.it/en/staff/giuseppe-mattioli/ ResearcherID: F-6308-2012 ___ 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
Hi Lorenzo, I have got it to work using both automatic and manual k-points, the mistake was to specify both 'berry=.true' and 'lelfield=.true.' at the same time and using 'nscf' calculation. The process I was going by was the description in the header of bp_c_phase.f90, when as you alluded to the electric field code is very similar but separate so the latter was the correct way to go with 'scf' calculation. For 'berry=.true.', one needs to run a normal 'scf' with 'lelfield=.false.' to get the ground state first, then the polarisation can be calculated (P=0 which is a good sign for my system) as described in bp_c_phase.f90. I will now test other gdir than 3. For 'lelfield=.true.', one can just specify a value of the field, both auto and manual work (again with gdir=3 so far). Afterwards one can apparently do a 'nscf' run with 'berry=.true.' (and 'lelfield=.false.') which reports the polarisation in the same format as the 0 field calculation above which is now non-zero as expected. Example 10 was helpful too, if anyone reads this that should be a good point of reference. Finally when you were talking about the bottleneck, I suppose you were talking about the efield code, my impression so far is this is not a problem using 4 processors, I will also test using 8 and compare the time taken. I have no idea how fast it 'should' be with proper parallisation, assuming it is possible to parallelise. Kindest regards, Louis From: pw_forum-boun...@pwscf.org on behalf of Louis Fry-Bouriaux Sent: 09 February 2017 11:38:01 To: PWSCF Forum Subject: Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell Hi Lorenzo, Thanks for clarifying! Yes that was quite silly of me to have nosym=.false., but yes it has no effect I still get the 'wrong g' error. I will now manually specify the k-points and relay what happens later.. I am very interested in solving the bottleneck issue as I wish to perform a much more intensive calculation using a large amorphous cell, and later move on to using ESM, so I am debugging as best as I can to first understand the code and what exactly causes the bottleneck. Are you able to share any additional technical information on this issue? Thank you so much for you help and assistance, Louis From: pw_forum-boun...@pwscf.org on behalf of Lorenzo Paulatto Sent: 08 February 2017 19:57:19 To: PWSCF Forum Subject: Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell On Wednesday, February 8, 2017 5:46:25 PM CET Louis Fry-Bouriaux wrote: > In your last email you mentioned the field 'pdir', I have not been able > to find this in the documentation, is this what you meant? It is the internal name of a variable in the subroutine that computes the macroscopic polarisation, but I think it is always gdir in the end. > as this is where the error is when I use other than gdir=3 (I added ln 364 > to identify what fails exactly) I never did this myself, but from the code expects strings of k-points, one after each other. Each string is formed by nppstr k-points, aligned in the direction gdir; there can be as many string as you want, in principle to form a grid in the two directions orthogonal to gdir. Maybe in the case gdir=3 these string are formed "spontaneously" when using k- points automatic, but it does not work in the other cases. The polarisation (berry=.true.) and the electric field (lefield=.true.) codes are very similar, but not identical, in theory the second is more general, I'm not too familiar with either. I've noticed that you set nosym=.false., I'm quite sure that that swith is overridden with lefield, but to be sure, could you try to sisable it? ___ 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] function "dgamma"
Dear QE developers, Kindly, in the subroutine "vnonloc" of program "hgh2qe.f90", the function "dgamma" is used but is not already defined. So the compilation is failed. Should I borrow some single-argument gamma function from somewhere to succeed? Best regards, Mahmoud Payami, AEOI___ 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
On Monday, February 13, 2017 11:43:08 AM CET Louis Fry-Bouriaux wrote: > Finally when you were talking about the bottleneck, I suppose you were > talking about the efield code, my impression so far is this is not a > problem using 4 processors, I will also test using 8 and compare the time > taken. I have no idea how fast it 'should' be with proper parallisation, > assuming it is possible to parallelise. When you increase the number of CPUs, you would expect the time to decreased linearly, if over a certain number of CPUs it stops decreasing or if it decreases slower than linear, it is a bottleneck. This will always happen eventually, but with berry/lefield it happens much sooner. Thank you for reporting back! I hope this information will be useful to future users -- Dr. Lorenzo Paulatto IdR @ IMPMC -- CNRS & Université Paris 6 phone: +33 (0)1 442 79822 / skype: paulatz www: http://www-int.impmc.upmc.fr/~paulatto/ mail: 23-24/423 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05 ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
Re: [Pw_forum] function "dgamma"
Hi Mahmoud, "dgamma" is an intrinsic fortran mathematical function that is not present on all compilers. Try with gfortran as in the README file: the compilation of "hgh2qe.f90" is independent from the rest of QE Paolo On Mon, Feb 13, 2017 at 1:13 PM, Mahmoud Payami Shabestari wrote: > > Dear QE developers, > > Kindly, in the subroutine "vnonloc" of program "hgh2qe.f90", the function > "dgamma" is used but is not already defined. So the compilation is failed. > Should I borrow some single-argument gamma function from somewhere to > succeed? > > Best regards, > Mahmoud Payami, AEOI > > ___ > Pw_forum mailing list > Pw_forum@pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum -- Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
Re: [Pw_forum] function "dgamma"
Dear Paolo, Thank you very much for your reply. I had also checked by using "gfortran" and it failed. Maybe because my gfortran it too old (version 4.1.2). Ok, I will make it. Thank you again, Best regards Mahmoud -Original Message- From: Paolo Giannozzi To: PWSCF Forum Date: Mon, 13 Feb 2017 14:28:58 +0100 Subject: Re: [Pw_forum] function "dgamma" Hi Mahmoud, "dgamma" is an intrinsic fortran mathematical function that is not present on all compilers. Try with gfortran as in the README file: the compilation of "hgh2qe.f90" is independent from the rest of QE Paolo On Mon, Feb 13, 2017 at 1:13 PM, Mahmoud Payami Shabestari mailto:mpayami%40aeoi.org.ir]> wrote: > > Dear QE developers, > > Kindly, in the subroutine "vnonloc" of program "hgh2qe.f90", the function > "dgamma" is used but is not already defined. So the compilation is failed. > Should I borrow some single-argument gamma function from somewhere to > succeed? > > Best regards, > Mahmoud Payami, AEOI > > ___ > Pw_forum mailing list > Pw_forum@pwscf.org [mailto:Pw_forum%40pwscf.org] > http://pwscf.org/mailman/listinfo/pw_forum [http://pwscf.org/mailman/listinfo/pw_forum] -- Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 ___ Pw_forum mailing list Pw_forum@pwscf.org [mailto:Pw_forum%40pwscf.org] http://pwscf.org/mailman/listinfo/pw_forum [http://pwscf.org/mailman/listinfo/pw_forum]___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] How to understand Local DOS of a certain atom in qe example
Dear all qe users: I have a problem of understanding Local DOS of a certain atom in qe example,especially the term irmin(*,*) and irmax in the following input file,I don't understand why and how we can do the LDOS calculations of a certain atom only by defining the value of irmin and irmax?especially how can we use the value of irmin to specify the LDOS we are going to calculate is above the surface Al not above the surface As? for example irmin(1,1)= 0, irmax(1,1)= 2, irmin(2,1)= 0, irmax(2,1)= 2, irmin(3,1)=63, irmax(3,1)=65, &projwfc prefix = 'AlAs110' outdir='$TMP_DIR/', ngauss=0 degauss=0.01 DeltaE=0.02 tdosinboxes=.true. plotboxes=.true. n_proj_boxes=8 !! Boxes centered on the first vacuum layer: !! 1) above the surface Al irmin(1,1)= 0, irmax(1,1)= 2, irmin(2,1)= 0, irmax(2,1)= 2, irmin(3,1)=63, irmax(3,1)=65, !! 2) above the surface As irmin(1,2)= 9, irmax(1,2)=11, irmin(2,2)= 5, irmax(2,2)= 7, irmin(3,2)=63, irmax(3,2)=65, !! 3) above the 2nd layer Al irmin(1,3)= 9, irmax(1,3)=11, irmin(2,3)=14, irmax(2,3)=16, irmin(3,3)=63, irmax(3,3)=65, !! 4) as large as the surface unit cell irmin(1,4)= 1, irmax(1,4)=18, irmin(2,4)= 1, irmax(2,4)=27, irmin(3,4)=63, irmax(3,4)=65, !! Same as above, centered on the second vacuum layer: irmin(1,5)= 0, irmax(1,5)= 2, irmin(2,5)= 0, irmax(2,5)= 2, irmin(3,5)=72, irmax(3,5)=74, irmin(1,6)= 9, irmax(1,6)=11, irmin(2,6)= 5, irmax(2,6)= 7, irmin(3,6)=72, irmax(3,6)=74, irmin(1,7)= 9, irmax(1,7)=11, irmin(2,7)=14, irmax(2,7)=16, irmin(3,7)=72, irmax(3,7)=74, irmin(1,8)= 1, irmax(1,8)=18, irmin(2,8)= 1, irmax(2,8)=27, irmin(3,8)=72, irmax(3,8)=74, / ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] Fw: Re: Re: optimization problems of vanadium oxide
Dear all, Hi. Still I have not fixed the relaxation problem. But I have some new findings. The output of the vc-relax calculation shows that the force in y position is totally zero (in each step). As can be seen from the input file, I did not set this constraint on the relaxation. Does this result mean something wrong in input? It is really appreciated if someone can answer this. Thank you in advance. Best, Yuanqing Wang --- Original Message Subject: Re: Re: [Pw_forum] optimization problems of vanadium oxide Date: Tue, 17 Jan 2017 18:33:24 +0900 From: ＷＡＮＧ ＹＵＡＮＱＩＮＧ To: PWSCF Forum Cc: Dear Manu, Hi. Sorry for the late reply. I tried your settings (cov_thr and bfgs), however, it does not help. The force is still very large during relaxation. I found two oxygens tend to approach potassium very closely during relaxation, which is not reasonable. Besides, I want to move the atoms in all directions. Is there anyone who can suggest me some alternative methods? Thank you in advance! Best, Yuanqing Date: Thu, 5 Jan 2017 12:42:07 -0500 From: Manu Hegde Subject: Re: [Pw_forum] optimization problems of vanadium oxide To: PWSCF Forum Message-ID: Content-Type: text/plain; charset="utf-8" I am not expert in this but i can suggest few things try conv_thr=10^-8 and use ion/cell_dynamics=bfgs. Also which direction you want to move the atoms?. I mean cell_dofree?. all the xyz direction? Hope it helps you. Manu On Thu, Jan 5, 2017 at 12:35 PM, wrote: > Dear QE users, > > I am trying to optimize the crystal structure of K2V8O21. The input file > is given below. I tried many different sets (vc-realx and relax. > constrained or not), or optimization algorithm (BFGS or damp). However, I > cannot get converged result. Can someone give me some suggestions? Thank > you very much! > > Best, > > Yuanqing Wang > > postdoctor > RIKEN, Japan > > --One input file--- > &control > calculation='vc-relax', > restart_mode = 'from_scratch', > prefix = 'k2v8o21', > outdir = './', > tprnfor = .TRUE. > pseudo_dir = '/pseudo/', > nstep=200 > / > &system > ibrav = 0, > nat= 62, ntyp= 3, > ecutwfc = 150, > ecutrho = 600, > tot_charge=0, > occupations='smearing', smearing='mp', degauss=0.03 > / > &electrons >mixing_beta = 0.3 > / > &ions > ion_dynamics='damp' > / > &CELL > cell_dynamics='damp-pr' > / > ATOMIC_SPECIES > K 39.0983 K.pz-hgh.UPF > V 50.942 V.pz-hgh.UPF > O 15.999 O.pz-hgh.UPF > CELL_PARAMETERS angstrom > 13.746484076 0.0 -0.193637952 > 0.0 3.360623858 0.0 > -0.429832895 0.0 13.681512366 > ATOMIC_POSITIONS angstrom > K 6.984312493 0.0 4.188728225 0 0 0 > K 6.332338675 0.0 9.299146598 0 0 0 > K 0.43470 1.680311929 4.286848404 0 0 0 > K 13.205507698 1.680311929 9.201026418 0 0 0 > V 10.878749236 1.680311929 12.433287018 > V 2.437901942 1.680311929 1.054587499 > V 4.008352623 0.0 12.539262335 > V 9.308298554 0.0 0.948612182 > V 11.369939010 0.0 6.612591821 > V 1.946712158 0.0 6.875283001 > V 4.495045176 1.680311929 6.720753553 > V 8.821605991 1.680311929 6.767121270 > V 11.150388833 0.0 3.743423629 > V 2.166262335 0.0 9.744451194 > V 4.296183684 1.680311929 3.847414705 > V 9.020467484 1.680311929 9.640460118 > V 12.578611942 0.0 1.090039654 > V 0.738039229 0.0 12.397835067 > V 5.704373956 1.680311929 1.184004573 > V 7.612277214 1.680311929 12.303870148 > O 12.349856377 0.0 5.231345609 > O 0.966794818 0.0 8.256528398 > O 5.490033518 1.680311929 5.354972202 > O 7.826617675 1.680311929 8.132901806 > O 10.708076383 1.680311929 6.225623611 > O 2.608574796 1.680311929 7.262250803 > O 3.828996973 0.0 6.322373797 > O 9.487654207 0.0 7.165500618 > O 12.137386541 1.680311929 0.583012891 > O 1.179264646 1.680311929 12.904861320 > O 5.265470757 -0.0 0.685756586 > O 8.051180430 0.0 12.802117625 > O 11.927069357 1.680311929 11.327461557 > O 1.389581812 1.680311929 2.160413266 > O 5.060238394 0.0 11.437026216 > O 8.256412774 0.0 2.050848606 > O 10.802990364 0.0 1.920124897 > O 2.513660822 0.0 11.567749315 > O 3.937601468 1.680311929 2.030377822 > O 9.379049718 1.680311929 11.457496389 > O 9.720341944 0.0 4.289255974 > O 3.596309249 0.0 9.198618033 > O 2.865221165 1.680311929 4.391289428 > O 10.451430029 1.680311929 9.096584579 > O 1.048281817 0.0 5
[Pw_forum] General quenstion about metallic supercell
Dear all,
I have a question regarding constructing supercells in QE and performing
vc-relax. Based on recommendations available on pwscf website, I used
xcrysden to generate a rather large cell (consisting 125 atoms of
vanadium, available in attached file). But, when I modify my input script
and again visualize the structure, "translational asymmetric cell" view
shows a very strange configuration of atoms. Also, performing vc-relax
takes incredibly long time (about 6 days on 64-cores).
Is there something wrong with my method? Is this a correct super cell?
I use QE5.4.0 compiled with ifort.
-
Method:
1- Constructing a simple bcc unit cell (~ in1.txt)
2- Visualizing using xcrysden, changing to primitive cell mode, repeating
cell in x,y and z-direction (5x5x5) and saving configuration (~ data.xyz)
3- Extracting atomic positions from saved configuration and modifying the
input script (in2.txt)
Thank you very much for your response.
--
With Best Regards
Afshin Arjhangemehr
PhD candidate in Radiation Application
Shahid Beheshti University G.C, Tehran, IRAN
(+98) 912 439 20 64
&CONTROL
calculation = 'scf' ,
restart_mode = 'from_scratch' ,
etot_conv_thr = 1.0E-8 ,
forc_conv_thr = 1.0D-8 ,
outdir='/home/koma/software/QE-USER/Output',
pseudo_dir = '/home/koma/software/QE-USER/Pseudo-potential',
tprnfor = .true.
tstress = .true.
/
&SYSTEM
ibrav = 3,
celldm(1) = 5.62586,
nat = 1,
ntyp = 1,
ecutwfc = 100
occupations = 'smearing' ,
degauss= 0.01 ,
smearing= 'gaussian',
nspin=2 ,
starting_magnetization(1) = 0.2 ,
/
&ELECTRONS
conv_thr = 1.D-8 ,
/
&IONS
ion_dynamics= 'bfgs',
upscale = 70.d0,
pot_extrapolation = 'atomic',
wfc_extrapolation = 'none' ,
/
ATOMIC_SPECIES
V50.6941V.pbe-spn-kjpaw_psl.0.2.3.UPF
ATOMIC_POSITIONS (angstrom)
V 0 0 0
K_POINTS {automatic}
16 16 16 0 0 0
data.xyz
Description: Protein Databank data
&CONTROL
calculation = 'vc-relax' ,
restart_mode = 'from_scratch' ,
prefix = 'V_125atoms' ,
etot_conv_thr = 1.0E-2 ,
forc_conv_thr = 1.0D-2 ,
outdir='/share/users/mahdiani/espresso/Output',
pseudo_dir = '/share/users/mahdiani/espresso/PS',
tprnfor = .true.
tstress = .true.
/
&SYSTEM
ibrav = 3,
celldm(1) = 28.6293 ,
nat = 125,
ntyp = 1,
ecutwfc = 47 ,
occupations = 'smearing' ,
degauss= 0.05 ,
smearing= 'gaussian',
nspin=2 ,
starting_magnetization(1) = 0.05 ,
/
&ELECTRONS
conv_thr = 1.D-2 ,
/
&IONS
ion_dynamics= 'bfgs',
upscale = 70.d0,
pot_extrapolation = 'atomic',
wfc_extrapolation = 'none' ,
/
&CELL
cell_dynamics = 'bfgs' ,
cell_factor = 2 ,
/
ATOMIC_SPECIES
V50.6941V.pbe-spn-kjpaw_psl.0.2.3.UPF
ATOMIC_POSITIONS (angstrom)
V0.000.000.00
V -1.5149967090 -1.51499670901.5149967090
V -3.0299934180 -3.02999341803.0299934180
V -4.5449901270 -4.54499012704.5449901270
V -6.0599868360 -6.05998683606.0599868360
V -1.51499670901.51499670901.5149967090
V -3.02999341800.003.0299934180
V -4.5449901270 -1.51499670904.5449901270
V -6.0599868360 -3.02999341806.0599868360
V -7.5749835450 -4.54499012707.5749835450
V -3.02999341803.02999341803.0299934180
V -4.54499012701.51499670904.5449901270
V -6.05998683600.006.0599868360
V -7.5749835450 -1.51499670907.5749835450
V -9.0899802540 -3.02999341809.0899802540
V -4.54499012704.54499012704.5449901270
V -6.05998683603.02999341806.0599868360
V -7.57498354501.51499670907.5749835450
V -9.08998025400.009.0899802540
V -10.6049769630 -1.5149967090 10.6049769630
V -6.05998683606.05998683606.0599868360
V -7.57498354504.54499012707.5749835450
V -9.08998025403.02999341809.0899802540
V -10.60497696301.5149967090 10.6049769630
V -12.11997367
Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell
Thanks Lorenzo I hope so too, I think the best references are Examples 4 and 10, I have this tendency to just go ahead once I get something working, need to work on that :P Indeed I have reproduced almost exactly what you have said. What I can confirm when using bp_c_phase (no electric field): - all gdir work, only gdir=3 has a notable improvement in performance. - when gdir=3, up to 4 processors scaling is good, on 8 it is terrible it actually takes longer, WALL time is notably larger than CPU time. - the call to 'CALL mp_sum(aux_g(:), intra_bgrp_comm )' is made when gdir != 3. My current understanding is that mp_sum takes the trace of the 'aux_g' matrix, whereas for gdir=3 there is significantly less code that ends up building the matrix 'aux' which is finally used to build 'mat'. The matrix 'evc' represents the wavefunctions built using plane waves, but 'evc' is used in many files. Since bp_c_phase is executed last, 'evc' has already been built and is only read in this file. With this and comparing the output I notice that performance when gdir=3 is better for almost all routines.. I will continue debugging tomorrow on the 8 processor machine where the differences are much more noticeable.. Do you think I should contact Paolo Giannozzi directly to better understand what is going on here? Thanks so much [??] Louis From: pw_forum-boun...@pwscf.org on behalf of Lorenzo Paulatto Sent: 13 February 2017 13:04:22 To: PWSCF Forum Subject: Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell On Monday, February 13, 2017 11:43:08 AM CET Louis Fry-Bouriaux wrote: > Finally when you were talking about the bottleneck, I suppose you were > talking about the efield code, my impression so far is this is not a > problem using 4 processors, I will also test using 8 and compare the time > taken. I have no idea how fast it 'should' be with proper parallisation, > assuming it is possible to parallelise. When you increase the number of CPUs, you would expect the time to decreased linearly, if over a certain number of CPUs it stops decreasing or if it decreases slower than linear, it is a bottleneck. This will always happen eventually, but with berry/lefield it happens much sooner. Thank you for reporting back! I hope this information will be useful to future users -- Dr. Lorenzo Paulatto IdR @ IMPMC -- CNRS & Université Paris 6 phone: +33 (0)1 442 79822 / skype: paulatz www: http://www-int.impmc.upmc.fr/~paulatto/ mail: 23-24/423 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05 ___ 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
