Re: [Wien] Discontinuity in electron density
Dear WIEN2k developers and users, This problem is simply solved by extending the L,M list. I am sorry for bothering you. with Best Regards, Nishimura > 2019/07/12 16:27、西村 真一 のメール: > > Dear WIEN2k developers and users, > > I am using WIEN2k 19.1. > When I calculate electron density distribution of silicon with 3ddens, > the density map shows discontinuities around the boundaries of muffin-tin > spheres. (See the attached image file.) > I tried different sets of parameters below with the attached struct file but > did not improve the map. > > init_lapw -b -red 0 -vxc 19 -ecut -6 -rkmax 9 -lmax 10 -lvns 4 -gmax 12 -numk > 1 > init_lapw -b -red 0 -vxc 19 -ecut -6 -rkmax 9 -lmax 12 -lvns 6 -gmax 16 -numk > 1 > > What parameter should I adjust to avoid this kind of discontinuities? > > Thanks in advance, > Shinichi Nishimura > > > Shin-ichi NISHIMURA, Ph.D > nishim...@chemsys.t.u-tokyo.ac.jp > https://shinichinishimura.github.io > http://orcid.org/-0001-7464-8692 > > Atsuo YAMADA Group, > Department of Chemical System Engineering, > Graduate School of Engineering, > The University of Tokyo > > Yamada Lab., Engineering Bldg.#3-5C08, > 7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656, > Japan > > ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] gap with hybrid functional
Dear Dr. Tran, Thank you for your clear explanation. > Hartree-Fock Hamiltonian, therefore the number of states in case.vectorhf > can only be smaller (typically much smaller) than the number of states in > case.vector. > It is obviously useless to choose for emax in case.int a value which is > larger than the energy of the highest state in case.vector(hf). This is clearly consistent with my result. I will set the nband to (slightly) larger number to plot the higher energy conduction bands, Thank you very much for your help. with best regards, Shinichi Nishimura On 2013/09/19, at 16:38, t...@theochem.tuwien.ac.at wrote: > For LDA/GGA calculations, emax in case.in1 determines how many states > are calculated and stored in case.vector (used for DOS plotting). > The corresponding energies are printed in case.energy. > > For hybrid calculations (-hf), this is nband in case.inhf which determines > the number of states stored in case.vectorhf (used for DOS plotting). > The corresponding energies are in case.energyhf. nband means that nband > LDA/GGA orbitals in case.vector will be used as basis functions for the > Hartree-Fock Hamiltonian, therefore the number of states in case.vectorhf > can only be smaller (typically much smaller) than the number of states in > case.vector. > > It is obviously useless to choose for emax in case.int a value which is > larger than the energy of the highest state in case.vector(hf). > > For DOS plotting you need to use -hf: > x lapw2 -qtl -hf (-up/dn) > x tetra -hf (-up/dn) > > F. Tran > > For DOS plotting, > > > On Thu, 19 Sep 2013, 西村 真一 wrote: > >> Dear Dr. Tran and WIEN2k community, >> >> I have a question related to this topic. >> >> DOS plot with the "-hf" switch is truncated at a lower energy than Emax >> value in the case.int file. >> The Emax in "-hf" mode is determined by the "nband" variable in case.inhf >> file? >> >> Could you please tell me the detailed definition of the DOS plot generation >> with full hybrid functional calculation? >> >> Thank you in advance >> >> Shinichi Nishimura >> >> >> On 2013/09/19, at 1:13, t...@theochem.tuwien.ac.at wrote: >> >>> Hi, >>> >>> For DOS calculation with full hybrid functionals you need to >>> execute lapw2 and tetra with -hf: >>> x lapw2 -qtl -hf (-up/dn) >>> x tetra -hf (-up/dn) >>> >>> Maybe this was the problem. This is not explained in the users's guide, >>> but we will add a paragraph about that soon. >>> >>> F. Tran >>> >>> On Wed, 18 Sep 2013, abdel Mar.. wrote: >>> >>>> dear Wien2k community, >>>> i'm interested on the calculation of gap for 4f materials with hybrid >>>> functional. >>>> (1) with onsite B3PW91 >>>> (2) with full hybrid B3PW91 >>>> for (1) the value with grep GAP case.scf in agreement with difference >>>> betwwen (the top) VB >>>> and (the bottom) of CB in Total DOS plot, also in agrement with expt. >>>> value ~ 3eV >>>> for (2) i have 2 values >>>> big one with grep GAP in the scf file ~ 3.4 eV >>>> small from total DOS plot ~ 0.8 eV >>>> can any one tell me please where this difference comes from for the same >>>> full hybrid functional >>>> and between on site and full hybrid functional? >>>> Regards >>>> >>>> M. >>> ___ >>> Wien mailing list >>> Wien@zeus.theochem.tuwien.ac.at >>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>> SEARCH the MAILING-LIST at: >>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >> ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] gap with hybrid functional
Dear Dr. Tran and WIEN2k community, I have a question related to this topic. DOS plot with the "-hf" switch is truncated at a lower energy than Emax value in the case.int file. The Emax in "-hf" mode is determined by the "nband" variable in case.inhf file? Could you please tell me the detailed definition of the DOS plot generation with full hybrid functional calculation? Thank you in advance Shinichi Nishimura On 2013/09/19, at 1:13, t...@theochem.tuwien.ac.at wrote: > Hi, > > For DOS calculation with full hybrid functionals you need to > execute lapw2 and tetra with -hf: > x lapw2 -qtl -hf (-up/dn) > x tetra -hf (-up/dn) > > Maybe this was the problem. This is not explained in the users's guide, > but we will add a paragraph about that soon. > > F. Tran > > On Wed, 18 Sep 2013, abdel Mar.. wrote: > >> dear Wien2k community, >> i'm interested on the calculation of gap for 4f materials with hybrid >> functional. >> (1) with onsite B3PW91 >> (2) with full hybrid B3PW91 >> for (1) the value with grep GAP case.scf in agreement with difference >> betwwen (the top) VB >> and (the bottom) of CB in Total DOS plot, also in agrement with expt. value >> ~ 3eV >> for (2) i have 2 values >> big one with grep GAP in the scf file ~ 3.4 eV >> small from total DOS plot ~ 0.8 eV >> can any one tell me please where this difference comes from for the same >> full hybrid functional >> and between on site and full hybrid functional? >> Regards >> >> M. > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Segmentation fault in lapw0 -eece
Dear Professor Blaha, Dr. Abo and WIEN2k users, Thank you very much for your kind replies. New I have succeeded to eliminate the segmentation fault of "lapw0 -eece". The "-xHost" of compiler option was causing the problem. For my Xeon X5570 + ifort (13.1.3) environment, "-xHost" and "-xSSE4.2" cause the error at line#704 of lapw0.F. I should be careful for applying the optimization options. Thanks again, Nishimura On 2013/09/05, at 16:10, 西村 真一 wrote: >> I doubt, that TiC is a meaningful case for -eece !!! > Yes. > I just wanted to confirm the origin of problem with a simple case. > >> Checkout case.clmvalupeece (and dn) files. Do they look ok ? >> (No . NaN, only zeros, ...) > > There are no * or NaN in case.slmval(up/dn)eece files. > All the values for Atom1 are seems normal... > > > On 2013/09/05, at 15:57, Peter Blaha wrote: > >> The ineece file looks ok. >> >> I doubt, that TiC is a meaningful case for -eece !!! >> >> Checkout case.clmvalupeece (and dn) files. Do they look ok ? >> (No . NaN, only zeros, ...) >> >> >> On 09/05/2013 08:49 AM, 西村 真一 wrote: >>> Hi Peter, >>> >>> My case.ineece file for TiC example is as follow. >>> -9.0 1 emin natom >>> 1 1 2 iatom nlorb lorb >>> HYBR HYBR / EECE mode >>> 0.25 amount of exact exchange >>> >>> Are there any problems with this file? >>> >>> On 2013/09/05, at 15:05, Peter Blaha wrote: >>> >>>> Error in case.ineece >>>> >>>> Am 05.09.2013 06:29, schrieb 西村 真一: >>>>> Dear Wien2k users, >>>>> >>>>> I met problem in -eece calcualtion. >>>>> The operation I did was as follow; >>>>> 1. init >>>>> 2. runsp >>>>> 3. save -d xxx >>>>> 4. edit case.ineece (copied from SRC_templates) >>>>> 5. runsp -eece >>>>> >>>>> After the 2nd lapw2, "x lapw0 -eece" failed. >>>>> The output is: >>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred >>>>> Image PCRoutineLineSource >>>>> lapw0 004804A0 MAIN__695 >>>>> lapw0.F >>>>> lapw0 0040388C Unknown Unknown >>>>> Unknown >>>>> libc.so.6 2B38BDBC3C8D Unknown Unknown >>>>> Unknown >>>>> lapw0 00403789 Unknown Unknown >>>>> Unknown >>>>> 0.036u 0.004s 0:00.04 75.0% 0+0k 0+40io 0pf+0w >>>>> >>>>> The line #695 of lapw0.F for ver.12.1 (#704 for ver.13.1) is >>>>> clmsp(j,lm1,jatom,1)=clmsp(j,lm1,jatom,1)*sqfp. >>>>> >>>>> This problem does not occur in WIEN2k ver.11.1a, while ver.12.1 and >>>>> ver.13.1 gave the same error. >>>>> The compiler and the linked libraries are same. (Intel Composer XE >>>>> 2013.5.192) >>>>> >>>>> Thanks in advance, >>>>> >>>>> Shinichi Nishimura >>>>> >>>>> ___ >>>>> Wien mailing list >>>>> Wien@zeus.theochem.tuwien.ac.at >>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>>>> SEARCH the MAILING-LIST at: >>>>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >>>>> >>>> >>>> -- >>>> - >>>> Peter Blaha >>>> Inst. Materials Chemistry, TU Vienna >>>> Getreidemarkt 9, A-1060 Vienna, Austria >>>> Tel: +43-1-5880115671 >>>> Fax: +43-1-5880115698 >>>> email: pbl...@theochem.tuwien.ac.at >>>> - >>>> ___ >>>> Wien mailing list >>>> Wien@zeus.theochem.tuwien.ac.at >>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>>> SEARCH the MAILING-LIST at: >>>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >>> >>> ___ >>> Wien mailing list >>> Wien@zeus.theochem.tuwien.ac.at >>>
Re: [Wien] Segmentation fault in lapw0 -eece
> I doubt, that TiC is a meaningful case for -eece !!! Yes. I just wanted to confirm the origin of problem with a simple case. > Checkout case.clmvalupeece (and dn) files. Do they look ok ? > (No . NaN, only zeros, ...) There are no * or NaN in case.slmval(up/dn)eece files. All the values for Atom1 are seems normal... On 2013/09/05, at 15:57, Peter Blaha wrote: > The ineece file looks ok. > > I doubt, that TiC is a meaningful case for -eece !!! > > Checkout case.clmvalupeece (and dn) files. Do they look ok ? > (No . NaN, only zeros, ...) > > > On 09/05/2013 08:49 AM, 西村 真一 wrote: >> Hi Peter, >> >> My case.ineece file for TiC example is as follow. >> -9.0 1 emin natom >> 1 1 2 iatom nlorb lorb >> HYBR HYBR / EECE mode >> 0.25 amount of exact exchange >> >> Are there any problems with this file? >> >> On 2013/09/05, at 15:05, Peter Blaha wrote: >> >>> Error in case.ineece >>> >>> Am 05.09.2013 06:29, schrieb 西村 真一: >>>> Dear Wien2k users, >>>> >>>> I met problem in -eece calcualtion. >>>> The operation I did was as follow; >>>> 1. init >>>> 2. runsp >>>> 3. save -d xxx >>>> 4. edit case.ineece (copied from SRC_templates) >>>> 5. runsp -eece >>>> >>>> After the 2nd lapw2, "x lapw0 -eece" failed. >>>> The output is: >>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred >>>> Image PCRoutineLineSource >>>> lapw0 004804A0 MAIN__695 lapw0.F >>>> lapw0 0040388C Unknown Unknown Unknown >>>> libc.so.6 2B38BDBC3C8D Unknown Unknown Unknown >>>> lapw0 00403789 Unknown Unknown Unknown >>>> 0.036u 0.004s 0:00.04 75.0%0+0k 0+40io 0pf+0w >>>> >>>> The line #695 of lapw0.F for ver.12.1 (#704 for ver.13.1) is >>>>clmsp(j,lm1,jatom,1)=clmsp(j,lm1,jatom,1)*sqfp. >>>> >>>> This problem does not occur in WIEN2k ver.11.1a, while ver.12.1 and >>>> ver.13.1 gave the same error. >>>> The compiler and the linked libraries are same. (Intel Composer XE >>>> 2013.5.192) >>>> >>>> Thanks in advance, >>>> >>>> Shinichi Nishimura >>>> >>>> ___ >>>> Wien mailing list >>>> Wien@zeus.theochem.tuwien.ac.at >>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>>> SEARCH the MAILING-LIST at: >>>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >>>> >>> >>> -- >>> - >>> Peter Blaha >>> Inst. Materials Chemistry, TU Vienna >>> Getreidemarkt 9, A-1060 Vienna, Austria >>> Tel: +43-1-5880115671 >>> Fax: +43-1-5880115698 >>> email: pbl...@theochem.tuwien.ac.at >>> - >>> ___ >>> Wien mailing list >>> Wien@zeus.theochem.tuwien.ac.at >>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>> SEARCH the MAILING-LIST at: >>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >> >> ___ >> Wien mailing list >> Wien@zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> SEARCH the MAILING-LIST at: >> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >> > > -- > > P.Blaha > -- > Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna > Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 > Email: bl...@theochem.tuwien.ac.atWWW: > http://info.tuwien.ac.at/theochem/ > -- > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html --- 西村 真一 東京大学 工学系研究科 化学システム工学専攻 山田研究室 主任研究員 〒113-8656 東京都文京区本郷7-3-1 工学部5号館604 山田研究室 e-mail: nishim...@chemsys.t.u-tokyo.ac.jp 電話: 03-5841-7316 FAX: 03-5841-7316 ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Segmentation fault in lapw0 -eece
Hi Peter, My case.ineece file for TiC example is as follow. -9.0 1 emin natom 1 1 2 iatom nlorb lorb HYBR HYBR / EECE mode 0.25 amount of exact exchange Are there any problems with this file? On 2013/09/05, at 15:05, Peter Blaha wrote: > Error in case.ineece > > Am 05.09.2013 06:29, schrieb 西村 真一: >> Dear Wien2k users, >> >> I met problem in -eece calcualtion. >> The operation I did was as follow; >> 1. init >> 2. runsp >> 3. save -d xxx >> 4. edit case.ineece (copied from SRC_templates) >> 5. runsp -eece >> >> After the 2nd lapw2, "x lapw0 -eece" failed. >> The output is: >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> Image PCRoutineLineSource >> lapw0 004804A0 MAIN__695 lapw0.F >> lapw0 0040388C Unknown Unknown Unknown >> libc.so.6 2B38BDBC3C8D Unknown Unknown Unknown >> lapw0 00403789 Unknown Unknown Unknown >> 0.036u 0.004s 0:00.04 75.0% 0+0k 0+40io 0pf+0w >> >> The line #695 of lapw0.F for ver.12.1 (#704 for ver.13.1) is >> clmsp(j,lm1,jatom,1)=clmsp(j,lm1,jatom,1)*sqfp. >> >> This problem does not occur in WIEN2k ver.11.1a, while ver.12.1 and ver.13.1 >> gave the same error. >> The compiler and the linked libraries are same. (Intel Composer XE >> 2013.5.192) >> >> Thanks in advance, >> >> Shinichi Nishimura >> >> ___ >> Wien mailing list >> Wien@zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> SEARCH the MAILING-LIST at: >> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >> > > -- > - > Peter Blaha > Inst. Materials Chemistry, TU Vienna > Getreidemarkt 9, A-1060 Vienna, Austria > Tel: +43-1-5880115671 > Fax: +43-1-5880115698 > email: pbl...@theochem.tuwien.ac.at > - > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Segmentation fault in lapw0 -eece
Dear Wien2k users, I met problem in -eece calcualtion. The operation I did was as follow; 1. init 2. runsp 3. save -d xxx 4. edit case.ineece (copied from SRC_templates) 5. runsp -eece After the 2nd lapw2, "x lapw0 -eece" failed. The output is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 004804A0 MAIN__695 lapw0.F lapw0 0040388C Unknown Unknown Unknown libc.so.6 2B38BDBC3C8D Unknown Unknown Unknown lapw0 00403789 Unknown Unknown Unknown 0.036u 0.004s 0:00.04 75.0% 0+0k 0+40io 0pf+0w The line #695 of lapw0.F for ver.12.1 (#704 for ver.13.1) is clmsp(j,lm1,jatom,1)=clmsp(j,lm1,jatom,1)*sqfp. This problem does not occur in WIEN2k ver.11.1a, while ver.12.1 and ver.13.1 gave the same error. The compiler and the linked libraries are same. (Intel Composer XE 2013.5.192) Thanks in advance, Shinichi Nishimura ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Parallel execution of hybrid functional calculation
Thank you for your kind reply. I have just started to examine effectiveness of the HF calculation in my system. > I don't really know. Anyway, the execution of the hf module will take > between 1 and 3 orders of magnitude more time than lapw1 and lapw2. I know that expensive calculations are not always effective. However, at initial stage of calculation, many trials are necessary before higher accuracy calculation. So disabling the parallel execution of initial stage calculation consumes too much time and reserved cores in job-queing systems. Thanks, Shinichi On 2013/09/01, at 18:10, t...@theochem.tuwien.ac.at wrote: > I don't really know. Anyway, the execution of the hf module will take > between 1 and 3 orders of magnitude more time than lapw1 and lapw2. > Therefore, to run lapw1 and lapw2 for FBZ in parallel will barely > change the total execution time. > > F. Tran > > On Sun, 1 Sep 2013, t...@theochem.tuwien.ac.at wrote: > >> Hi, >> >> Thank you for your quick reply. >> >>> No, with hybrid functionals the k-point parallelization is for the >>> k-points in case.klist_ibz only. >> How about the fine-grained parallelization? >> I can put the $para to the lines for case.klist_fbz calculations. >> Does this cause some problems? >> >> Shinichi >> >> On 2013/09/01, at 17:31, tran at theochem.tuwien.ac.at wrote: >> >>> Hi, >>> No, with hybrid functionals the k-point parallelization is for the >>> k-points in case.klist_ibz only. >>> Another thing: >>> If you start a hybrid calculation without case.vectorhf, >>> case.energyhf and case.weighhf in your directory, then in order to >>> generate these files, during the 1st iteration lapw1 and lapw2 will >>> be executed one additional time compared to the next iterations. >>> F. Tran >>> On Sun, 1 Sep 2013, wrote: Dear WIEN2k users, I am trying to perform the hybrid functionals calculation with -hf of option like: $ runsp -hf -p. The version of WIEN2k is 13.1. With the -hf execution lapw1 and lapw2 with the FBZ-klist do not run in >> parallel mode, while the normal runsp runs in parallel mode (MPI/k-point), I checked the runsp script, and found that the lines for the calculations with FBZ-klist do not have the $para >> variable. We can not run the FBZ calculations with any parallel options? Thanks in advance, Shinichi Nishimura ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: >> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >>> ___ >>> Wien mailing list >>> Wien at zeus.theochem.tuwien.ac.at >>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >>> SEARCH the MAILING-LIST at: >> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html >> > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Parallel execution of hybrid functional calculation
Hi, Thank you for your quick reply. > No, with hybrid functionals the k-point parallelization is for the > k-points in case.klist_ibz only. How about the fine-grained parallelization? I can put the $para to the lines for case.klist_fbz calculations. Does this cause some problems? Shinichi On 2013/09/01, at 17:31, t...@theochem.tuwien.ac.at wrote: > Hi, > > No, with hybrid functionals the k-point parallelization is for the > k-points in case.klist_ibz only. > > Another thing: > If you start a hybrid calculation without case.vectorhf, > case.energyhf and case.weighhf in your directory, then in order to > generate these files, during the 1st iteration lapw1 and lapw2 will > be executed one additional time compared to the next iterations. > > F. Tran > > On Sun, 1 Sep 2013, 西村 真一 wrote: > >> Dear WIEN2k users, >> >> I am trying to perform the hybrid functionals calculation with >> -hf of option like: >> $ runsp -hf -p. >> >> The version of WIEN2k is 13.1. >> >> With the -hf execution lapw1 and lapw2 with the FBZ-klist do not run in >> parallel mode, >> while the normal runsp runs in parallel mode (MPI/k-point), >> I checked the runsp script, and found that >> the lines for the calculations with FBZ-klist do not have the $para variable. >> >> We can not run the FBZ calculations with any parallel options? >> >> Thanks in advance, >> >> Shinichi Nishimura >> ___ >> Wien mailing list >> Wien@zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> SEARCH the MAILING-LIST at: >> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Parallel execution of hybrid functional calculation
Dear WIEN2k users, I am trying to perform the hybrid functionals calculation with -hf of option like: $ runsp -hf -p. The version of WIEN2k is 13.1. With the -hf execution lapw1 and lapw2 with the FBZ-klist do not run in parallel mode, while the normal runsp runs in parallel mode (MPI/k-point), I checked the runsp script, and found that the lines for the calculations with FBZ-klist do not have the $para variable. We can not run the FBZ calculations with any parallel options? Thanks in advance, Shinichi Nishimura ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
