Re: [Wien] [SUSPECTED SPAM] Re: [SPAM] Re: Forward of moderated message
All right, I am going to do that. Thank you. Pascal > Le 7 mars 2021 à 22:16, Peter Blaha a écrit : > > Forget kram at the moment. > Check case.joint if this file looks ok. It contains the unbroadened imag > epsilon (eps2). > It should be zero up to the band gap, but increase afterwards. > > Check the band ranges in case.scf2 > You will see how far it reaches in energy above EF. > > PS: Hybrid DFT calculations: > > Since hybrid DFT is expensive, it is VERY important to check convergence of > various parameters, starting with SMALL parameters. > > Eg. a scf calculation with 12x12x12 full k-mesh is almost certainly an > overkill. If this is a semiconductor, I'd start with 4x4x4 and later check > it. > > There is a good reason that we offer the "reduced k-mesh" It saves a lot of > time. Maybe for beginning a 2x2x2 mesh is fine as a start. > > Number of bands: As L. Marks said: maybe the technical minimum NB+1 is > missleading in the UG. This is certainly not converged. I would add start > with adding 2-3 bands/atom in the unit cell. If you have 9 atoms/cell, add > 20-30 bands at the beginning. ( This depends a lot on the type of atom. You > should always add all empty orbitals of an atom (all d-orbitals of a TM atom, > or all p for C or Si, P, S ) > > Once you have a result for optics, increase (double) these parameters and > check how much the optics has changed. > smime.p7s Description: S/MIME cryptographic signature ___ 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] [SPAM] Re: Forward of moderated message
Forget kram at the moment. Check case.joint if this file looks ok. It contains the unbroadened imag epsilon (eps2). It should be zero up to the band gap, but increase afterwards. Check the band ranges in case.scf2 You will see how far it reaches in energy above EF. PS: Hybrid DFT calculations: Since hybrid DFT is expensive, it is VERY important to check convergence of various parameters, starting with SMALL parameters. Eg. a scf calculation with 12x12x12 full k-mesh is almost certainly an overkill. If this is a semiconductor, I'd start with 4x4x4 and later check it. There is a good reason that we offer the "reduced k-mesh" It saves a lot of time. Maybe for beginning a 2x2x2 mesh is fine as a start. Number of bands: As L. Marks said: maybe the technical minimum NB+1 is missleading in the UG. This is certainly not converged. I would add start with adding 2-3 bands/atom in the unit cell. If you have 9 atoms/cell, add 20-30 bands at the beginning. ( This depends a lot on the type of atom. You should always add all empty orbitals of an atom (all d-orbitals of a TM atom, or all p for C or Si, P, S ) Once you have a result for optics, increase (double) these parameters and check how much the optics has changed. Am 07.03.2021 um 21:53 schrieb pboulet: ok, I can try with more bands. 50 bands correspond to NB+5, which is probably not enough (I am not sure how many is ‘many’ for optics). As I understand, optics with hybrids seems beyond what is feasible even with supercomputers… But increasing the number of bands may not solve the problem I noticed about the "forrtl: severe (64): input conversion error, unit 10, file Cu3SbS4_nb50_k121212.joint" with kram. Thank you Best, Pascal Le 7 mars 2021 à 20:25, Peter Blaha a écrit : Are you sure you have enough bands in the HF calculation ? For a compound Cu3SbS4 nb=50 looks very small. You probably need even for the scf run more than NB+1 bands (this is formally enough, but results are not converged), and for optics you need MANY unoccupied states !!! Check case.in1 and case.inhf and case.inop. Betreff: Re: [Wien] Running optics with hybrid functional Von: pboulet Datum: 07.03.2021, 12:16 An: A Mailing list for WIEN2k users Hello, I am resuming the discussion on this topic as I have not solved the problem yet. As Peter sait in his previous post, I did _not_ use x kgen but rather runkgenhf_lapw in all my calculations with HF. The SCF procedure with HF looks clear to me in the manual. I am less comfortable with the x optic -hf procedure. I recall that I have generated a mesh with 163 k-points in the IBZ (12x12x12). As it turns out, I can converge a HF SCF with this many k-point mesh, so I did it. This way I do not have to resort to redklist or newklist; I suppose it is not incorrect for further optics calculations… Once the SCF had converged I ran the following sequence for the optical properties: x lapw0 -grr -p x lapw0 -p x lapw1 -p -c x lapw2 -p -c x lcore x hf -mode1 -p -c x lapw2 -fermi -hf -p x optic -hf -p x joint -hf x kram Until x joint -hf -p, the calculations seem to go fine, although this may not be true in the sense of the resulting data (see Im(eps) and Re(eps) below). But then there is a problem with x kram as I have an error message, which is: opmat allocated with kkk,nemax1,ncol 163 51 2 ( 0 MB) SUM OF WEIGHTS:2.01 JOINT DOS END 0.047u 0.172s 0:00.80 26.2% 0+0k 2280+464io 0pf+0w forrtl: severe (64): input conversion error, unit 10, file /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint forrtl: severe (64): input conversion error, unit 10, file /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint Image PCRoutineLineSource kram 0040AE46 Unknown Unknown Unknown kram 00425BA0 Unknown Unknown Unknown kram 00403020 MAIN__ 83 kram.f kram 00402A9E Unknown Unknown Unknown libc-2.17.so 2B8821F76555 __libc_start_main Unknown Unknown kram 004029A9 Unknown Unknown Unknown 0.001u 0.017s 0:00.21 4.7% 0+0k 1496+0io 0pf+0w error: command /scratch/cnt0022/pmc6881/paboulet/wien2k/19.2/kram kram.def failed The joint file contains: # Energy [eV] Im(eps)xx Im(eps)zz Re(eps)xx Re(eps)zz # 0.013606 -0.134882E-39 -0.104665E-39 0.10E+01 0.10E+01 0.027211 -0.639539E-40 -0.496264E-40 0.10E+01 0.10E+01 0.040817 -0.392533E-40 -0.304594E-40 0.10E+01 0.10E+01 … There is a line break in the file between Re(eps)xx and Re(eps)zz. Is it normal? Note also that I still get Im(eps)~0 and Re(eps)=1.0 irrespective
Re: [Wien] [SPAM] Re: Forward of moderated message
ok, I can try with more bands. 50 bands correspond to NB+5, which is probably not enough (I am not sure how many is ‘many’ for optics). As I understand, optics with hybrids seems beyond what is feasible even with supercomputers… But increasing the number of bands may not solve the problem I noticed about the "forrtl: severe (64): input conversion error, unit 10, file Cu3SbS4_nb50_k121212.joint" with kram. Thank you Best, Pascal > Le 7 mars 2021 à 20:25, Peter Blaha a écrit : > > Are you sure you have enough bands in the HF calculation ? > For a compound Cu3SbS4 nb=50 looks very small. > > You probably need even for the scf run more than NB+1 bands (this is formally > enough, but results are not converged), and for optics you need MANY > unoccupied states !!! > Check case.in1 and case.inhf and case.inop. > > > > Betreff: > Re: [Wien] Running optics with hybrid functional > Von: > pboulet > Datum: > 07.03.2021, 12:16 > An: > A Mailing list for WIEN2k users > > Hello, > > I am resuming the discussion on this topic as I have not solved the problem > yet. > As Peter sait in his previous post, I did _not_ use x kgen but rather > runkgenhf_lapw in all my calculations with HF. > > The SCF procedure with HF looks clear to me in the manual. I am less > comfortable with the x optic -hf procedure. > > I recall that I have generated a mesh with 163 k-points in the IBZ > (12x12x12). As it turns out, I can converge a HF SCF with this many k-point > mesh, so I did it. This way I do not have to resort to redklist or newklist; > I suppose it is not incorrect for further optics calculations… > > Once the SCF had converged I ran the following sequence for the optical > properties: > x lapw0 -grr -p > x lapw0 -p > x lapw1 -p -c > x lapw2 -p -c > x lcore > x hf -mode1 -p -c > x lapw2 -fermi -hf -p > x optic -hf -p > x joint -hf > x kram > > Until x joint -hf -p, the calculations seem to go fine, although this may not > be true in the sense of the resulting data (see Im(eps) and Re(eps) below). > But then there is a problem with x kram as I have an error message, which is: > > opmat allocated with kkk,nemax1,ncol 163 51 2 ( > 0 MB) > SUM OF WEIGHTS:2.01 > JOINT DOS END > 0.047u 0.172s 0:00.80 26.2% 0+0k 2280+464io 0pf+0w > forrtl: severe (64): input conversion error, unit 10, file > /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint > forrtl: severe (64): input conversion error, unit 10, file > /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint > Image PCRoutineLineSource > kram 0040AE46 Unknown Unknown Unknown > kram 00425BA0 Unknown Unknown Unknown > kram 00403020 MAIN__ 83 kram.f > kram 00402A9E Unknown Unknown Unknown > libc-2.17.so 2B8821F76555 __libc_start_main Unknown Unknown > kram 004029A9 Unknown Unknown Unknown > 0.001u 0.017s 0:00.21 4.7% 0+0k 1496+0io 0pf+0w > error: command /scratch/cnt0022/pmc6881/paboulet/wien2k/19.2/kram kram.def > failed > > > The joint file contains: > # Energy [eV] Im(eps)xx Im(eps)zz Re(eps)xx > Re(eps)zz > # > 0.013606 -0.134882E-39 -0.104665E-39 0.10E+01 0.10E+01 > 0.027211 -0.639539E-40 -0.496264E-40 0.10E+01 0.10E+01 > 0.040817 -0.392533E-40 -0.304594E-40 0.10E+01 0.10E+01 > … > > There is a line break in the file between Re(eps)xx and Re(eps)zz. Is it > normal? > > Note also that I still get Im(eps)~0 and Re(eps)=1.0 irrespective of the > energy, which is strange. > > > What could be the origin of these behaviours? > > Thank you for your time and help, > Best regards, > Pascal > > > > > Am 07.03.2021 um 12:48 schrieb wien-boun...@zeus.theochem.tuwien.ac.at: > > -- > -- > 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.atWIEN2k: http://www.wien2k.at > WWW: http://www.imc.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 smime.p7s Description: S/MIME cryptographic signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH t
Re: [Wien] Forward of moderated message
Are you sure you have enough bands in the HF calculation ? For a compound Cu3SbS4 nb=50 looks very small. You probably need even for the scf run more than NB+1 bands (this is formally enough, but results are not converged), and for optics you need MANY unoccupied states !!! Check case.in1 and case.inhf and case.inop. Betreff: Re: [Wien] Running optics with hybrid functional Von: pboulet Datum: 07.03.2021, 12:16 An: A Mailing list for WIEN2k users Hello, I am resuming the discussion on this topic as I have not solved the problem yet. As Peter sait in his previous post, I did _not_ use x kgen but rather runkgenhf_lapw in all my calculations with HF. The SCF procedure with HF looks clear to me in the manual. I am less comfortable with the x optic -hf procedure. I recall that I have generated a mesh with 163 k-points in the IBZ (12x12x12). As it turns out, I can converge a HF SCF with this many k-point mesh, so I did it. This way I do not have to resort to redklist or newklist; I suppose it is not incorrect for further optics calculations… Once the SCF had converged I ran the following sequence for the optical properties: x lapw0 -grr -p x lapw0 -p x lapw1 -p -c x lapw2 -p -c x lcore x hf -mode1 -p -c x lapw2 -fermi -hf -p x optic -hf -p x joint -hf x kram Until x joint -hf -p, the calculations seem to go fine, although this may not be true in the sense of the resulting data (see Im(eps) and Re(eps) below). But then there is a problem with x kram as I have an error message, which is: opmat allocated with kkk,nemax1,ncol 163 51 2 ( 0 MB) SUM OF WEIGHTS:2.01 JOINT DOS END 0.047u 0.172s 0:00.80 26.2% 0+0k 2280+464io 0pf+0w forrtl: severe (64): input conversion error, unit 10, file /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint forrtl: severe (64): input conversion error, unit 10, file /scratch/cnt0022/pmc6881/paboulet/WIEN2k/Cu3SbS4_nb50_k121212/Cu3SbS4_nb50_k121212.joint Image PCRoutineLineSource kram 0040AE46 Unknown Unknown Unknown kram 00425BA0 Unknown Unknown Unknown kram 00403020 MAIN__ 83 kram.f kram 00402A9E Unknown Unknown Unknown libc-2.17.so 2B8821F76555 __libc_start_main Unknown Unknown kram 004029A9 Unknown Unknown Unknown 0.001u 0.017s 0:00.21 4.7% 0+0k 1496+0io 0pf+0w error: command /scratch/cnt0022/pmc6881/paboulet/wien2k/19.2/kram kram.def failed The joint file contains: # Energy [eV] Im(eps)xx Im(eps)zz Re(eps)xx Re(eps)zz # 0.013606 -0.134882E-39 -0.104665E-39 0.10E+01 0.10E+01 0.027211 -0.639539E-40 -0.496264E-40 0.10E+01 0.10E+01 0.040817 -0.392533E-40 -0.304594E-40 0.10E+01 0.10E+01 … There is a line break in the file between Re(eps)xx and Re(eps)zz. Is it normal? Note also that I still get Im(eps)~0 and Re(eps)=1.0 irrespective of the energy, which is strange. What could be the origin of these behaviours? Thank you for your time and help, Best regards, Pascal Am 07.03.2021 um 12:48 schrieb wien-boun...@zeus.theochem.tuwien.ac.at: -- -- 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.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
Re: [Wien] opticcpara crashed for mstar
Dear Prof. Oleg Sorry to interrupt you. Earlier I was looking for the wrong file. My case.klist has 40 k-points and thus #KP also varies upto 40. >From my eigenvalue file, my VBM lies on band index=38 (XX) row number KP(YY) ENE 6531.08800-0.04699 So according to your hint, I should look for #KP 653 and then index number 38. But I have #KP upto 40. You also mentioned occupancy, but I could not understand it. Could you please correct me? Thank you in advance. Regards Bhamu On Thu, Mar 4, 2021 at 10:51 PM Rubel, Oleg wrote: > Oh, sorry about the misunderstanding. In your previous correspondence it > sounded as you had a confusion about which klist file is used. > > > In my case the CBM/CMB is at N-point which is located at 622 row number > in case.klist_band. But I have only 20 K-points in my case.klist and thus > the total KP in mstar output file is also 20. > > To get band edges, I would check an eigenvalues file to identify band > number XX, k point number YY, occupancy. Then look for a line "# KP: YY" > and band XX below that in the output of mstar. > > I hope it answers the question > Oleg > ___ > 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
