[Wien] gcc-gfortran compilation problem
Dear users and developers I have encountered a problem while compiling WIEN2k ver 12.1. I am running a machine with system Fedora 16 (64 bit version) and with Intel Core 2 processor. My compiler is gcc-gfortran. I have ATLAS math library installed. During compilation process I can see several messages similar to this: ### assign 2021 to iform1 1 Warning: Deleted feature: ASSIGN statement at (1) init.f:264.17: READ(9,iform1) (CLM(I,L,JATOM),I=1,JRJ) 1 Warning: Deleted feature: ASSIGNED variable in FORMAT tag at (1) ### and this: ### CALL CFFTI1 (N,WSAVE(IW1),WSAVE(IW2)) 1 Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4) fftpack_helpers.f:366.40: CALL CFFTF1 (N,C,WSAVE,WSAVE(IW1),WSAVE(IW2)) 1 Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4) fftpack_helpers.f:122.29: ### And this results with this message at the end of compilation process: ### Compile time errors (if any) were: SRC_aim/compile.msg:make[1]: *** [aim] Error 1 SRC_aim/compile.msg:make: *** [real] Error 2 SRC_aim/compile.msg:make[1]: *** [aimc] Error 1 SRC_aim/compile.msg:make: *** [complex] Error 2 SRC_dipan/compile.msg:make: *** [dipan] Error 1 SRC_filtvec/compile.msg:make[1]: *** [filtvec] Error 1 SRC_filtvec/compile.msg:make: *** [real] Error 2 SRC_filtvec/compile.msg:make[1]: *** [filtvecc] Error 1 SRC_filtvec/compile.msg:make: *** [complex] Error 2 SRC_hf/compile.msg:Error: Syntax error in array constructor at (1) SRC_hf/compile.msg:Error: Syntax error in array constructor at (1) SRC_hf/compile.msg:make[1]: *** [calc_exhfvv.o] Error 1 SRC_hf/compile.msg:make: *** [real] Error 2 SRC_hf/compile.msg:Error: Syntax error in array constructor at (1) SRC_hf/compile.msg:Error: Syntax error in array constructor at (1) SRC_hf/compile.msg:make[1]: *** [calc_exhfvv.o] Error 1 SRC_hf/compile.msg:make: *** [complex] Error 2 SRC_hf/compile.msg:modules_tmp_.F:182: Error: Can't open included file 'mpif.h' SRC_hf/compile.msg:make[1]: *** [modules.o] Error 1 SRC_hf/compile.msg:make: *** [rp] Error 2 SRC_hf/compile.msg:modules_tmp_.F:182: Error: Can't open included file 'mpif.h' SRC_hf/compile.msg:make[1]: *** [modules.o] Error 1 SRC_hf/compile.msg:make: *** [cp] Error 2 SRC_kgen/compile.msg:Error: Logicals at (1) must be compared with .eqv. instead of .eq. SRC_kgen/compile.msg:make: *** [arbmsh.o] Error 1 SRC_lapw0/compile.msg:Error: Logicals at (1) must be compared with .neqv. instead of .ne. SRC_lapw0/compile.msg:Error: Logicals at (1) must be compared with .eqv. instead of .eq. SRC_lapw0/compile.msg:Error: Logicals at (1) must be compared with .eqv. instead of .eq. SRC_lapw0/compile.msg:make[1]: *** [lapw0.o] Error 1 SRC_lapw0/compile.msg:make: *** [seq] Error 2 SRC_lapw0/compile.msg:modules.F:22: Error: Can't open included file 'mpif.h' SRC_lapw0/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw0/compile.msg:make: *** [para] Error 2 SRC_lapw1/compile.msg:make[1]: *** [lapw1] Error 1 SRC_lapw1/compile.msg:make: *** [real] Error 2 SRC_lapw1/compile.msg:make[1]: *** [lapw1c] Error 1 SRC_lapw1/compile.msg:make: *** [complex] Error 2 SRC_lapw1/compile.msg:modules_tmp_.F:33: Error: Can't open included file 'mpif.h' SRC_lapw1/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw1/compile.msg:make: *** [rp] Error 2 SRC_lapw1/compile.msg:modules_tmp_.F:33: Error: Can't open included file 'mpif.h' SRC_lapw1/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw1/compile.msg:make: *** [cp] Error 2 SRC_lapw2/compile.msg:make[1]: *** [lapw2] Error 1 SRC_lapw2/compile.msg:make: *** [real] Error 2 SRC_lapw2/compile.msg:make[1]: *** [lapw2c] Error 1 SRC_lapw2/compile.msg:make: *** [complex] Error 2 SRC_lapw2/compile.msg:modules_tmp_.F:47: Error: Can't open included file 'mpif.h' SRC_lapw2/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw2/compile.msg:make: *** [rp] Error 2 SRC_lapw2/compile.msg:modules_tmp_.F:47: Error: Can't open included file 'mpif.h' SRC_lapw2/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw2/compile.msg:make: *** [cp] Error 2 SRC_lapw7/compile.msg:make[1]: *** [lapw7] Error 1 SRC_lapw7/compile.msg:make: *** [real] Error 2 SRC_lapw7/compile.msg:make[1]: *** [lapw7c] Error 1 SRC_lapw7/compile.msg:make: *** [complex] Error 2 SRC_lapwdm/compile.msg:make[1]: *** [lapwdm] Error 1 SRC_lapwdm/compile.msg:make: *** [real] Error 2 SRC_lapwdm/compile.msg:make[1]: *** [lapwdmc] Error 1 SRC_lapwdm/compile.msg:make: *** [complex] Error 2 SRC_lapwso/compile.msg:make: *** [lapwso] Error 1 SRC_mini/compile.msg:make: *** [mini] Error 1 SRC_mixer/compile.msg:make: *** [mixer] Error 1 SRC_pairhess/compile.msg:make: *** [pairhess] Error 1 SRC_qtl/compile.msg:make: *** [qtl] Error 1 SRC_structeditor/compile.
[Wien] BerryPI error
Hello Mostefa, I am glad the code finally worked for your installation. I would suggest to try BiCoO3 first without the spin polarization. The spin polarization is presently not captured in BerryPI. Could you please expand on why do you need SP? I never used DFT+U, so I cannot make a comment at the moment. Let me take a look. Thank you Oleg >>> On 1/6/2013 at 12:48 PM, in message <1357494529.9587.YahooMailNeo at web172102.mail.ir2.yahoo.com>, mostefa djermouni wrote: > Dear Oleg Rubel, > > Thanks for your interesting, I have worked with BerryPI-code and I tried the > tutorials. > > I have tried to calculate the polarisation of BiCoO3 in Tetragonal-AFM-C-type > but I think the spin polarization is didn't take into account with this > BerryPI-code, what shall I do in this case? And How can I calculate with > DFT+U ? > > Thank you very much for your kind cooperation. > > > > --- > Mostefa DJERMOUNI > Modeling and Simulation in Materials Science Laboratory > University of Sidi Bel-Abbes > 22000 Sidi Bel-Abbes, Algeria > Tel: +213 795 626 105 > ---
[Wien] case.inhf
> Best Regards > > Ali > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/3e9142d4/attachment.htm>
[Wien] case.inhf
11 can not be the number of occupied bands. Search for :BAN in case.scf and then you can see how many bands are occupied (the last column is the occupancy). Furthermore, your system (Bi2Sr2CaCu2O8) looks maybe too big for hybrid calculations. I don't know what computer ressources you have, but I doubt that you can do a hybrid calculations on this system (hybrid calculations are VERY expensive). F. Tran -wien-bounces at zeus.theochem.tuwien.ac.at wrote: - To: A Mailing list for WIEN2k users From: ali ghafari Sent by: wien-bounces at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: 01/07/2013 12:51PM Subject: Re: [Wien] case.inhf Dear Prof. Tran regarding your suggestion about ' nband' in case.inhf. In the Bi2Sr2CaCu2O8 compound I would like to use B3LYP, while the occupation number is about 11 at the case.scf. The question is that when I put any numbers less than 100 the error appears due to the less value of 'nband' and calculation is stoped. ? What is your advice? ?Wwith Best Regards Ali From: "tran at theochem.tuwien.ac.at" To: A Mailing list for WIEN2k users Sent: Thursday, September 20, 2012 1:40 PM Subject: Re: [Wien] case.inhf Search for :BAN in case.scf. The last column is the occupation number. On Thu, 20 Sep 2012, ali ghafari wrote: > Dear Prof. Tran > Thank you very much for your replay. > But? Could you please explain to me how can I find the number of partially > occupied band in case.scf? > I can not find any explanation in the UG. > > Best Regards > Ali > > > > >? From: "tran at theochem.tuwien.ac.at" > To: A Mailing list for WIEN2k users > Sent: Wednesday, September 19, 2012 1:06 PM > Subject: Re: [Wien] case.inhf >? > Why not, but I think that it is not really more simple than just looking > at the number n_occ of (partially) occupied bands in case.scf and choosing > nband = n_occ + a few more bands. But remember that nband in case.inhf is > a parameter (similar to R*K_max) which has to be tested. > > One last thing: the purpose of nband in case.in1 is not at all the same > as nband in case.inhf. > > F. Tran > > On Wed, 19 Sep 2012, ali ghafari wrote: > > > Dear Prof. Blaha > > > > For hybrid functionals case.inhf is necessary as discussed in the UG on > > pages 49 and 97. But the value of "nband' at case.inhf is confusing. on the > > page 97 of UG has mentioned "? nband should be at least equal to the > > number of (partially) occupied bands plus one". While at the line 5 of > > case.in1 the value of nband is automatically determined ( UG page 102) by > > "?? nband = ne ? 2.0 + 5 " which is number of eigenvalues. Can we consider > > inband of case.inhf is equals: (eigenvalues -5)/2+1 which is extracted from > > case.in1? > > ?? > > > > Best Regards > > Ali > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/8917d869/attachment.htm>
[Wien] What should be criteria for selection of RMTs?
Respected All WIEN2k Users, Greetings! Please comments and give suggestion on two basic question. First question is 1. What should be criteria for selecting radius of muffin tin (RMT) of any atom in WIEN2k code. 2. How can we choose the K-point value in WIIEN2k code. Please spare some time for this. I am waiting for your reply. Regards, Sanjay -- *"DO HELP WHO NEED HELP"* * * *SANJAY KUMAR SINGH* SCHOOL OF STUDIES IN PHYSICS JIWAJI UNIVERSITY, GWALIOR - 474 011 MADHYA PRADESH, INDIA Mobile : +91-9229979962 PHONE : +91-751-2442781, (Office) FAX : +91-751-2442784 -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/df6e386d/attachment.htm>
[Wien] gcc-gfortran compilation problem
; SRC_lapw2/compile.msg:make[1]: *** [lapw2] Error 1 > SRC_lapw2/compile.msg:make: *** [real] Error 2 > SRC_lapw2/compile.msg:make[1]: *** [lapw2c] Error 1 > SRC_lapw2/compile.msg:make: *** [complex] Error 2 > SRC_lapw2/compile.msg:modules_tmp_.F:47: Error: Can't open included > file 'mpif.h' > SRC_lapw2/compile.msg:make[1]: *** [modules.o] Error 1 > SRC_lapw2/compile.msg:make: *** [rp] Error 2 > SRC_lapw2/compile.msg:modules_tmp_.F:47: Error: Can't open included > file 'mpif.h' > SRC_lapw2/compile.msg:make[1]: *** [modules.o] Error 1 > SRC_lapw2/compile.msg:make: *** [cp] Error 2 > SRC_lapw7/compile.msg:make[1]: *** [lapw7] Error 1 > SRC_lapw7/compile.msg:make: *** [real] Error 2 > SRC_lapw7/compile.msg:make[1]: *** [lapw7c] Error 1 > SRC_lapw7/compile.msg:make: *** [complex] Error 2 > SRC_lapwdm/compile.msg:make[1]: *** [lapwdm] Error 1 > SRC_lapwdm/compile.msg:make: *** [real] Error 2 > SRC_lapwdm/compile.msg:make[1]: *** [lapwdmc] Error 1 > SRC_lapwdm/compile.msg:make: *** [complex] Error 2 > SRC_lapwso/compile.msg:make: *** [lapwso] Error 1 > SRC_mini/compile.msg:make: *** [mini] Error 1 > SRC_mixer/compile.msg:make: *** [mixer] Error 1 > SRC_pairhess/compile.msg:make: *** [pairhess] Error 1 > SRC_qtl/compile.msg:make: *** [qtl] Error 1 > SRC_structeditor/compile.msg:make[1]: *** [ncmsymmetry] Error 1 > SRC_structeditor/compile.msg:make: *** [all] Error 2 > SRC_vecpratt/compile.msg:make[1]: *** [vecpratt] Error 1 > SRC_vecpratt/compile.msg:make: *** [real] Error 2 > SRC_vecpratt/compile.msg:make[1]: *** [vecprattc] Error 1 > SRC_vecpratt/compile.msg:make: *** [complex] Error 2 > SRC_structeditor/SRC_ncmsymmetry/compile.msg:make: *** [ncmsymmetry] Error > 1 > > ### > > This problem results in improper working of the software. When I try > to calculate one of example struct files provided with WIEN2k (in this > case - coo.struct): > > ### > > At line 138 of file insld.f (unit = 6, file = 'coo.outputst') > Fortran runtime error: Expected INTEGER for item 1 in formatted > transfer, got REAL > (/,'WARNING: R0=",f8.6," for atom',i5," Z=",f6.2," too big. Use 0.0001",/) >^ > 0.000u 0.000s 0:10.64 0.0% 0+0k 0+64io 0pf+0w > error: command /root/WIEN/lstart lstart.def failed > >stop error > > ## > > I "did my homework" and found out that this regards a function that > was present in fortran 77, deprecated in fortran 90 and deleted in > fortran 95. But as I can see script for configuring WIEN2k is prepared > for usage gfortran so I suspect that there is simple way of solving > this. > > I have entertained an idea of changing compiler to g77 but as it turns > out I could not find a version compatible with 64 bit system. I also > resorted to (and failed) attempts of using f2c as a compiler. > > I searched trough Manual, FAQ and the mailing lists but I did not find > a solution. I found one similar but unanswered post on a mailing list. > Please point me in the right direction. Should I change my compiler > (if it is the case, then which should i chose for problemless > compilation)? Or did I forget/miss something? > > Best regards > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Gyorgi -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/4fe7189a/attachment.htm>
[Wien] [SPAM?] Error is BS plotting using hybrid functionals
Dear users of WIEN2k, I am trying to calculate the band structure of a semiconductor using a hybrid functional.After a successful SCF run and creating the case.klist_band file, I run "run_bandplothf_lapw".LAPW1 ends successfully, but running the "x hf -band" command, the error message "error in create_stars 1" appears.Can you help me finding the cause? Best regards,Ali --Ali Tavana, PhD, Assistant Prof.?, Department of Physics, University of Mohaghegh Ardabili, Ardabil, Iran. TEL: +98 451 5512081 (2430) FAX: +98 451 5514701 EMAIL: a_tavana at alum.sharif.edu -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/fcb85e43/attachment.htm>
[Wien] Electron density at ruthenium nucleus
I checked your scf and struct files: a) Please use identical RMT for Ru for the 2 cases. Since RuO2 forces you to have r(Ru)=2.0), use it also for hcp-Ru. (I don't think the effect will be very large, but ...) b) You cannot do these calculations with just ONE k-point ! For metallic Ru you should use something like "1" when running x kgen; and since also RuO2 is metallic, use a similar number (maybe 5000, since RuO2 contains more atoms/cell than Ru). c) Finally, check how much the differences in :RTO depend on RKMAX (case.in1; 7 by default). Once you have the first scf-calculation saved, increase it to 8, do another run_lapw and compare the resulting RTO The possible errors are not so easy to quantify. Besides computational parameters (which you can check as mentioned above), the error from DFT is hard to quantify and only from experience for a certain quantity in comparison with experiment we can estimate it. From my experience with Isomer shifts in Fe (M?ssbauer), it should be ok within 10-20 %, but it could be different for Ru ForwardedMessage.eml Subject: Electron density at ruthenium nucleus From: Robert Larson List-Post: wien@zeus.theochem.tuwien.ac.at Date: 01/05/2013 06:13 PM To: wien at zeus.theochem.tuwien.ac.at Hello, I would like to compare the change in electron density at the nucleus of a ruthenium atom in an Ru crystal versus in (rutile) ruthenium oxide, RuO2. This is for Ru97 electron capture decay half life predictions. I am seeing a difference of 0.02% for total electron density by comparing the :RTO001 values for each case -- which agrees well with experimental data. I have attached the struct and scf files for each case. My questions are 1) do these calculations look reasonable? and 2) what would an estimate be for the uncertainty of :RTO electron density values? I am running WIEN2k_12.1 (Release 22/7/2012) under mac OSX 10.8.2 and Intel Fortran composer_xe_2011_sp1.9.289. Thanks very much, Robert Larson Colorado School of Mines Golden, CO -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] Error is BS plotting using hybrid functionals
Hi, If the files case.klist_ibz, case.klist_fbz and case.outputkgenhf are the same as the ones used for the SCF run, then this error should not appear. Are you sure that you did not modify one of them before running "run_bandplothf_lapw"? F. Tran -wien-bounces at zeus.theochem.tuwien.ac.at wrote: - To: A Mailing list for WIEN2k users From: Ali Tavana Sent by: wien-bounces at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: 01/07/2013 09:37AM Subject: [Wien] [SPAM?] Error is BS plotting using hybrid functionals Dear users of WIEN2k, I am trying to calculate the band structure of a semiconductor using a hybrid functional. After a?successful SCF run?and creating the case.klist_band file, I run "run_bandplothf_lapw". LAPW1 ends successfully, but running the "x hf -band" command, the error message "error in create_stars 1" appears. Can you help me finding the cause? Best regards, Ali ? -- Ali Tavana, PhD, Assistant Prof.?, Department of Physics, University of Mohaghegh Ardabili, Ardabil, Iran. TEL: +98 451 5512081 (2430) FAX: +98 451 5514701 EMAIL: a_tavana at alum.sharif.edu ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/ec5b1e9f/attachment.htm>
[Wien] What should be criteria for selection of RMTs?
> 1. What should be criteria for selecting radius of muffin tin (RMT) of > any atom in WIEN2k code. http://www.wien2k.at/reg_user/faq/rmt.html > 2. How can we choose the K-point value in WIIEN2k code. increase, increase, increase,... until your property of interest is converged (preferably for a small yet relevant model system). Stefaan
[Wien] case.inhf
Dear Prof. Tran Thank you very much for your replay. I'm using cluster for this calculation. the :BAN in case.scf is in the following, as you said the last column is occupancy but it is less than 11?is it right? with Best Regards Ali ??? Bandranges (emin - emax) and occupancy: :BAN00070:? 70??? 0.428082??? 0.509292? 1. :BAN00071:? 71??? 0.440837??? 0.511967? 1. :BAN00072:? 72??? 0.460794??? 0.520858? 1. :BAN00073:? 73??? 0.471917??? 0.522531? 1. :BAN00074:? 74??? 0.471972??? 0.529510? 1. :BAN00075:? 75??? 0.495224??? 0.541786? 1. :BAN00076:? 76??? 0.496657??? 0.544179? 1. :BAN00077:? 77??? 0.509514??? 0.760574? 0.51995576 :BAN00078:? 78??? 0.509898??? 0.765628? 0.40435460 :BAN00079:? 79??? 0.604807??? 0.829075? 0.03620490 :BAN00080:? 80??? 0.615796??? 0.867992? 0.01107466 :BAN00081:? 81??? 0.801158??? 0.905668? 0. :BAN00082:? 82??? 0.802653??? 0.905668? 0. :BAN00083:? 83??? 0.846712??? 0.913216? 0. :BAN00084:? 84??? 0.866694??? 0.925919? 0. :BAN00085:? 85??? 0.920677??? 1.009571? 0.? From: "f.tran at pci.uzh.ch" To: A Mailing list for WIEN2k users Sent: Monday, January 7, 2013 1:29 PM Subject: Re: [Wien] case.inhf 11 can not be the number of occupied bands. Search for :BAN in case.scf and then you can see how many bands are occupied (the last column is the occupancy). Furthermore, your system (Bi2Sr2CaCu2O8) looks maybe too big for hybrid calculations. I don't know what computer ressources you have, but I doubt that you can do a hybrid calculations on this system (hybrid calculations are VERY expensive). F. Tran -wien-bounces at zeus.theochem.tuwien.ac.at wrote: - To: A Mailing list for WIEN2k users From: ali ghafari Sent by: wien-bounces at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: 01/07/2013 12:51PM Subject: Re: [Wien] case.inhf Dear Prof. Tran regarding your suggestion about ' nband' in case.inhf. In the Bi2Sr2CaCu2O8 compound I would like to use B3LYP, while the occupation number is about 11 at the case.scf. The question is that when I put any numbers less than 100 the error appears due to the less value of 'nband' and calculation is stoped. ? What is your advice? ?Wwith Best Regards Ali From: "tran at theochem.tuwien.ac.at" To: A Mailing list for WIEN2k users Sent: Thursday, September 20, 2012 1:40 PM Subject: Re: [Wien] case.inhf Search for :BAN in case.scf. The last column is the occupation number. On Thu, 20 Sep 2012, ali ghafari wrote: > Dear Prof. Tran > Thank you very much for your replay. > But? Could you please explain to me how can I find the number of partially > occupied band in case.scf? > I can not find any explanation in the UG. > > Best Regards > Ali > > > > >? From: "tran at theochem.tuwien.ac.at" > To: A Mailing list for WIEN2k users > Sent: Wednesday, September 19, 2012 1:06 PM > Subject: Re: [Wien] case.inhf >? > Why not, but I think that it is not really more simple than just looking > at the number n_occ of (partially) occupied bands in case.scf and choosing > nband = n_occ + a few more bands. But remember that nband in case.inhf is > a parameter (similar to R*K_max) which has to be tested. > > One last thing: the purpose of nband in case.in1 is not at all the same > as nband in case.inhf. > > F. Tran > > On Wed, 19 Sep 2012, ali ghafari wrote: > > > Dear Prof. Blaha > > > > For hybrid functionals case.inhf is necessary as discussed in the UG on > > pages 49 and 97. But the value of "nband' at case.inhf is confusing. on the > > page 97 of UG has mentioned "? nband should be at least equal to the > > number of (partially) occupied bands plus one". While at the line 5 of > > case.in1 the value of nband is automatically determined ( UG page 102) by "?? nband = ne ? 2.0 + 5 " which is number of eigenvalues. Can we consider inband of case.inhf is equals: (eigenvalues -5)/2+1 which is extracted from case.in1? > > ?? > > > > Best Regards > > Ali > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/036b78fa/attachment.htm>
[Wien] case.inhf
Dear Prof. Tran regarding your suggestion about ' nband' in case.inhf. In the Bi2Sr2CaCu2O8 compound I would like to use B3LYP, while the occupation number is about 11 at the case.scf. The question is that when I put any numbers less than 100 the error appears due to the less value of 'nband' and calculation is stoped. ? What is your advice? ?Wwith Best Regards Ali From: "tran at theochem.tuwien.ac.at" To: A Mailing list for WIEN2k users Sent: Thursday, September 20, 2012 1:40 PM Subject: Re: [Wien] case.inhf Search for :BAN in case.scf. The last column is the occupation number. On Thu, 20 Sep 2012, ali ghafari wrote: > Dear Prof. Tran > Thank you very much for your replay. > But? Could you please explain to me how can I find the number of partially > occupied band in case.scf? > I can not find any explanation in the UG. > > Best Regards > Ali > > > > >? From: "tran at theochem.tuwien.ac.at" > To: A Mailing list for WIEN2k users > Sent: Wednesday, September 19, 2012 1:06 PM > Subject: Re: [Wien] case.inhf >? > Why not, but I think that it is not really more simple than just looking > at the number n_occ of (partially) occupied bands in case.scf and choosing > nband = n_occ + a few more bands. But remember that nband in case.inhf is > a parameter (similar to R*K_max) which has to be tested. > > One last thing: the purpose of nband in case.in1 is not at all the same > as nband in case.inhf. > > F. Tran > > On Wed, 19 Sep 2012, ali ghafari wrote: > > > Dear Prof. Blaha > > > > For hybrid functionals case.inhf is necessary as discussed in the UG on > > pages 49 and 97. But the value of "nband' at case.inhf is confusing. on the > > page 97 of UG has mentioned "? nband should be at least equal to the > > number of (partially) occupied bands plus one". While at the line 5 of > > case.in1 the value of nband is automatically determined ( UG page 102) by > > "?? nband = ne ? 2.0 + 5 " which is number of eigenvalues. Can we consider > > inband of case.inhf is equals: (eigenvalues -5)/2+1 which is extracted from > > case.in1? > > ?? > > > > Best Regards > > Ali > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130107/0ddb6069/attachment.htm>
