Re: [Wien] Wannier
Dear Lukasz, Wannier basis is pretty similar to TB basis, but they are not fully equivalent. In Wannier basis Hamiltonian contributions from quite distant neighbors are important, they are not automatically localized on atoms, have proper symmetry, etc. I recommend to check the following papers where proper TB is constructed from the Wannier functions: https://doi.org/10.1103/PhysRevB.92.085301 https://doi.org/10.1103/PhysRevMaterials.2.103805 https://doi.org/10.1103/PhysRevB.99.125117 Sincerely yours, Mikhail >Четверг, 15 февраля 2024, 1:41 +01:00 от pluto via Wien >: > >Dear All, > >I am interested to project WIEN2k band structure onto atomic orbitals, >but getting complex amplitudes. For example, for graphene Dirac band >(formed primarily by C 2pz) I would get two k-dependent complex numbers >A_C2pz(k) and B_C2pz(k), where A and B are the two inequivalent sites, >and these coefficients for other orbitals (near the Dirac points) would >be nearly zero. Of course, for graphene I can write a TB model and get >these numbers, but already for WSe2 monolayer TB model has several bands >(TB models for WSe2 are published but implementing would be >time-consuming), and for a generic material there is often no simple TB >model. > >Some time ago I looked at the WIEN2k wave functions, but because of the >way LAPW works, it is not a trivial task to project these onto atomic >orbitals. This is due to the radial wave functions, each one receiving >its own coefficient. > >I was wondering if I can somehow get such projection automatically using >Wien2Wannier, and later with some Wannier program. I thought it is good >to ask before I invest any time into this. > >And I would need it with spin, because I am interested with systems >where SOC plays a role. > >The reason I ask: >Simple model of photoemission can be made by assuming coherent addition >of atomic-like photoionization, with additional k-dependent initial band >amplitudes/phases. One can assume that radial integrals in photoemission >matrix elements don't have special structure and maybe just take atomic >cross sections of Yeh-Lindau. But one still needs these complex >coefficients to allow for interference of the emission from different >sites within the unit cell. I think for a relatively simple material >such as WSe2 monolayer, the qualitative result of this might be >reasonable. I am not aiming at anything quantitative since we have >one-step-model codes for quantitative. > >Any suggestion on how to do this projection (even approximately) within >the realm of WIEN2k would be welcome. > >Best, >Lukasz > > >PD Dr. Lukasz Plucinski >Group Leader, FZJ PGI-6 >Phone: +49 2461 61 6684 >https://electronic-structure.fz-juelich.de/ > >___ >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] lapwso segfault
Dear wien2k community, I am trying to check the convergence of problem with respect to Emax and the problem fails starting Emax~=8.5 (strained InP, 2 atoms in elementary cell) with segfault for lapwso. WIEN2k version is 23.2. Intel OneAPI 21 (ifort (IFORT) 2021.11.0 20231010). The problem occurs in memory allocation, mostly in line 836 of hmsec.F, sometimes in lines 843 or 1185 of same file, deallocation of work arrays. lwork is really small and I have plenty of memory on my system. The issue seems to have something with the OMP parallelization. The segfault occurs only when the code is run with 6 threads or more. Since I have two Xeon E5-2697 v3 on this machine, I would love to use at least 8 threads. Maybe someone has suggestions how to trace/fix this issue? Thank you in advance. Sincerely yours, Mikhail Nestoklon___ 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] init_lapw -nodstart and mBJ
Than you for the clarification! I was checking the new options of init_lapw and was confused by the following phrase in UG [page 73]: > Once you have a scf solution (and have ”saved” the results), you can rerun > init lapw with higher > precision and the -nodstart switch, to create a more accurate input (but > continue the scf with the > previously converged density). Sincerely yours, Mikhail Nestoklon > Среда, 25 октября 2023, 18:23 +02:00 от Peter Blaha > : > > This is the expected behaviour. > Why would you run init_lapw ... -nodstart again ? > It rewrites ALL input files (except the density of the last scf cycle). Thus > your mBJ setting are overwritten and you do another PBE calculation. > In essence, you have to run again init_mbj after init_lapw .. -nodstart. > In addition, be careful when using -prec 2/3: it will eventually reset the > RMTs (to make them smaller than 2.3), thus your old old density (clmsum,..) > will be on a different radial grid and incompatible with the new struct file. > Regards > Am 25.10.2023 um 15:07 schrieb Mikhail Nestoklon via Wien: > > Dear wien2k community, > > I encountered strange and unexpected problem. > > If I try to use init_lapw -nodstart with mBJ calculations, the results are > > quite strange. > > On bilk Si, init_lapw -prec 1n and converge mBJ in Koller paramerization, > > the gap is 1.151 eV. > > Next, init_lapw -prec 2n -nokshift -nodstart and run_lapw gives 0.599 eV. > > > > If I init_lapw -prec 2n -nokshift from scratch and converge mBJ in Koller > > parametrization, I got 1.150 eV > > > > Similar problem with similar numbers is with -prec 3n. > > > > Is there some limitation in using -nodstart not mentioned in UG (e.g. > > incompatibility with mGGA) or I am doing something wrong? > > > > WIEN2k version is 23.2. > > > > Thank you in advance. > > > > Sincerely yours, > > Mikhail Nestoklon > > ___ 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. f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: > > +43-158801165300 Email: peter.bl...@tuwien.ac.at WWW: > > http://www.imc.tuwien.ac.at WIEN2k: http://www.wien2k.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] init_lapw -nodstart and mBJ
Dear wien2k community, I encountered strange and unexpected problem. If I try to use init_lapw -nodstart with mBJ calculations, the results are quite strange. On bilk Si, init_lapw -prec 1n and converge mBJ in Koller paramerization, the gap is 1.151 eV. Next, init_lapw -prec 2n -nokshift -nodstart and run_lapw gives 0.599 eV. If I init_lapw -prec 2n -nokshift from scratch and converge mBJ in Koller parametrization, I got 1.150 eV Similar problem with similar numbers is with -prec 3n. Is there some limitation in using -nodstart not mentioned in UG (e.g. incompatibility with mGGA) or I am doing something wrong? WIEN2k version is 23.2. Thank you in advance. Sincerely yours, Mikhail Nestoklon___ 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] HF with HDLO?
Dear wien2k community, When I am trying to run calculations with hybrid exchange-correlation potential, the hf program produces an error without much details on what went wrong (error in calc_h_1: info not equal to 0). I see that there is some problem with the atom where I added HDLO (NaN in scf2hf). Without HDLO, same case works without any problem as expected. Is this expected behavior or this is some kind of bug? I checked the User Guide and the incompatibility between HDLO and HF is not mentioned. Thank you in advance. Sincerely yours, Mikhail Nestoklon___ 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] problems with parallel version of run_bandplothf_lapw
For klist_band I used xcrysden and chose the special points. What can be wrong with this file? Note that the problem occurs only after lapwso stage. Sincerely Mikhail P.S. The file is in attachment. Looks fine to me. >Среда, 8 июня 2022, 13:42 +03:00 от Lyudmila Dobysheva via Wien >: > >07.06.2022 19:11, Mikhail Nestoklon via Wien wrote: >> After lapw cycle (run_lapw -p -so -hf -redklist) I save the calculations >> and run ‘run_bandplothf_lapw -p -redklist -so’. >> I expect the energies to be in case.energyhfso file, but this file is >> corrupted. >> For my calculations, the klist_band has ~200 k points and it is split in 4 >> files with ~50 k points each. The resulting case.energyhfso_1, >> case.energyhfso_2, case.energyhfso_3, case.energyhfso_4 >> files contain the same k points which may be found in klist_band_? >> files, but the case.energyhfso file contains only first 29 k points from >> each of them. In addition, they have the same enumeration as >> in klist_band_? files and not in case.klist_band (i.e., after 29th k it >> is 1st again and so on). With case.energyhf the numbering of k points is >> correct: it is consistent with the main case.klist_band file. >> Is there something wrong with run_bandplothf_lapw or I am misusing it? > >I remember that similar strange things happened when the stage "Create >case.klist band" had been conducted in a wrong way. >How did you make it? Number of k-points is suspicious. > >Best wishes >Lyudmila Dobysheva > >-- >http://ftiudm.ru/content/view/25/103/lang,english/ >Institute of Physics and Technology, >Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci. >426000 Izhevsk Kirov str. 132 >Russia >--- >Tel. +7 (34I2)43-24-59 (office), +7 (9I2)OI9-795O (home) >Skype: lyuka18 (office), lyuka17 (home) >E-mail: lyuk...@mail.ru (office), lyuk...@gmail.com (home) >___ >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 PbSe_YSPBE0.klist_band Description: Binary data ___ 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] problems with parallel version of run_bandplothf_lapw
Dear wien2k community, I have strange problem with results of YSPBE0 calculations with spinorbit (WIEN2k 21.1). After lapw cycle (run_lapw -p -so -hf -redklist) I save the calculations and run ‘run_bandplothf_lapw -p -redklist -so’. I expect the energies to be in case.energyhfso file, but this file is corrupted. For my calculations, the klist_band has ~200 k points and it is split in 4 files with ~50 k points each. The resulting case.energyhfso_1, case.energyhfso_2, case.energyhfso_3, case.energyhfso_4 files contain the same k points which may be found in klist_band_? files, but the case.energyhfso file contains only first 29 k points from each of them. In addition, they have the same enumeration as in klist_band_? files and not in case.klist_band (i.e., after 29th k it is 1st again and so on). With case.energyhf the numbering of k points is correct: it is consistent with the main case.klist_band file. Is there something wrong with run_bandplothf_lapw or I am misusing it? Thank you in advance. Sincerely yours, Mikhail Nestoklon ___ 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] new script optimize_abc_lapw
Dear Prof. Blaha, Thank you for the explanation. The general idea was hard to get from the UG. Sincerely Mikhail >Пятница, 15 октября 2021, 19:37 +03:00 от Peter Blaha >: > >I think (hope) the parallelization of this script is well described in >the UG or simply in the "online help" using -h switch. It has multiple >options and levels for parallelization: > >psi11:/psi11/scratch> optimize_abc -h >USAGE: optimize_abc [-h -t 2/3 -sp -p -n X -FC X -d X -ctest X Y Z >-ana X -j "run_lapw -p ..." ] >optimizes a,(b),c lattice parameters >-p requires the presence of .machines (single jobstep) and > .machines_1...4 (9) for 4 (9) parallel jobsteps in the 2D (3D) case > >The script makes a scf calculation for the present lattice parameter in >the case directory. This calculation uses the standerd .machines file >when specifying "run_lapw -p" as job. > >However, then it has to make changes in 4 (or 9 for the 3Dcase) >directions. This can be done in serial or in parallel (using the -p >switch of optimize_abc). So with -p it will span 4 (9) run_lapw jobs in >parallel. >If you still have more cores available, you can in addition supply >.machines_1, .machines_2, ...4 (9) files. > >So suppose you have 4 nodes with 16 cores each, you could put into each >of these .machine_X files 16 different cores (eg. in mpi), but run 4 mpi >jobs in parallel. >In addition you create a .machines with all 64 cores for the "starting >job" (at least if it is still efficient for your example. Remember: a >very small cell will run MUCH LONGER in mpi with 64 cores (or even >crash) then on fewer cores. > >The "task" parallelization is MUCH more efficient then heavy mpi >parallelization. > > > >Am 15.10.2021 um 17:28 schrieb Mikhail Nestoklon: >> Dear wien2k community, >> I am trying to use new script optimize_abc_lapw on a cluster. Something >> in its behavior in terms of computer power consumption confused me and I >> am checking how it actually works. I realized that at some point (at >> least when ‘doing x-zchange’) it runs lapw0 and lapw1c and not >> lapw0_mpi, etc. The most strange part is that when it starts it >> correctly uses mpi versions of the programs. >> Is this correct behavior? >> I run the script as ‘optimize_abc_lapw -p’ at the end of slurm script >> which prepares .machines file. >> The structure is hexagonal. >> >> Thank you in advance. >> Sincerely yours, >> Mikhail Nestoklon >> >> ___ >> 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.f. Materials Chemistry, TU Vienna, A-1060 Vienna >Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 >Email: bl...@theochem.tuwien.ac.at WIEN2k: 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 ___ 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] new script optimize_abc_lapw
Dear wien2k community, I am trying to use new script optimize_abc_lapw on a cluster. Something in its behavior in terms of computer power consumption confused me and I am checking how it actually works. I realized that at some point (at least when ‘doing x-zchange’) it runs lapw0 and lapw1c and not lapw0_mpi, etc. The most strange part is that when it starts it correctly uses mpi versions of the programs. Is this correct behavior? I run the script as ‘optimize_abc_lapw -p’ at the end of slurm script which prepares .machines file. The structure is hexagonal. Thank you in advance. Sincerely yours, Mikhail Nestoklon ___ 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] external magnetic field using orb with spin-orbit interaction
Thank you for the comments. This is option 4 of orb package "Interaction with the external magnetic field" mentioned in page 127 of UG around (7.2). So, U=0. After your mail I realized that both "case.energysodn" AND "case.energysoup" contain the information I was looking for (splitting of the two- or four-times degenerate states in Gamma-point by the magnetic field) and now do not understand why I thought they should be different. Indeed, no more up and down spins after spin-orbit. Maybe, I was confused by the fact that there are two files in the output. Thank you for clarifying this. I will try to do the full cycle without runsp_c_lapw at all, maybe there is a difference. Sincerely yours, Mikhail Nestoklon >Вторник, 29 сентября 2020, 13:05 +03:00 от Peter Blaha >: > >You miss the physics of spin-orbit interaction. > >Spin-orbit MIXES spin-up and dn (spin is no longer a good quantumnumber). > >This means that each eigenvalue will contain contributions of spin-up >AND spin-dn. In many cases one spin will dominate, but they can also be >completely mixed. > >Of course, one can still project spin-up and dn out and this is done in >WIEN2k. >The amount of spin-up and dn for each eigenvalue can be found in the >case.norm* files. > >Regards > >PS: I don't understand your procedure. When you do runsp_c_lapw, you >FORCE spin-up and dn to be the same. Once you have a non-spinpolarized >density, it is very hard to get back to a magnetic state (except when >the runsp_c scf cycle is not done to full convergence). > >So how could you find some splitting of spin-up and dn states ??? > >And what U did you use (for which elements/states ??) > >On 9/29/20 11:47 AM, Mikhail Nestoklon wrote: >> Dear wien2k community, >> I am trying to estimate the g-factors in bulk semiconducting material. >> From the mail list and user guide I learned that orb may be used for >> this purpose (as discussed in beginning of this thread [1] and in >> section 7.4 of UG). >> Using the GaAs as a reference semiconductor I do the following steps >> (case.inorb and case.indmc files are more or less the same as in [1]): >> $ init_lapw -b -vxc 13 -sp >> $ runsp_c_lapw >> $ init_so_lapw >> $ runsp_lapw -so -orb >> In the end of this procedure I indeed see some splitting of spinup and >> spindown states in conduction band which corresponds to g-factor about 2 >> in the files case.energydn and case.energyup. But, as far as I >> understand, these results are before lapwso (i.e., without spinorbit >> interaction). In particular, for the valence band these numbers are >> completely useless. My expectation was that files "case.energysodn" >> and "case.energysoup" should have the energies of spinup and spindown >> states with spinorbit. However, these files are equivalent (only some >> mysterious numbers in first two lines are slightly different). >> Am I doing something wrong or some additional steps needed to extract >> energies with spin-orbit interaction? >> Thank you in advance. >> [1] >> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13399.html >> Sincerely yours, >> Mikhail Nestoklon >> >> ___ >> 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.at WIEN2k: http://www.wien2k.at >WWW: http://www.imc.tuwien.ac.at/TC_Blaha >-- >___ >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] external magnetic field using orb with spin-orbit interaction
Dear wien2k community, I am trying to estimate the g-factors in bulk semiconducting material. From the mail list and user guide I learned that orb may be used for this purpose (as discussed in beginning of this thread [1] and in section 7.4 of UG). Using the GaAs as a reference semiconductor I do the following steps (case.inorb and case.indmc files are more or less the same as in [1]): $ init_lapw -b -vxc 13 -sp $ runsp_c_lapw $ init_so_lapw $ runsp_lapw -so -orb In the end of this procedure I indeed see some splitting of spinup and spindown states in conduction band which corresponds to g-factor about 2 in the files case.energydn and case.energyup. But, as far as I understand, these results are before lapwso (i.e., without spinorbit interaction). In particular, for the valence band these numbers are completely useless. My expectation was that files "case.energysodn" and "case.energysoup" should have the energies of spinup and spindown states with spinorbit. However, these files are equivalent (only some mysterious numbers in first two lines are slightly different). Am I doing something wrong or some additional steps needed to extract energies with spin-orbit interaction? Thank you in advance. [1] https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13399.html Sincerely yours, Mikhail Nestoklon ___ 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] lapw7 with spin-orbit
Dear wien2k community, I am trying to use lapw7 to plot a particular wave function for the case with spin-orbit switched on. In the manual it is mentioned that "It should be easy to run lapw7 in parallel mode, and/or to apply it to wave function data obtained by a spin-orbit interaction calculation. None of these options have been implemented so far." Does anyone has some recommendations how this can be done? I have tried to change the lapw7.def to use SO results (replaced case.vector with case.vectorso[_n] file), this kind of worked, but the result is not what I expected. The energy mentioned in case.output7 file corresponds to the band number in the file without spin-orbit interaction. And the wave function looks like the one for the band numbered accordingly to the output of lapw1, not lapwso. I am pretty sure that lapw7 uses the "so" file: when I forgot to remove RLOs, the result was totally incorrect. Of course, I will read the source code, but I don’t believe nobody tried to use lapw7 with SO before. Thank you in advance. Sincerely yours, Mikhail Nestoklon ___ 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] spin-orbit (PBE and mBJ) for perovskites
Thank you.
Recently I tried to check also PbSe and there I saw this problem. With RLOs
when I go above de=8 the total energy starts to increase and SO also behaves
strangely. I understood that there is a problem with RLO and tried to do the
calculations without RLO. From your answers I conclude that it was a bad
decision, RLO are needed, but «de» should be limited.
And what indicates that I need RLOs for the cases where it is not completely
straightforward? Should I try to check the figure like the Fig1 in Kuneš et al
[PRB, 64, 153102 (2001)], and if I see similar behavior, then I definitely need
RLO? Or just «6p elements beginning with Hg and actinides» as mentioned in
Singh and Nordstrom book?
Sincerely yours,
Mikhail Nestoklon
>Вторник, 10 декабря 2019, 10:46 +03:00 от Peter Blaha
>:
>
>Don't go above EMAX=10 for SO calculations with RLOs.
>
>On 12/9/19 9:32 PM, Mikhail Nestoklon wrote:
>> Dear Prof. Blaha,
>> Thank you for clarification. I think, now I more or less understand what
>> is happening.
>> It seems, this issue is very easy to miss. Do you have any practical
>> recommendation how to spot this kind of problem in the calculations of
>> non-trivial material with few atoms?
>> Sincerely yours,
>> Mikhail Nestoklon
>>
>> Понедельник, 9 декабря 2019, 19:02 +03:00 от Peter Blaha
>> < pbl...@theochem.tuwien.ac.at >:
>> Hi,
>>
>> Fist of all: The RLOs (p-1/2)-LOs were originally designed to improve
>> the SO splitting of semicore states. There it makes a big difference and
>> is essential to converge E-tot in a meaningful way.
>>
>> (By meaningful I do not mean the absolute number as you tested it, but
>> an E-tot difference of 2 calculations at eg. 2 volumes).
>>
>> This can be best seen if you compare these semicore eigenvalues with the
>> eigenvalues of case.outputst, where the fully-relativistic splitting can
>> be found and compared.
>>
>> You can also add it in a case like Pb (usually, Pb does not have
>> semicore p-states), but the effect MUST be small.
>>
>> Most importantly, you MUST NOT have a too large E-max, because when the
>> spurious LO-eigenvalues of the APW+lo method enter in the spectrum at
>> high energy, you may get a problem as indicated below:
>>
>> I checked this for a free Pb-atom (in a big box).
>>
>> lapwso with Emax=10 gives:
>>
>> -1.5996189 -1.5996189 -1.5996189 -1.5996189 -1.4111046
>> -1.4111046 -1.4111046 -1.4111046 -1.4110328 -1.4110328
>> -0.8489490 -0.8489490 -0.3028265 -0.3028265 -0.2040009
>> -0.2040009 -0.2040009 -0.2040009 -0.0106114 -0.0106114
>>
>> while with EMAX=15 I get 6 spurious ghostbands ("bad Pb-5p states):
>> -8.2276000 -8.2276000 -3.1336676 -3.1336676 -3.1336591
>> -3.1336591 -1.6001880 -1.6001880 -1.6001880 -1.6001880
>> -1.4113465 -1.4113465 -1.4113464 -1.4113464 -1.4112735
>> -1.4112735 -0.8489490 -0.8489490 -0.2886641 -0.2886641
>> -0.2000960 -0.2000960 -0.2000960 -0.2000960 -0.0106114
>>
>> The SO-splitting of 6p states in the Pb atom is 0.109 Ry, while the
>> "good" lapwso calculations yield 0.099, but the "bad ones only 0.088
>> Without the RLO the SO splitting is 0.092, so still better than the
>> "bad" calculation.
>>
>> Eventually one can avoid this switching back to LAPW for the Pb-p
>> states.
>>
>> Peter Blaha
>>
>> On 12/9/19 3:30 PM, Mikhail Nestoklon wrote:
>> > Dear Dr. Tran,
>> > Thank you for the suggestion. Indeed, for CsPbCl3 I get very similar
>> > values (0.70 for PBE-SO and 1.67eV for TB-mBJ) and if I add RLO on Pb
>> > for CsPbI3 at least for PBE-SO I have something close to value
>> given in
>> > Jishi.
>> > However, now I have a general question. How to understand that I
>> need to
>> > add RLO in this situation? Should I just try to add RLO on heavy
>> atoms
>> > and if the result changes prefer the values given by +RLO
>> calculations?
>> > Or I had to suspect that I need to add RLO when realized that the
>> result
>> > does not converge until de>15?
>> > Sincerely yours,
>> > Mikhail Nestoklon
>> >
>> > Пятница, 6 декабря 2019, 0:39 +03:00 от "Tran, Fabien"
>> > < fabien.t...@tuwien.ac.at
>> >:
>> >
>> > Hi,
>> >
>> > Some time ago I did calculations on CsPbCl3 and I could reproduce
>> > Jishi's results reasonably well except the one in the 1st
>> > column("GGA&quo
Re: [Wien] spin-orbit (PBE and mBJ) for perovskites
Dear Prof. Blaha,
Thank you for clarification. I think, now I more or less understand what is
happening.
It seems, this issue is very easy to miss. Do you have any practical
recommendation how to spot this kind of problem in the calculations of
non-trivial material with few atoms?
Sincerely yours,
Mikhail Nestoklon
>Понедельник, 9 декабря 2019, 19:02 +03:00 от Peter Blaha
>:
>
>Hi,
>
>Fist of all: The RLOs (p-1/2)-LOs were originally designed to improve
>the SO splitting of semicore states. There it makes a big difference and
>is essential to converge E-tot in a meaningful way.
>
>(By meaningful I do not mean the absolute number as you tested it, but
>an E-tot difference of 2 calculations at eg. 2 volumes).
>
>This can be best seen if you compare these semicore eigenvalues with the
>eigenvalues of case.outputst, where the fully-relativistic splitting can
>be found and compared.
>
>You can also add it in a case like Pb (usually, Pb does not have
>semicore p-states), but the effect MUST be small.
>
>Most importantly, you MUST NOT have a too large E-max, because when the
>spurious LO-eigenvalues of the APW+lo method enter in the spectrum at
>high energy, you may get a problem as indicated below:
>
>I checked this for a free Pb-atom (in a big box).
>
>lapwso with Emax=10 gives:
>
> -1.5996189 -1.5996189 -1.5996189 -1.5996189 -1.4111046
> -1.4111046 -1.4111046 -1.4111046 -1.4110328 -1.4110328
> -0.8489490 -0.8489490 -0.3028265 -0.3028265 -0.2040009
> -0.2040009 -0.2040009 -0.2040009 -0.0106114 -0.0106114
>
>while with EMAX=15 I get 6 spurious ghostbands ("bad Pb-5p states):
> -8.2276000 -8.2276000 -3.1336676 -3.1336676 -3.1336591
> -3.1336591 -1.6001880 -1.6001880 -1.6001880 -1.6001880
> -1.4113465 -1.4113465 -1.4113464 -1.4113464 -1.4112735
> -1.4112735 -0.8489490 -0.8489490 -0.2886641 -0.2886641
> -0.2000960 -0.2000960 -0.2000960 -0.2000960 -0.0106114
>
>The SO-splitting of 6p states in the Pb atom is 0.109 Ry, while the
>"good" lapwso calculations yield 0.099, but the "bad ones only 0.088
>Without the RLO the SO splitting is 0.092, so still better than the
>"bad" calculation.
>
>Eventually one can avoid this switching back to LAPW for the Pb-p states.
>
>Peter Blaha
>
>On 12/9/19 3:30 PM, Mikhail Nestoklon wrote:
>> Dear Dr. Tran,
>> Thank you for the suggestion. Indeed, for CsPbCl3 I get very similar
>> values (0.70 for PBE-SO and 1.67eV for TB-mBJ) and if I add RLO on Pb
>> for CsPbI3 at least for PBE-SO I have something close to value given in
>> Jishi.
>> However, now I have a general question. How to understand that I need to
>> add RLO in this situation? Should I just try to add RLO on heavy atoms
>> and if the result changes prefer the values given by +RLO calculations?
>> Or I had to suspect that I need to add RLO when realized that the result
>> does not converge until de>15?
>> Sincerely yours,
>> Mikhail Nestoklon
>>
>> Пятница, 6 декабря 2019, 0:39 +03:00 от "Tran, Fabien"
>> < fabien.t...@tuwien.ac.at >:
>>
>> Hi,
>>
>> Some time ago I did calculations on CsPbCl3 and I could reproduce
>> Jishi's results reasonably well except the one in the 1st
>> column("GGA") which is probably wrong. I got 0.70 eV (0.71 eV from
>> Jishi) for "GGA+SOC", 1.68 eV (1.59 eV from Jishi) for TB-mBJ and
>> 2.86 eV (2.83 eV from Jishi) for "present". The only special
>> requirement that was needed is a p1/2 LO on Pb. I used RKMAX=9 and
>> de=10 in case.in1. The bug reported here
>>
>> http://zeus.theochem.tuwien.ac.at/pipermail/wien/2019-November/029882.html
>>
>> is active but has very small effect of 0.01 eV for GGA+SOC. Try
>> CsPbCl3 instead (struct and inso are attached).
>>
>> FT
>>
>>
>> *From:* Wien < wien-boun...@zeus.theochem.tuwien.ac.at > on behalf of
>> Mikhail Nestoklon < nestok...@mail.ru >
>> *Sent:* Thursday, December 5, 2019 8:21 PM
>> *To:* A Mailing list for WIEN2k users
>> *Subject:* [Wien] spin-orbit (PBE and mBJ) for perovskites
>> Dear wien2k community,
>> I plan to do some DFT calculation of inorganic perovskites using
>> WIEN2k (19.1 with some patches except the last one for RLO).
>> I’ve started from attempt to reproduce the values from Jishi et al.,
>> JPCC 118, 28344 (2014), but can not get the numbers given in Table 2
>> even for cubic CsPbI_3. The difference seem to stem from the spin-orbit.
>> What I di
Re: [Wien] spin-orbit (PBE and mBJ) for perovskites
Dear Dr. Tran,
Thank you for the suggestion. Indeed, for CsPbCl3 I get very similar values
(0.70 for PBE-SO and 1.67eV for TB-mBJ) and if I add RLO on Pb for CsPbI3 at
least for PBE-SO I have something close to value given in Jishi.
However, now I have a general question. How to understand that I need to add
RLO in this situation? Should I just try to add RLO on heavy atoms and if the
result changes prefer the values given by +RLO calculations? Or I had to
suspect that I need to add RLO when realized that the result does not converge
until de>15?
Sincerely yours,
Mikhail Nestoklon
>Пятница, 6 декабря 2019, 0:39 +03:00 от "Tran, Fabien" <
>fabien.t...@tuwien.ac.at >:
>
>Hi,
>
>Some time ago I did calculations on CsPbCl3 and I could reproduce Jishi's
>results reasonably well except the one in the 1st column("GGA") which is
>probably wrong. I got 0.70 eV (0.71 eV from Jishi) for "GGA+SOC", 1.68 eV
>(1.59 eV from Jishi) for TB-mBJ and 2.86 eV (2.83 eV from Jishi) for
>"present". The only special requirement that was needed is a p1/2 LO on Pb. I
>used RKMAX=9 and de=10 in case.in1. The bug reported here
>http://zeus.theochem.tuwien.ac.at/pipermail/wien/2019-November/029882.html
>is active but has very small effect of 0.01 eV for GGA+SOC. Try CsPbCl3
>instead (struct and inso are attached).
>
>FT
>
>----------
>From: Wien < wien-boun...@zeus.theochem.tuwien.ac.at > on behalf of Mikhail
>Nestoklon < nestok...@mail.ru >
>Sent: Thursday, December 5, 2019 8:21 PM
>To: A Mailing list for WIEN2k users
>Subject: [Wien] spin-orbit (PBE and mBJ) for perovskites
>
>Dear wien2k community,
>I plan to do some DFT calculation of inorganic perovskites using WIEN2k (19.1
>with some patches except the last one for RLO).
>I’ve started from attempt to reproduce the values from Jishi et al., JPCC 118,
>28344 (2014), but can not get the numbers given in Table 2 even for cubic
>CsPbI_3. The difference seem to stem from the spin-orbit.
>
>What I did:
>Using the file in attachment (I use the lattice constant given in table 1 and
>R_MT indicated in the text) I do
>$ init_lapw -b -vxc 13 -rkmax 9.0 -lvns 6 -fftfac 4 && x kgen (14x14x14) &&
>run_lapw -ec 0.1 -cc 0.0001
>I use -lvns 6, the difference with the result using standard value is small,
>in Jishi et al. it is mentioned that l_{max}=10 which is default, assuming
>they might have meant lvns I tried lvns=10, the difference with lvns=6 is
>close to zero. I also tried to put Pb p3/2 orbitals to core (if I put P1/2 to
>valence the result is strange, but this is a separate question) and see no
>difference.
>For k-mesh I check the convergence and see that for 14x14x14 the total energy
>convergence is below 1mRy and GAP is below 1 meV which is fine, so I am using
>this k mesh.
>Then I check the RKMAX convergence. For Rmt*Kmax =9 without spin-orbit I get
>the same number as in Table 2, but I see that this number is not fully
>converged: if I increase RKMAX further the total energy decreases for 8mRy and
>gap increases for almost 6 meV. I find it acceptable to use RKMAX=12: only
>then it is <1mRy and ~1meV for total energy and gap respectively. The gap with
>these numbers is 1.329meV which is 5 meV different from Table 2, this
>difference is probably acceptable.
>
>However, when I switch on the spin-orbit, the difference is huge. With the
>default values (I only increase llmax, however it does not change much) I get
>GAP about 0.269meV, which is almost 4 times different from the value given in
>Jishi et al. Table 2. As the SO value depends on de (in case.in1), I increase
>this parameter and check the value of GAP and also spin-orbit splitting of
>conduction and valence band (difference between energies of Gamma_8 and
>Gamma_7 in R point). GAP and spin-orbit in conduction band fully (below 1meV)
>converge only when de=15. Still, the band gap is 0.259eV which is too far from
>value given in Jishi et al.
>The RLO (I tried to add it on Cs, as for Pb it should be useless [1]) does not
>help
>
>With the same parameters I do the mBJ run (TB-mBJ). As expected, the gap
>increases, but up to 0.722 eV which is two times different from the value
>given in Jishi et al.
>I did not try to change R_MT: I use the value given in their paper.
>
>The fact that I do reproduce the number given for PBE without spin-orbit
>indicates that I hardly did any mistake in the structure. However, the
>difference in the numbers with spin-orbit is too large to be explained by
>unconverged results, both on my and their side. Could you help me to
>understand, how can I reproduce their results?
>
[Wien] spin-orbit (PBE and mBJ) for perovskites
Dear wien2k community,
I plan to do some DFT calculation of inorganic perovskites using WIEN2k (19.1
with some patches except the last one for RLO).
I’ve started from attempt to reproduce the values from Jishi et al., JPCC 118,
28344 (2014), but can not get the numbers given in Table 2 even for cubic
CsPbI_3. The difference seem to stem from the spin-orbit.
What I did:
Using the file in attachment (I use the lattice constant given in table 1 and
R_MT indicated in the text) I do
$ init_lapw -b -vxc 13 -rkmax 9.0 -lvns 6 -fftfac 4 && x kgen (14x14x14) &&
run_lapw -ec 0.1 -cc 0.0001
I use -lvns 6, the difference with the result using standard value is small, in
Jishi et al. it is mentioned that l_{max}=10 which is default, assuming they
might have meant lvns I tried lvns=10, the difference with lvns=6 is close to
zero. I also tried to put Pb p3/2 orbitals to core (if I put P1/2 to valence
the result is strange, but this is a separate question) and see no difference.
For k-mesh I check the convergence and see that for 14x14x14 the total energy
convergence is below 1mRy and GAP is below 1 meV which is fine, so I am using
this k mesh.
Then I check the RKMAX convergence. For Rmt*Kmax =9 without spin-orbit I get
the same number as in Table 2, but I see that this number is not fully
converged: if I increase RKMAX further the total energy decreases for 8mRy and
gap increases for almost 6 meV. I find it acceptable to use RKMAX=12: only then
it is <1mRy and ~1meV for total energy and gap respectively. The gap with these
numbers is 1.329meV which is 5 meV different from Table 2, this difference is
probably acceptable.
However, when I switch on the spin-orbit, the difference is huge. With the
default values (I only increase llmax, however it does not change much) I get
GAP about 0.269meV, which is almost 4 times different from the value given in
Jishi et al. Table 2. As the SO value depends on de (in case.in1), I increase
this parameter and check the value of GAP and also spin-orbit splitting of
conduction and valence band (difference between energies of Gamma_8 and Gamma_7
in R point). GAP and spin-orbit in conduction band fully (below 1meV) converge
only when de=15. Still, the band gap is 0.259eV which is too far from value
given in Jishi et al.
The RLO (I tried to add it on Cs, as for Pb it should be useless [1]) does not
help
With the same parameters I do the mBJ run (TB-mBJ). As expected, the gap
increases, but up to 0.722 eV which is two times different from the value given
in Jishi et al.
I did not try to change R_MT: I use the value given in their paper.
The fact that I do reproduce the number given for PBE without spin-orbit
indicates that I hardly did any mistake in the structure. However, the
difference in the numbers with spin-orbit is too large to be explained by
unconverged results, both on my and their side. Could you help me to
understand, how can I reproduce their results?
Thank you in advance.
Sincerely yours,
Mikhail Nestoklon
[1] https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17828.html
CsPbI3.struct
Description: Binary data
___
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] gfortran compilation and run problems for 19.1
Dear Prof Blaha, Thank you for the solution. Now standard calculations (with spinorbit also) work. k-Parallel version also work, until I try hybrid potentials. When I run k-parallel calculations with hybrid potentials (spin-orbit included, reduced k-mesh), the code stops after HF on a first iteration with an error "STOP error with energyhf_rbz files". What can be the source of this error? Note that on one machine hybrid potentials work without problems. Sincerely yours, Mikhail Nestoklon >Среда, 26 июня 2019, 11:16 +03:00 от Peter Blaha >: > >I can confirm the lapw2 problem with gfortran. > >According to the Fortran standard, you can specify status=scratch, but >then you MUST NOT specify a "FILE=...". (ifort can handle this easily). > >You can edit x_lapw and remove the line with unit 15 in the lapw2: >section (search for lapw2:, then go down until you find > > 15,'GaAs.tmp', 'scratch','unformatted',0 > >and delete it. > >(I will later on put an open of unit 15 in the rare cases we need it). > > >On 6/26/19 12:52 AM, Mikhail Nestoklon wrote: >> Thank you. >> LAPW1 seem to work with default 4 threads. >> Now run_lapw stops at the next step: >> >> STOP LAPW0 END >> STOP LAPW1 END >> STOP LAPW2 - Error. Check file lapw2.error >> >> $ cat lapw2.error >> 'LAPW2' - can't open unit: 15 >> 'LAPW2' - filename: GaAs.tmp >> 'LAPW2' - status: scratch form: unformatted >> >> In the update information it is mentioned that case.tmp is removed now. >> However, >> >> $ cat lapw2.def >> ... >> 15,'GaAs.tmp', 'scratch','unformatted',0 >> ... >> >> >> Sincerely >> Mikhail >> >> >> >> >> >> Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha >> < pbl...@theochem.tuwien.ac.at >: >> >> Hi, >> >> I can confirm the fix for inputpars.F. Of course, according to >> fortran standards a logical if should have an .eqv. operator >> (although I >> never "understood" what that should be good for ...). >> >> Also your second problem I have most likely recently seen myself. I >> guess it happens only with OMP_NUM_THREAD > 1 (and goes away if you >> explicitly set OMP_NUM_THREAD to 1). >> >> Together with Pavel Ondracka we have found a fix for the problem. It >> happens only with OMP_NUM_THREAD >1 (more than one core) and only in >> cases where the matrix size is that small as compared to the blocksize >> (128), that the iouter-loop in hamilt.F is executed not by all >> requested >> cores, but only one (or a few) and the free core jumps immediately to >> the "omp single" section (which was introduced to avoid idling of the >> "last" core). >> >> I attach a patched hamilt.F for WIEN2k_19 / release 12.6.19 >> >> A patched WIEN2k_19 /release 25.6.19. will be on the web shortly. >> >> Best regards >> >> On 6/24/19 11:45 PM, Mikhail Nestoklon wrote: >> > Dear wien2k community, >> > I am trying to run the new version of the code on a fresh install of >> > Ubuntu 18.04.2 LTS. >> > It is serial (with OMP) compilation with no libxc, fftw, >> scalapack, elpa. >> > Since WIEN2k_16 it was more or less Ok to compile the code with >> gfortran, >> > but with new version there are problems again. >> > >> > First, the new 19.1 version does not compile with gfortran >> (7.4.0) with >> > the error during lapw0 compilation >> > > inputpars.F:664:8: >> > > if(read_vhalf .eq. .true.) then >> > > 1 >> > > Error: Logicals at (1) must be compared with .eqv. instead of .eq. >> > If I fix the file in accordance with gfortran rules, it compiles. >> > According to gcc, this is the ifort extension not working on "more >> > standard" implementations. >> > >> > Second, when the code is compiled, running simple (GaAs) example >> which >> > works perfectly >> > at least in WIEN2k 16, 17, 18 gives the error >> > $ init_lapw -b >> > $ run_lapw >> > STOP LAPW0 END >> > STOP SECLR4 - Error >> > >> > What possibly may go wrong here? I have no idea how to debug this >> problem. >> > >> > Sincerely yours, >> > Mi
Re: [Wien] gfortran compilation and run problems for 19.1
No, it understands the intention of the person who wrote the code but this is
an error.
@ gfortran 7.4.0
if(a == b) then
1
Error: Logicals at (1) must be compared with .eqv. instead of ==
gfort_test.f:15:9:
if(a .eq. b) then
1
Error: Logicals at (1) must be compared with .eqv. instead of .eq.
As far as I remember,some time ago to make the fortran code which compiles with
ifort compile with gfortran the good starting point was to switch on all flags
which control the strict use of the standard, unfortunately I have no access to
ifort right now and can not check the proper combination, probably it was just
"-std90".
By default, ifort compiles the non-standard code it is able to understand while
the default gfortran behavior is to treat it as an error. This particular case
is far beyond the standard, so I do not know if it is even possible to force
gfortran to compile this code.
Sincerely,
Mikhail
>Среда, 26 июня 2019, 8:43 +03:00 от "Fecher, Gerhard" :
>
>Dear Gavin,
>Sorry my question was probably to short, it should read
> Does anyone know whether "== " works with gfortran ?
>
>With ifort the following test works well, but I cannot test it with gfortran
>The answer in the Intel forum that you quote does not include "=="
>
> program logicaltest
> implicit none
>!
>! test ==, .eq., .eqv.
>!
> logical a, b, c
>
> a=.true.
> b=.true.
>
> if(a == b) then
> write(6,*) 'a = b'
> end if
>
> if(a .eq. b) then
> write(6,*) 'a .eq. b'
> end if
>
> if(a .eqv. b) then
> write(6,*) 'a .eqv. b'
> end if
>
> end
>
>
>Ciao
>Gerhard
>
>DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>"I think the problem, to be quite honest with you,
>is that you have never actually known what the question is."
>
>
>Dr. Gerhard H. Fecher
>Institut of Inorganic and Analytical Chemistry
>Johannes Gutenberg - University
>55099 Mainz
>and
>Max Planck Institute for Chemical Physics of Solids
>01187 Dresden
>
>Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Gavin Abo
>[gs...@crimson.ua.edu]
>Gesendet: Mittwoch, 26. Juni 2019 03:37
>An: wien@zeus.theochem.tuwien.ac.at
>Betreff: Re: [Wien] gfortran compilation and run problems for 19.1
>
>The == should work for C/C++ language. I don't recall ever seeing that being
>used for Fortran.
>
>A quote from a HP Doctor Fortran article [
>https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/274462
> ]:
>
>"The real trouble with making assumptions about the internal value of LOGICALs
>is when you try testing them for "equality" against another logical
>expression. The way many Fortran programmers would naturally do this is as
>follows:
>
>IF (LOGVAL1 .EQ. LOGVAL2) ...
>
>but the results of this can vary depending on the internal representation. The
>Fortran language defines two operators exclusively for use on logical values,
>.EQV. ("equivalent to") and .NEQV. ("not equivalent to"). So the above test
>would be properly written as:
>
>IF (LOGVAL1 .EQV. LOGVAL2) ..."
>
>On 6/25/2019 3:14 PM, Fecher, Gerhard wrote:
>
>Does == work ?
>
>Ciao
>Gerhard
>
>DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>"I think the problem, to be quite honest with you,
>is that you have never actually known what the question is."
>
>
>Dr. Gerhard H. Fecher
>Institut of Inorganic and Analytical Chemistry
>Johannes Gutenberg - University
>55099 Mainz
>and
>Max Planck Institute for Chemical Physics of Solids
>01187 Dresden
>
>Von: Wien
>[wien-boun...@zeus.theochem.tuwien.ac.at<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>]
> im Auftrag von Sam Trickey [tric...@qtp.ufl.edu<mailto:tric...@qtp.ufl.edu>]
>Gesendet: Dienstag, 25. Juni 2019 15:13
>An: wien@zeus.theochem.tuwien.ac.at
>Betreff: Re: [Wien] gfortran compilation and run problems for 19.1
>
>See below
>
>On 6/25/19 5:47 AM, Peter Blaha wrote:
>Hi,
>
>I can confirm the fix for inputpars.F. Of course, according to fortran
>standards a logical if should have an .eqv. operator (although I never
>"understood" what that should be good for ...).
>
>Keeps computer scientists occupied introducing needless and annoying
>distinctions.
>
>peace, Sam
>
>
>--
>Samuel B. Trickey
>QTP, Depts. of Physics and Chemistry
>2324 Physics Building
&
Re: [Wien] gfortran compilation and run problems for 19.1
Thank you. LAPW1 seem to work with default 4 threads. Now run_lapw stops at the next step: STOP LAPW0 END STOP LAPW1 END STOP LAPW2 - Error. Check file lapw2.error $ cat lapw2.error 'LAPW2' - can't open unit: 15 'LAPW2' - filename: GaAs.tmp 'LAPW2' - status: scratch form: unformatted In the update information it is mentioned that case.tmp is removed now. However, $ cat lapw2.def ... 15,'GaAs.tmp', 'scratch','unformatted',0 ... Sincerely Mikhail >Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha >: > >Hi, > >I can confirm the fix for inputpars.F. Of course, according to >fortran standards a logical if should have an .eqv. operator (although I >never "understood" what that should be good for ...). > >Also your second problem I have most likely recently seen myself. I >guess it happens only with OMP_NUM_THREAD > 1 (and goes away if you >explicitly set OMP_NUM_THREAD to 1). > >Together with Pavel Ondracka we have found a fix for the problem. It >happens only with OMP_NUM_THREAD >1 (more than one core) and only in >cases where the matrix size is that small as compared to the blocksize >(128), that the iouter-loop in hamilt.F is executed not by all requested >cores, but only one (or a few) and the free core jumps immediately to >the "omp single" section (which was introduced to avoid idling of the >"last" core). > >I attach a patched hamilt.F for WIEN2k_19 / release 12.6.19 > >A patched WIEN2k_19 /release 25.6.19. will be on the web shortly. > >Best regards > >On 6/24/19 11:45 PM, Mikhail Nestoklon wrote: >> Dear wien2k community, >> I am trying to run the new version of the code on a fresh install of >> Ubuntu 18.04.2 LTS. >> It is serial (with OMP) compilation with no libxc, fftw, scalapack, elpa. >> Since WIEN2k_16 it was more or less Ok to compile the code with gfortran, >> but with new version there are problems again. >> >> First, the new 19.1 version does not compile with gfortran (7.4.0) with >> the error during lapw0 compilation >> > inputpars.F:664:8: >> > if(read_vhalf .eq. .true.) then >> > 1 >> > Error: Logicals at (1) must be compared with .eqv. instead of .eq. >> If I fix the file in accordance with gfortran rules, it compiles. >> According to gcc, this is the ifort extension not working on "more >> standard" implementations. >> >> Second, when the code is compiled, running simple (GaAs) example which >> works perfectly >> at least in WIEN2k 16, 17, 18 gives the error >> $ init_lapw -b >> $ run_lapw >> STOP LAPW0 END >> STOP SECLR4 - Error >> >> What possibly may go wrong here? I have no idea how to debug this problem. >> >> Sincerely yours, >> Mikhail Nestoklon >> >> ___ >> 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.at WIEN2k: http://www.wien2k.at >WWW: http://www.imc.tuwien.ac.at/TC_Blaha >-- >___ >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 -- Mikhail Nestoklon ___ 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] gfortran compilation and run problems for 19.1
Dear wien2k community, I am trying to run the new version of the code on a fresh install of Ubuntu 18.04.2 LTS. It is serial (with OMP) compilation with no libxc, fftw, scalapack, elpa. Since WIEN2k_16 it was more or less Ok to compile the code with gfortran, but with new version there are problems again. First, the new 19.1 version does not compile with gfortran (7.4.0) with the error during lapw0 compilation > inputpars.F:664:8: > if(read_vhalf .eq. .true.) then > 1 > Error: Logicals at (1) must be compared with .eqv. instead of .eq. If I fix the file in accordance with gfortran rules, it compiles. According to gcc, this is the ifort extension not working on "more standard" implementations. Second, when the code is compiled, running simple (GaAs) example which works perfectly at least in WIEN2k 16, 17, 18 gives the error $ init_lapw -b $ run_lapw STOP LAPW0 END STOP SECLR4 - Error What possibly may go wrong here? I have no idea how to debug this problem. Sincerely yours, Mikhail Nestoklon___ 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] inversion and spin-orbit
Dear wien2k community, I do not fully understand the way kgen (and code in general) treats the structures without inversion. For standard GaAs structure, spacegroup #216, without inversion, when I do calculations WITH spin-orbit, the kgen $ x kgen -so still informs that """ GaAs.ksym not present, using GaAs.struct because inversion is present 24 symmetry operations without inversion inversion added (non-spinpolarized non-so calculation) """ In fact, there is no inversion center in the system (and code is aware of that) and there is spin-orbit, so the states k and -k are not the same (Indeed, they are still connected by the time inversion, but technically it is different from spacial inversion). The manual is a bit cryptic about this part: It tells that the symmetry is lowered only if the magnetic field is switched on, in which case one should use symmetso. Does this mean that "under the hood" the code behaves correctly and in fact uses time inversion and not spacial inversion or I should trick it into removing the inversion from the symmetry if I do care about correct description of properties which come from the lack of inversion center? Thank you in advance. Sincerely, Mikhail Nestoklon ___ 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] Problems with hf and so
Thank you. With these changes everything works as expected, including the combination of "-newklist" and "-redklist". Sincerely yours, Mikhail Nestoklon. >Среда, 9 января 2019, 2:13 +03:00 от t...@theochem.tuwien.ac.at: > >Yes, one more bug. In calc_cnk.F, at line 156 replace > > weigh_redk(1:nboccmax,ikfr) = >weigh_redk_ibz(1:nboccmax,ikir)/dble(nkstarredkall(ikir)) >by > weigh_redk(1:maxval(nbocc_redk_ibz),ikfr) = >weigh_redk_ibz(1:maxval(nbocc_redk_ibz),ikir)/dble(nkstarredkall(ikir)) > >and at line 343 > > weigh_redk(1:nboccmax,ikfr) = >weigh_redk_ibz(1:nboccmax,ikir)/dble(nkstarredkall(ikir)) >by > weigh_redk(1:maxval(nbocc_redk_ibz),ikfr) = >weigh_redk_ibz(1:maxval(nbocc_redk_ibz),ikir)/dble(nkstarredkall(ikir)) > >and recompile. > >Concerning the previous bug with -newklist, you HAVE to fix it >as I mentioned, otherwise it may not work if -redklist is used >(maybe it was also a problem for the present case). > > >On Tuesday 2019-01-08 23:01, Mikhail Nestoklon wrote: > >>Date: Tue, 8 Jan 2019 23:01:03 >>From: Mikhail Nestoklon < nestok...@mail.ru > >>Reply-To: A Mailing list for WIEN2k users < wien@zeus.theochem.tuwien.ac.at > >>To: A Mailing list for WIEN2k users < wien@zeus.theochem.tuwien.ac.at > >>Subject: Re: [Wien] Problems with hf and so >> >>Thank you for your reply. >>The solution to the "-newklist" bug works (just to comment the line is also >>Ok). >> >>To better understand the "-redklist" bug, I recompiled the code with some >>debug flags on. The same GaAs example, >>$ init_lapw -b -vxc 19 >>$ run_lapw >>$ save_lapw -d PBE_min >>$ init_hf_lapw (choose 32 nband in GaAs.hf, 36 nband in GaAs.in1c, >>redklist with number of k for lapw1=6x6x6 number of k for hf =1x1x1 ) >>$ run_lapw -hf -redklist >>$ save_lapw -d HSE_min >>$ initso_lapw (everything default) >>$ run_lapw -hf -so -redklist >> >>gives >>" >> LAPW0 END >> LAPW0 END >> LAPW1 END >> LAPW2 END >> CORE END >>forrtl: severe (408): fort: (2): Subscript #1 of the array WEIGH_REDK_IBZ has >>value 15 which is greater than the upper bound of 14 >> >>Image PC Routine Line Source >> >>hfc 00C5C0A0 Unknown Unknown Unknown >>hfc 00562B85 calc_cnk_ 156 >>calc_cnk_tmp_.F >>hfc 00BA72F7 read_cnk_ 258 >>read_cnk_tmp_.F >>hfc 00B595C6 MAIN__ 26 hf.f >>" >> >> >>Sincerely yours, >>Mikhail Nestoklon >> >> >> >> Понедельник, 7 января 2019, 15:54 +03:00 от t...@theochem.tuwien.ac.at: >> >> Hi, >> >> Gavin is right, there is a bug. To fix the problem, you need >> at line 126 in read_weight.f to replace >> nk = nkibzall >> by >> if (newklist .eqv. .false.) then >> nk = nkibzall >> elseif (newklist .eqv. .true.) then >> nk = nkibzoldk >> endif >> >> Concerning the other problem with -redklist, try it again. If it still >> occurs, then give the details of your procedure. >> >> One unrelated thing: >> Use "save_lapw" when a calculation is finished to avoid to mix >> several different calculations in the same scf file. >> >> Thanks for having reported the problem. >> >> F. Tran >> >> On Sunday 2019-01-06 22:05, Mikhail Nestoklon wrote: >> >> >Date: Sun, 6 Jan 2019 22:05:12 >> >From: Mikhail Nestoklon < nestok...@mail.ru > >> >Reply-To: A Mailing list for WIEN2k users < >> wien@zeus.theochem.tuwien.ac.at > >> >To: A Mailing list for WIEN2k users < wien@zeus.theochem.tuwien.ac.at > >> >Subject: [Wien] Problems with hf and so >> > >> > >> >Dear wien2k community, >> >In the new version of WIEN2k the hybrid functionals are compatible >> with spin-orbit. >> >However, using such combination I can not continue calculations after >> I change the k-mesh. >> > >> >As a minimal non-working example, to compute the GaAs (the .struct is >> fine, the band structure with e.g. mBJ is perfect, for >> >c
Re: [Wien] Problems with hf and so
Thank you for your reply. The solution to the "-newklist" bug works (just to comment the line is also Ok). To better understand the "-redklist" bug, I recompiled the code with some debug flags on. The same GaAs example, $ init_lapw -b -vxc 19 $ run_lapw $ save_lapw -d PBE_min $ init_hf_lapw (choose 32 nband in GaAs.hf, 36 nband in GaAs.in1c, redklist with number of k for lapw1=6x6x6 number of k for hf =1x1x1 ) $ run_lapw -hf -redklist $ save_lapw -d HSE_min $ initso_lapw (everything default) $ run_lapw -hf -so -redklist gives " LAPW0 END LAPW0 END LAPW1 END LAPW2 END CORE END forrtl: severe (408): fort: (2): Subscript #1 of the array WEIGH_REDK_IBZ has value 15 which is greater than the upper bound of 14 Image PC Routine Line Source hfc 00C5C0A0 Unknown Unknown Unknown hfc 00562B85 calc_cnk_ 156 calc_cnk_tmp_.F hfc 00BA72F7 read_cnk_ 258 read_cnk_tmp_.F hfc 00B595C6 MAIN__ 26 hf.f " Sincerely yours, Mikhail Nestoklon >Понедельник, 7 января 2019, 15:54 +03:00 от t...@theochem.tuwien.ac.at: > >Hi, > >Gavin is right, there is a bug. To fix the problem, you need >at line 126 in read_weight.f to replace > nk = nkibzall >by > if (newklist .eqv. .false.) then > nk = nkibzall > elseif (newklist .eqv. .true.) then > nk = nkibzoldk > endif > >Concerning the other problem with -redklist, try it again. If it still >occurs, then give the details of your procedure. > >One unrelated thing: >Use "save_lapw" when a calculation is finished to avoid to mix >several different calculations in the same scf file. > >Thanks for having reported the problem. > >F. Tran > >On Sunday 2019-01-06 22:05, Mikhail Nestoklon wrote: > >>Date: Sun, 6 Jan 2019 22:05:12 >>From: Mikhail Nestoklon < nestok...@mail.ru > >>Reply-To: A Mailing list for WIEN2k users < wien@zeus.theochem.tuwien.ac.at > >>To: A Mailing list for WIEN2k users < wien@zeus.theochem.tuwien.ac.at > >>Subject: [Wien] Problems with hf and so >> >> >>Dear wien2k community, >>In the new version of WIEN2k the hybrid functionals are compatible with >>spin-orbit. >>However, using such combination I can not continue calculations after I >>change the k-mesh. >> >>As a minimal non-working example, to compute the GaAs (the .struct is fine, >>the band structure with e.g. mBJ is perfect, for >>completeness it is in attachment) I am trying to >>$ init_lapw -b -vxc 19 -rkmax 8 >>$ run_lapw >>$ init_hf_lapw (choose 32 nband in GaAs.hf, 36 nband in GaAs.in1c >>number of k =30 ) >>$ run_lapw -hf >>$ initso_lapw (everything default) >>$ run_lapw -hf -so >>This works, but if I then follow UG 4.5.8 and >>$ mv GaAs.klist_fbz GaAs.klist_fbz_old >>$ mv GaAs.klist_ibz GaAs.klist_ibz_old >>$ mv GaAs.outputkgenhf GaAs.outputkgenhf_old >>$ run_kgenhf_lapw (choose 300) >>$ run_lapw -hf -so -newklist >>The result is >> LAPW0 END >> LAPW0 END >> LAPW1 END >> LAPW2 END >> CORE END >>error in read_weight: wrong case.weighthfnoso >> >>Am I doing something wrong? The error message is strange and I can not >>understand how it is related with what I am doing. >> >>By the way, doing the same with reduced mesh, it gets worse: there is memory >>error on a first iteration with spin-orbit, >>something like (this one for ubuntu 16.04 / ifort 15.0.1+mkl / xeon E5420) >>*** Error in `.../WIEN2k_18/hfc': munmap_chunk(): invalid pointer: >>0x00d4cc90 *** >>The exact message may be different for different machines/compilers, but I >>could not find the working combination. . >> >>Thank you in advance. >> >>Sincerely, >>Mikhail Nestoklon >> >> >___ >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 -- Mikhail Nestoklon ___ 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] Problems with hf and so
Dear wien2k community, In the new version of WIEN2k the hybrid functionals are compatible with spin-orbit. However, using such combination I can not continue calculations after I change the k-mesh. As a minimal non-working example, to compute the GaAs (the .struct is fine, the band structure with e.g. mBJ is perfect, for completeness it is in attachment) I am trying to $ init_lapw -b -vxc 19 -rkmax 8 $ run_lapw $ init_hf_lapw (choose 32 nband in GaAs.hf, 36 nband in GaAs.in1c number of k =30 ) $ run_lapw -hf $ initso_lapw (everything default) $ run_lapw -hf -so This works, but if I then follow UG 4.5.8 and $ mv GaAs.klist_fbz GaAs.klist_fbz_old $ mv GaAs.klist_ibz GaAs.klist_ibz_old $ mv GaAs.outputkgenhf GaAs.outputkgenhf_old $ run_kgenhf_lapw (choose 300) $ run_lapw -hf -so -newklist The result is LAPW0 END LAPW0 END LAPW1 END LAPW2 END CORE END error in read_weight: wrong case.weighthfnoso Am I doing something wrong? The error message is strange and I can not understand how it is related with what I am doing. By the way, doing the same with reduced mesh, it gets worse: there is memory error on a first iteration with spin-orbit, something like (this one for ubuntu 16.04 / ifort 15.0.1+mkl / xeon E5420) *** Error in `.../WIEN2k_18/hfc': munmap_chunk(): invalid pointer: 0x00d4cc90 *** The exact message may be different for different machines/compilers, but I could not find the working combination. . Thank you in advance. Sincerely, Mikhail Nestoklon GaAs.struct Description: Binary data ___ 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] Reg: Parity determination using x irrep
In WIEN2k, the non-symmorphic spaceroups are not implemented. Normally, it is not a big problem. For instance, in Si (O_h^7 group) if you DO NOT neglect spin there is only one irreducible representation in X point and you have no problem at all (See Bir Pikus "Symmetry and strain-induced effects in semiconductors" § 23 pp216-218). If you want to neglect spin in Si or consider even more complex case, in most cases you most likely may extract information about symmetry in problem point by tracing the symmetry near this point (case of Si may be found in Bir Pikus book, p.222, 3rd block of equations). But WIEN2k is not able to do this automatically. >Dear all, > >I am trying to determine the parity of wavefunction at particular k points >(TRIM points), using x irrep. At Gamma point i could see the irreducible >representation successfully for each band, but for some point like (0.5, 0, 0) > i am facing problem, > instead of showing each band details it is written that ' WILL BE >IMPLEMENTED'. >Please help me in this regard. My system has inversion symmetry. >Thank you > >Sreeparvathy P. C >Research scholar >IIT Hyderabad >___ >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 -- Mikhail Nestoklon ___ 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
