Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
I did not add RLOs at all. For sure not for light elements like O and F. This option is in particular for semicore p states of heavy elements, but maybe for Bi-p it is ok. In any case, if case.inso, in1, in2, in0 are identical for mbj-lda and mbj-pbe, the results must be identical. Am 17.05.2024 um 22:24 schrieb Yakup Boran: Thank you for your valuable answer. Yes, Emax is the same for mbj_lda_so and mbj_pbe_so. I checked your results and I am doing something wrong with the SO calculation. I've shared below the operation file for SO calculation. I would appreciate it if you can tell me where I am doing wrong. The Best hsn@hsn-Veriton-X4630G:~/WIEN2k/yakup/BiOF/so/mbj/nsp-gga-mbj-0-2/nsp$ save_lapw -d uc hsn@hsn-Veriton-X4630G:~/WIEN2k/yakup/BiOF/so/mbj/nsp-gga-mbj-0-2/nsp$ init_so_lapw The file nsp.in2c has been generated automatically >Please select the direction of the moment ( h k l ) (For R-lattice in R coordinates)(default 0 0 1): atom 1 is Bi atom 2 is O atom 3 is F Select atom-numbers (1,2,3) or "ranges of atoms" (1-3,9-12) (without blanks) for which you would NOT like to add SO interaction (default none, just press "enter" ): For large spin orbit effects it might be necessary to include many more eigenstates from lapw1 by increasing EMAX in case.in1(c) - in case of MPI-parallel calculations with ELPA nband has to be increased instead. >Please enter EMAX(default 5.0 Ryd): The radial basis set for heavy atoms with p-semicore states is very limited. One can improve this by adding RLOs. Note: you MUST NOT add RLOs for atoms like oxygen, therefore the default is set to NONE >Add RLO for NONE, ALL, CHOOSE elements? (N/a/c) : c p-Energy parameters for Bi atom is : 1 0.30 0. CONT 1 Would you like to add RLO? (Y/n)Y p-Energy parameters for O atom is : 1 0.30 0. CONT 1 Would you like to add RLO? (Y/n)n p-Energy parameters for F atom is : 1 0.30 0. CONT 1 Would you like to add RLO? (Y/n)n Check the generated nsp.inso file (RLOs,...) Check the generated nsp.in1 file (Emax and nband (if ELPA is used) at the bottom of the file) In spinpolarized case SO may reduce symmetry. The program symmetso detects the proper symmetry and creates new struct and input files. (Note, equivalent atoms could become inequivalent in some cases). Do you have a spinpolarized case (and want to run symmetso) ? (y/N)N Spinorbit is now ready to run. hsn@hsn-Veriton-X4630G:~/WIEN2k/yakup/BiOF/so/mbj/nsp-gga-mbj-0-2/nsp$ run_lapw -i 200 -so -ec 0.1 -cc 0.1 -NI On Fri, May 17, 2024 at 9:29 PM Peter Blaha <mailto:peter.bl...@tuwien.ac.at>> wrote: Using your struct file I tested the gaps. The results are exactly as expected: psi11:/psi11/pblaha/test> grepline :gap '*scf' 1 in 6 files: lda.scf::GAP (global) : 0.243291 Ry = 3.310 eV (accurate value if proper k-mesh) pbe.scf::GAP (global) : 0.257682 Ry = 3.506 eV (accurate value if proper k-mesh) mbj_lda.scf::GAP (global) : 0.368924 Ry = 5.019 eV (accurate value if proper k-mesh) mbj_lda_so.scf::GAP (this spin): 0.336905 Ry = 4.584 eV (accurate value if proper k-mesh) mbj_pbe.scf::GAP (global) : 0.368926 Ry = 5.020 eV (accurate value if proper k-mesh) mbj_pbe_so.scf::GAP (this spin): 0.336901 Ry = 4.584 eV (accurate value if proper k-mesh) The lda gap is smallest, PBE a bit larger, and both mbj after lda or mbj after pbe give the same large gap. Including SO yields of course also identical gaps, which are by about 0.5 eV reduced. PS These calculations are just ewith -prec 1 PPS: make a diff of your in1 files of mbj_lda_so and mbj_pbe_so. Is Emax the same ? Am 17.05.2024 um 14:14 schrieb Yakup Boran: > Dear Dr. Blaha, > > First of all, thank you for your time. > > DIS of all calculations are below. > > I checked the calculations again and everything seems correct to me (of > course, there might be something I am missing). > > I also share the struct file below for more detailed information. I > would appreciate it if you could take a look at it when you have a chance. > -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.at <mailto:peter.bl...@tuwien.ac.at> WIEN2k: http://www.wien2k.at <http://www.wien2k.at> WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at> ----- -- ---
Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
Using your struct file I tested the gaps. The results are exactly as expected: psi11:/psi11/pblaha/test> grepline :gap '*scf' 1 in 6 files: lda.scf::GAP (global) : 0.243291 Ry = 3.310 eV (accurate value if proper k-mesh) pbe.scf::GAP (global) : 0.257682 Ry = 3.506 eV (accurate value if proper k-mesh) mbj_lda.scf::GAP (global) : 0.368924 Ry = 5.019 eV (accurate value if proper k-mesh) mbj_lda_so.scf::GAP (this spin): 0.336905 Ry = 4.584 eV (accurate value if proper k-mesh) mbj_pbe.scf::GAP (global) : 0.368926 Ry = 5.020 eV (accurate value if proper k-mesh) mbj_pbe_so.scf::GAP (this spin): 0.336901 Ry = 4.584 eV (accurate value if proper k-mesh) The lda gap is smallest, PBE a bit larger, and both mbj after lda or mbj after pbe give the same large gap. Including SO yields of course also identical gaps, which are by about 0.5 eV reduced. PS These calculations are just ewith -prec 1 PPS: make a diff of your in1 files of mbj_lda_so and mbj_pbe_so. Is Emax the same ? Am 17.05.2024 um 14:14 schrieb Yakup Boran: Dear Dr. Blaha, First of all, thank you for your time. DIS of all calculations are below. I checked the calculations again and everything seems correct to me (of course, there might be something I am missing). I also share the struct file below for more detailed information. I would appreciate it if you could take a look at it when you have a chance. -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] mixer error in lmbj calculations
You did probably previously a minimization (-min) with PBE, which did not converge or you stopped it manually. In any case, you still have in case.inm a line with: MSR1a Edit this file and change to MSR1. PS: restore the pbe structure. You made a relaxation with completely wrong forces). Am 17.05.2024 um 11:12 schrieb Nestoklon Mikhail: Dear wien2k community, I faced a strange problem in lmbj calculations with WIEN2k 23.2. For an intermediate size system (57 atoms, CsPbBr slab with organic ligands and some vacuum): 1) I did structure relaxation with PBE, 2) "restored" result into another directory, 3) made a few iterations to have all files in place, initialized lmbj and run it. After about 60 iterations when the system seem to started approaching convergence the iterations failed with the message > CORE END >Mixer - Error. no feasible step small enough, check RMT and model >> stop error Which seems strange as I expected this message occurs only in the minimization procedure. I tried to remove *.broyd* files and rerun the iterations, but now the error is > changing TOT to FOR in CsPbBr3_3ML_PEA_BS.in2c > while: Badly formed number. >> stop error I have two questions: 1) Why did the error in the mixer occur and how could it had been prevented? 2) How can I continue calculations now from where it stopped? 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
Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
As I said before: The first question is: why is LDA+mBJ and PBE#mBJ not identical ?? What is :DIS of all your calculations ? My guess is that they are not converged (just 40 default iterations, just default convergence ?) We do not know enough about your compound (except that it contains Bi), but this does not happen in 99.9 % of all cases. The behavior with SO is a second step, but unless the first one is solved, I would not even discuss the SO behavior. Also your comment about EMAX=6 (which is a very small increase for a convergence test) indicates to me, that the previous calculations have not been converged. Am 16.05.2024 um 21:59 schrieb Yakup Boran: Dear Dr. Blaha, 1. Case: I get 4.85 eV for LDA and then MBJ without SO (4.77 eV with SO) 2. Case: I get 4.74 eV for PBE and then MBJ without SO (4.79 eV with SO) In the 1. case band gap decreases with SO, but in the 2. case band gap increases. I use Emax=5 eV for both calculations. As far as I know, for SO calculation Emax should be chosen carefully. I did another calculation with Emax = 6eV. This time, in both cases, the band gap increases with SO. In literature, band gap decrease is expected with SO, but I get band gap increase in my calculations. My question is if there is something else should I check. Or how one can explain the band gap increase? Best regards. On Sat, May 11, 2024 at 7:14 PM Peter Blaha <mailto:peter.bl...@tuwien.ac.at>> wrote: __ Do you get identical gaps for: LDA and then MBJ (no SO) PBE and then MBJ (no SO) ??? If you did everything right, there is no reason why adding SO at the end should give a different result. Probably some other mistake ... ? Am 11.05.2024 um 17:32 schrieb Yakup Boran: Dear Dr Blaha, I think I did not write clear enough. The calculation was done by following: 1. I did regular scf calculation with LDA 2. I added mBJ on it. 3. Then I added SOC. I repeated the same calculation with PBE. Thank you 11 May 2024 Cmt, saat 17:08 tarihinde Peter Blaha mailto:peter.bl...@tuwien.ac.at>> şunu yazdı: No. These 2 calculations should be exactly the same. What matters is only: XC_MBJ Everything in parenthesis is only a comment to give you a few common options. Am 11.05.2024 um 16:00 schrieb Yakup Boran: Dear Dr Blaha, Thank you for your response. ——— case.in0 for LDA is TOT XC_MBJ ( (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ——- Case.in0 for PBE TOT XC_MBJ ( (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ———- Best regards 11 May 2024 Cmt, saat 16:03 tarihinde Peter Blaha mailto:peter.bl...@tuwien.ac.at>> şunu yazdı: I'm not quite sure I understand what you did. You are always using mBJ (for VX), but how do you mix in LDA or PBE ? By default we use LDA for VC, (and anything for EX and EC, since this is not important). Usually, the choice of VC has only a small effect (as compared to VX). Please show the 2 lines in case.in0 Am 10.05.2024 um 15:56 schrieb Yakup Boran: > Dear Wien2K users, > I am running a calculation for a Bi-containing compound with a > tetragonal structure type. I used LDA with mBJ, and then, due to the > heavy Bi atom, I did the SOC calculation. The calculated band gap > energy with SOC is smaller than without SOC. I checked the literature, > and the band gap decrease is common for SOC calculation. However, if I > use PBE-GGA with mBJ (instead of LDA with mBJ), the band gap energy > with SOC is greater than without SOC, which is contrary to the > literature. > > Is it possible that I get a band gap decrease with LDA while I get a > band gap increase with PBE-GGA when the SOC effect is taken into > consideration? > > Any response will be appreciated. > > Best Regards > > Yakup Bran > > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at <mailto:Wien@zeus.theochem.tuwien.ac.at> > htt
Re: [Wien] Mysterious errors parallel jobs
Everything is fine. It is the default behavior of wien2k, that during running a dummy error message is printed. When the step completes, the error file gets zero size. Suppose, the jobstep is killed by the OS (eg. out of memory,..) or by the user, then the starting shell script (run_lapw) can find out if the step crashed (or was killed) or finished properly. Am 13.05.2024 um 20:24 schrieb Straus, Daniel B: Hi, I am trying to run WIEN2k 23.2 on a Slurm cluster using a modified version of the example scripts to make the .machines file. The jobs seem to be running okay, but there are nondescript messages in the .error files I am trying to figure out. For instance, when running a 4 node job with parallel LAPW0, as soon as the job starts, lapw0.error shows “Error in LAPW0”, but the job keeps running, and when LAPW0 completes, lapw0.error is blank. Similarly, as soon as LAPW1 starts, uplapw1_1.error shows “Error in LAPW1” (but uplapw1_2, _3, and _4 are blank), and uplapw1.error shows “** Error in Parallel LAPW1”. However, the job steps keep running, and I cannot find any more descriptive error messages. Stdout shows no printed error messages—for LAPW0, the only message printed to stdout is LAPW0 END. Any suggestions on where I should look to find the specific error that is occurring? I looked through the output files and found nothing Daniel Straus Assistant Professor Department of Chemistry Tulane University 5088 Percival Stern Hall 6400 Freret Street New Orleans, LA 70118 (504) 862-3585 http://straus.tulane.edu/ <http://straus.tulane.edu/> ___ 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 Email: peter.bl...@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] [WIEN2k] abort of CPU core parallel jobs in NMR calculations of the current
This makes sense. Please let me know if it shows EXECUTING: /usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current-green -scratch /scratch/WIEN2k/ -noco or onlynmr -case ... In any case, it is running correctly. PS: I know that also the current step needs a lot of memory, after all it needs to read the eigenvectors of all eigenvalues, ... PPS: -quota 8 (or 24) might help and still utilizing all cores, but I'm not sure if it would save enough memory in the current steps. Am 12.05.2024 um 10:09 schrieb Michael Fechtelkord via Wien: Hello all, hello Peter, That is what is really running in the background (from htop: this is a new job with 4 nodes but it was the same with 8 nodes -p 1 - 8), so no nmr_mpi. TIME+ Command 96.0 14.9 19h06:05 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 3 95.8 14.9 19h05:10 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 1 95.1 14.9 19h06:00 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2K/ -noco -p 2 95.5 15.4 19h08:10 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 4 94.6 14.9 18h35:33 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 3 93.3 15.4 18h36:24 /usr/local/WIEN2k/nmr-case MS_2M1_Al2 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 4 93.3 14.9 18h33:02 /usr/local/WIEN2k/nmr-case MS_2M1_A12 -mode current -green -scratch/scratch/WIEN2k/ -noco -p2 94.0 14.9 18h38:44 /usr/local/WIEN2k/nmr -case MS_2M1_A12 -mode current -green -scratch /scratch/WIEN2k/ -noco -p 1 Regards, Michael Am 11.05.2024 um 20:10 schrieb Michael Fechtelkord via Wien: Hello Peter, I just use "x_nmr_lapw -p" and the rest is initiated by the nmr script. The Line "/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current -green -scratch /scratch/WIEN2k/ -noco " is just part of the whole procedure and not initiated by me manually.. (I only copied the last lines of the calculation). Best regards, Michael Am 11.05.2024 um 18:08 schrieb Peter Blaha: Hallo Michael, I don't understand the line: /usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current -green -scratch /scratch/WIEN2k/ -noco The mode current should run only k-parallel, not in mpi ?? PS: The repetition of nmr_integ:localhost is useless. nmr mode integ runs only once (not k-parallel, sumpara has already summed up the currents) But one can use nmr_integ:localhost:8 Best regards Am 11.05.2024 um 16:19 schrieb Michael Fechtelkord via Wien: Hello Peter, this is the .machines file content: granulartity:1 omp_lapw0:8 omp_global:2 1:localhost 1:localhost 1:localhost 1:localhost 1:localhost 1:localhost 1:localhost 1:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost nmr_integ:localhost Best regards, Michael Am 11.05.2024 um 14:58 schrieb Peter Blaha: Hmm. ? Are you using k-parallel AND mpi-parallel ?? This could overload the machine. How does the .machines file look like ? Am 10.05.2024 um 18:15 schrieb Michael Fechtelkord via Wien: Dear all, the following problem occurs to me using the NMR part of WIEN2k (23.2) on a opensuse LEAP 15.5 Intel platform. WIEN2k was compiled using one-api 2024.1 ifort and gcc 13.2.1. I am using ELPA 2024.03.01, Libxc 6.22, fftw 3.3.10 and MPICH 4.2.1 and the one-api 2024.1 MKL libraries. The CPU is a I9 14900k with 24 cores where I use eight for the calculations. The RAM is 130 Gb and a swap file of 16 GB on a Samsung PCIE 4.0 NVME SSD. The BUS width is 5600 MT / s. The structure is a layersilicate and to simulate the ratio of Si:Al = 3:1 I use a 1:1:2 supercell currently. The monoclinic symmetry of the new structure (original is C 2/c) is P 2/c and contains 40 atoms (K, Al, Si, O, and F). I use 3 NMR LOs for K and O and 10 for Si, Al, and F (where I need the chemical shifts). The k mesh is 40k points. The interesting thing is that the RAM is sufficient during NMR vector calculations (always under 100 Gb RAM occupied) and at the beginning of the electron current calculation. However, the RAM use increases to a critical point in the calculation and more and more data is outsourced into the SWAP File which is sometimes 80% occupied. As you see this time only one core failed because of memory overflow. But using 48k points 3 cores crashed and so the whole current calculation. The reason is of the crash clear to me. But I do not understand, why the current calculation reacts so sensitive with so few atoms and a small k mesh. I made calculations with more atoms and a 1000K point mesh on 4 cores .. they worked fine. So can it be that the Intel MKL library is the source of failure? So I better get back to 4 cor
Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
Do you get identical gaps for: LDA and then MBJ (no SO) PBE and then MBJ (no SO) ??? If you did everything right, there is no reason why adding SO at the end should give a different result. Probably some other mistake ... ? Am 11.05.2024 um 17:32 schrieb Yakup Boran: Dear Dr Blaha, I think I did not write clear enough. The calculation was done by following: 1. I did regular scf calculation with LDA 2. I added mBJ on it. 3. Then I added SOC. I repeated the same calculation with PBE. Thank you 11 May 2024 Cmt, saat 17:08 tarihinde Peter Blaha şunu yazdı: No. These 2 calculations should be exactly the same. What matters is only: XC_MBJ Everything in parenthesis is only a comment to give you a few common options. Am 11.05.2024 um 16:00 schrieb Yakup Boran: Dear Dr Blaha, Thank you for your response. ——— case.in0 for LDA is TOT XC_MBJ ( (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ——- Case.in0 for PBE TOT XC_MBJ ( (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ———- Best regards 11 May 2024 Cmt, saat 16:03 tarihinde Peter Blaha şunu yazdı: I'm not quite sure I understand what you did. You are always using mBJ (for VX), but how do you mix in LDA or PBE ? By default we use LDA for VC, (and anything for EX and EC, since this is not important). Usually, the choice of VC has only a small effect (as compared to VX). Please show the 2 lines in case.in0 Am 10.05.2024 um 15:56 schrieb Yakup Boran: > Dear Wien2K users, > I am running a calculation for a Bi-containing compound with a > tetragonal structure type. I used LDA with mBJ, and then, due to the > heavy Bi atom, I did the SOC calculation. The calculated band gap > energy with SOC is smaller than without SOC. I checked the literature, > and the band gap decrease is common for SOC calculation. However, if I > use PBE-GGA with mBJ (instead of LDA with mBJ), the band gap energy > with SOC is greater than without SOC, which is contrary to the > literature. > > Is it possible that I get a band gap decrease with LDA while I get a > band gap increase with PBE-GGA when the SOC effect is taken into > consideration? > > Any response will be appreciated. > > Best Regards > > Yakup Bran > > ___ > 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 -- ------- 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
Re: [Wien] [WIEN2k] abort of CPU core parallel jobs in NMR calculations of the current
Hallo Michael,
I don't understand the line:
/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current -green
-scratch /scratch/WIEN2k/ -noco
The mode current should run only k-parallel, not in mpi ??
PS: The repetition of
nmr_integ:localhost is useless.
nmr mode integ runs only once (not k-parallel, sumpara has already
summed up the currents)
But one can use nmr_integ:localhost:8
Best regards
Am 11.05.2024 um 16:19 schrieb Michael Fechtelkord via Wien:
Hello Peter,
this is the .machines file content:
granulartity:1
omp_lapw0:8
omp_global:2
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
Best regards,
Michael
Am 11.05.2024 um 14:58 schrieb Peter Blaha:
Hmm. ?
Are you using k-parallel AND mpi-parallel ?? This could overload
the machine.
How does the .machines file look like ?
Am 10.05.2024 um 18:15 schrieb Michael Fechtelkord via Wien:
Dear all,
the following problem occurs to me using the NMR part of WIEN2k
(23.2) on a opensuse LEAP 15.5 Intel platform. WIEN2k was compiled
using one-api 2024.1 ifort and gcc 13.2.1. I am using ELPA
2024.03.01, Libxc 6.22, fftw 3.3.10 and MPICH 4.2.1 and the one-api
2024.1 MKL libraries. The CPU is a I9 14900k with 24 cores where I
use eight for the calculations. The RAM is 130 Gb and a swap file of
16 GB on a Samsung PCIE 4.0 NVME SSD. The BUS width is 5600 MT / s.
The structure is a layersilicate and to simulate the ratio of Si:Al
= 3:1 I use a 1:1:2 supercell currently. The monoclinic symmetry of
the new structure (original is C 2/c) is P 2/c and contains 40 atoms
(K, Al, Si, O, and F).
I use 3 NMR LOs for K and O and 10 for Si, Al, and F (where I need
the chemical shifts). The k mesh is 40k points.
The interesting thing is that the RAM is sufficient during NMR
vector calculations (always under 100 Gb RAM occupied) and at the
beginning of the electron current calculation. However, the RAM use
increases to a critical point in the calculation and more and more
data is outsourced into the SWAP File which is sometimes 80% occupied.
As you see this time only one core failed because of memory
overflow. But using 48k points 3 cores crashed and so the whole
current calculation. The reason is of the crash clear to me. But I
do not understand, why the current calculation reacts so sensitive
with so few atoms and a small k mesh. I made calculations with more
atoms and a 1000K point mesh on 4 cores .. they worked fine. So can
it be that the Intel MKL library is the source of failure? So I
better get back to 4 cores, even with longer calculation times?
Have all a nice weekend!
Best wishes from
Michael Fechtelkord
---
cd ./ ... x lcore -f MS_2M1_Al2
CORE END
0.685u 0.028s 0:00.71 98.5% 0+0k 2336+16168io 5pf+0w
lcore ready
EXECUTING: /usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode
current -green -scratch /scratch/WIEN2k/ -noco
[1] 20253
[2] 20257
[3] 20261
[4] 20265
[5] 20269
[6] 20273
[7] 20277
[8] 20281
[8] + Abgebrochen ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[7] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[6] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[5] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[4] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[3] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[2] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[1] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
EXECUTING: /usr/local/WIEN2k/nmr -case MS_2M1_Al2 -mode
sumpara -p 8 -green -scratch /scratch/WIEN2k/
current ready
EXECUTING: mpirun -np 1 -machinefile .machine_nmrinteg
/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode integ -green
nmr: integration ... done in 4032.3s
stop
--
---
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
Re: [Wien] Fwd: unit of eval in case.in2
Please read the UG. This is not a valid question for the mailing list. Am 11.05.2024 um 10:38 schrieb shamik chakrabarti: -- Forwarded message - From: *shamik chakrabarti* Date: Thu, 9 May 2024 at 19:50 Subject: Re: unit of eval in case.in2 To: A Mailing list for WIEN2k users Is it that we have to use either 0 or 0.0018 for room temperature broadening? On Thu, 9 May 2024, 17:40 shamik chakrabarti, wrote: sorry the query should be eval to 0.00 or 0.0018? On Thu, 9 May 2024 at 17:39, shamik chakrabarti wrote: Dear Wien2k users, I have a query. What is the unit of eval in case.in2. I want to change TETRA to TEMP in case.in2. Should I change the eval to 0.018 or kept it to 0 ? Looking forward to your response in this regard. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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
Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
No. These 2 calculations should be exactly the same. What matters is only: XC_MBJ Everything in parenthesis is only a comment to give you a few common options. Am 11.05.2024 um 16:00 schrieb Yakup Boran: Dear Dr Blaha, Thank you for your response. ——— case.in0 for LDA is TOT XC_MBJ ( (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ——- Case.in0 for PBE TOT XC_MBJ ( (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN) R2V IFFT (R2V) 30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint, NCON n ———- Best regards 11 May 2024 Cmt, saat 16:03 tarihinde Peter Blaha şunu yazdı: I'm not quite sure I understand what you did. You are always using mBJ (for VX), but how do you mix in LDA or PBE ? By default we use LDA for VC, (and anything for EX and EC, since this is not important). Usually, the choice of VC has only a small effect (as compared to VX). Please show the 2 lines in case.in0 Am 10.05.2024 um 15:56 schrieb Yakup Boran: > Dear Wien2K users, > I am running a calculation for a Bi-containing compound with a > tetragonal structure type. I used LDA with mBJ, and then, due to the > heavy Bi atom, I did the SOC calculation. The calculated band gap > energy with SOC is smaller than without SOC. I checked the literature, > and the band gap decrease is common for SOC calculation. However, if I > use PBE-GGA with mBJ (instead of LDA with mBJ), the band gap energy > with SOC is greater than without SOC, which is contrary to the > literature. > > Is it possible that I get a band gap decrease with LDA while I get a > band gap increase with PBE-GGA when the SOC effect is taken into > consideration? > > Any response will be appreciated. > > Best Regards > > Yakup Bran > > ___ > 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 -- ------- 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
Re: [Wien] Spin-orbit coupling effect on band gap energy with LDA and GGA-PBE
I'm not quite sure I understand what you did. You are always using mBJ (for VX), but how do you mix in LDA or PBE ? By default we use LDA for VC, (and anything for EX and EC, since this is not important). Usually, the choice of VC has only a small effect (as compared to VX). Please show the 2 lines in case.in0 Am 10.05.2024 um 15:56 schrieb Yakup Boran: Dear Wien2K users, I am running a calculation for a Bi-containing compound with a tetragonal structure type. I used LDA with mBJ, and then, due to the heavy Bi atom, I did the SOC calculation. The calculated band gap energy with SOC is smaller than without SOC. I checked the literature, and the band gap decrease is common for SOC calculation. However, if I use PBE-GGA with mBJ (instead of LDA with mBJ), the band gap energy with SOC is greater than without SOC, which is contrary to the literature. Is it possible that I get a band gap decrease with LDA while I get a band gap increase with PBE-GGA when the SOC effect is taken into consideration? Any response will be appreciated. Best Regards Yakup Bran ___ 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
Re: [Wien] [WIEN2k] abort of CPU core parallel jobs in NMR calculations of the current
Hmm. ?
Are you using k-parallel AND mpi-parallel ?? This could overload
the machine.
How does the .machines file look like ?
Am 10.05.2024 um 18:15 schrieb Michael Fechtelkord via Wien:
Dear all,
the following problem occurs to me using the NMR part of WIEN2k (23.2)
on a opensuse LEAP 15.5 Intel platform. WIEN2k was compiled using
one-api 2024.1 ifort and gcc 13.2.1. I am using ELPA 2024.03.01, Libxc
6.22, fftw 3.3.10 and MPICH 4.2.1 and the one-api 2024.1 MKL
libraries. The CPU is a I9 14900k with 24 cores where I use eight for
the calculations. The RAM is 130 Gb and a swap file of 16 GB on a
Samsung PCIE 4.0 NVME SSD. The BUS width is 5600 MT / s.
The structure is a layersilicate and to simulate the ratio of Si:Al =
3:1 I use a 1:1:2 supercell currently. The monoclinic symmetry of the
new structure (original is C 2/c) is P 2/c and contains 40 atoms (K,
Al, Si, O, and F).
I use 3 NMR LOs for K and O and 10 for Si, Al, and F (where I need the
chemical shifts). The k mesh is 40k points.
The interesting thing is that the RAM is sufficient during NMR vector
calculations (always under 100 Gb RAM occupied) and at the beginning
of the electron current calculation. However, the RAM use increases to
a critical point in the calculation and more and more data is
outsourced into the SWAP File which is sometimes 80% occupied.
As you see this time only one core failed because of memory overflow.
But using 48k points 3 cores crashed and so the whole current
calculation. The reason is of the crash clear to me. But I do not
understand, why the current calculation reacts so sensitive with so
few atoms and a small k mesh. I made calculations with more atoms and
a 1000K point mesh on 4 cores .. they worked fine. So can it be that
the Intel MKL library is the source of failure? So I better get back
to 4 cores, even with longer calculation times?
Have all a nice weekend!
Best wishes from
Michael Fechtelkord
---
cd ./ ... x lcore -f MS_2M1_Al2
CORE END
0.685u 0.028s 0:00.71 98.5% 0+0k 2336+16168io 5pf+0w
lcore ready
EXECUTING: /usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode
current -green -scratch /scratch/WIEN2k/ -noco
[1] 20253
[2] 20257
[3] 20261
[4] 20265
[5] 20269
[6] 20273
[7] 20277
[8] 20281
[8] + Abgebrochen ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[7] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[6] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[5] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[4] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[3] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[2] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
[1] + Fertig ( cd $dir; $exec2 >>
nmr.out.${loop} ) >& nmr.err.$loop
EXECUTING: /usr/local/WIEN2k/nmr -case MS_2M1_Al2 -mode sumpara
-p 8 -green -scratch /scratch/WIEN2k/
current ready
EXECUTING: mpirun -np 1 -machinefile .machine_nmrinteg
/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode integ -green
nmr: integration ... done in 4032.3s
stop
--
---
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
Re: [Wien] Continuing: Non convergence of LiNiO2
1. 2x1x1 of R3m (166) LiNiO2 cell 2. It produces 12 atom cell. After X sgroup code instructed to choose settings P3m1 (156) & I have accepted it. 3. I have verified by simulating the XRD of R3m cell & P3m1 cell, that both are giving same XRD using Vesta 4. I have used runsp_lapw -orb -nlvdw -ec 0.0001 -cc 0.0001 to include both GGA+U & nlvdw 5 . For the last 10 iterations the DIS are --- DIS --- :DIS : CHARGE DISTANCE ( 0.3638450 for atom4 spin 1) 0.2170913 :DIS : CHARGE DISTANCE ( 0.3803815 for atom4 spin 1) 0.2210045 :DIS : CHARGE DISTANCE ( 0.6461132 for atom4 spin 1) 0.3107978 :DIS : CHARGE DISTANCE ( 0.6338935 for atom4 spin 1) 0.3051461 :DIS : CHARGE DISTANCE ( 0.6429209 for atom4 spin 1) 0.3107008 :DIS : CHARGE DISTANCE ( 0.3898947 for atom4 spin 1) 0.2278767 :DIS : CHARGE DISTANCE ( 0.3139869 for atom4 spin 1) 0.1967012 :DIS : CHARGE DISTANCE ( 0.3727963 for atom4 spin 1) 0.2165397 :DIS : CHARGE DISTANCE ( 0.2745662 for atom4 spin 1) 0.1856212 :DIS : CHARGE DISTANCE ( 0.2947020 for atom4 spin 1) 0.1929777 Looking forward to your advice in this regard. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at <mailto:Wien@zeus.theochem.tuwien.ac.at> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <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 <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html> ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at <mailto:Wien@zeus.theochem.tuwien.ac.at> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <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 <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html> -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 Email: peter.bl...@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] Is there any format for putting the plasma frequencies? x kram failing despite running joint with switch 4 after 6.
You need 2 Gammas for 2 Drude terms Am 07.05.2024 um 21:13 schrieb Pranjal Nandi: Dear All, Version 23.2. Using init_lapw -sp -prec 1 For adding the intraband contributions in the optic package. I am running x joint with switch 6 and then noting the plasma frequency. Then I am again running it with switch 4. Then I am adding the plasma frequencies xx and zz in the .inkram file like shown below., 0.1 Gamma: broadening of interband spectrum 0.0 energy shift (scissors operator) 1 add intraband contributions? yes/no: 1/0 2.6968 2.5895 plasma frequencies (from joint, opt 6) 0.20 Gammas for Drude terms However when I run x kram, I am getting the following error. At line 180 of file kram.f (unit = 5, file = 'nato.inkram') Fortran runtime error: Bad real number in item 2 of list input Error termination. Backtrace: #0 0x132419223960 in ??? #1 0x1324192244d9 in ??? #2 0x13241922510f in ??? #3 0x1324194701b6 in ??? #4 0x1324194715fd in ??? #5 0x1324194722aa in ??? #6 0x132419477b7a in ??? #7 0x59f6ec7117ec in ??? #8 0x59f6ec70d1de in ??? #9 0x132418e29d8f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x132418e29e3f in __libc_start_main_impl at ../csu/libc-start.c:392 #11 0x59f6ec70d214 in ??? #12 0x in ??? xx zz Energy units: [eV] Lorentzian broadening with gamma: 0.10001 [eV] 223 data points WARNING: Gamma has been redefined to 0.306130001 since your E-grid (case.injoint) was too crude ENERGY INCREMENT: 0.306130001 0.074u 0.008s 0:00.08 87.5% 0+0k 0+0io 0pf+0w error: command /home/pranjal2/WIEN2K/kram kram.def failed I am not sure what I am doing wrong here. Am I putting the plasma frequencies in the correct format? Really stuck at this issue for almost the entire day. Any help would be highly appreciated. With warm regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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 Email: peter.bl...@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] Error in IRelast initialization for tetragonal structure | too many arguments
Never used IRelast myself.
Anyway, the fix is simple: In set_elast_lapw change
set sym=`sgroup -wi $file.struct | grep "Bravais"|cut -c18-18`
to
set sym=`sgroup -wi $file.struct | grep "Bravais lattice:"|cut -c18-18`
Apparently it was not considered that sgroup might give also a message
that the spacegroup has changed.
And this is the problematic point of your struct file. Within rounding
errors this is actually a FCC cubic cell. Check this with sgroup using
different tolerances:
sgroup -wi test.struct -set-TOL=0.001
sgroup -wi test.struct -set-TOL=0.0001
sgroup -wi test.struct -set-TOL=0.1
Am 07.05.2024 um 10:22 schrieb Dr. KISHOR KUMAR डॉ. किशोर कुमार:
Dear Developer and user,
So far, I did not get any answer for error in initialization of IRelast
using {set_elast_lapw} script.
Structure is tetragonal {87_I4/m }. In my previous mail, I already sent
structure file.
error was {at the end of set_elast_lapw script}
-
setupc program found.
goto: Too many arguments.
and not folders created in elast
directory.
Any how, I found some thing but I still have doubt.
in set_elast_script, there is a command at line No. 42, 43 and 49 which
are as:
sgroup -wi $file.struct | grep "Bravais"|cut -c18-18
in
set sym=`sgroup -wi $file.struct | grep "Bravais"|cut -c18-18`
which give output if i do manually as:
if not use cut--
warning: !!! Bravais lattice has changed.
Bravais lattice: Rhombohedral
---if used cut---
a
R
--
From above output lines, probably it will take multiple arguments for
structure and make Too many arguments error.
Although I did some thing manualy using command {cat} as:
set bravais=`cat $file.outputsgroup | grep "Bravais"`
set inf=`cat $file.outputsgroup | grep "Number and" | cut -c33-`
echo "---> $bravais <---"
echo "---> $inf <---"
echo ""
sleep 2
set sel=`echo "setelast"`
set sym=`cat $file.outputsgroup | grep "Bravais"|cut -c18-18`
-
It works and directories are created in elast folder.
But again, calljob_lapw have same command line.
But not sure it is correct or not. Your kind help is needed.
Please help..
Dr. KISHOR KUMAR/डॉ. किशोर कुमार
Department of Physics/भौतिक विज्ञान विभाग
___
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
Email: peter.bl...@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] Confusion on starting prec 2 after prec 1 on the same struct file.
Actually, it is strongly recommended to use the previously converged density (init -prec 2 -nodstart), except when RMTs were .gt. 2.3 bohr. In this case the RMTs get reduced to 2.3 and the old clmsum files cannot be used. I'll probably modify init_lapw such that the reduction of the RMTs can be avoided (the HDLOs usually do a good job in reducing a possible linearization error). Am 06.05.2024 um 17:02 schrieb Mikhail Nestoklon via Wien: Dear Pranjal, it was discussed in mailing list, -prec 2/3 may change some settings which does not allow to reuse previous calculations. Sincerely, M. Dear All, Hello. Version 23.2 Suppose if I do a calculation with prec 1 and then I save everything that I need (save_lapw). On the same structure I would like to do the same calculations BUT this time with prec 2. In this case, when I run SCF, do I need to delete the old scf files or can I keep continuing from the old ones (in w2web when you click on Run SCF, they give you the option to save/delete or continue from the previous data)? I would like to kindly confirm what is the correct way to do (to optimise time). Kindly let me know. Thank you. With warm regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <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 <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 -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Installation of Wien2k_23.2
Look into SRC_3ddens/compile.msg for more details. Since all these programs use fftw, I'd expect that your fftw settings are not correct or the library has been compiled with ifort, ... Am 04.05.2024 um 20:31 schrieb shamik chakrabarti: Dear Wien2k users, While installing Wien2k -23 2 in Ubantu 22.04.4 LTS, I got the following error Compile time errors (if any) were: SRC_3ddens/compile.msg:collect2: error: ld returned 1 exit status SRC_3ddens/compile.msg:make: *** [Makefile:65: 3ddens] Error 1 SRC_hf/compile.msg:collect2: error: ld returned 1 exit status SRC_hf/compile.msg:make[1]: *** [Makefile:199: hf] Error 1 SRC_hf/compile.msg:make: *** [Makefile:181: real] Error 2 SRC_hf/compile.msg:collect2: error: ld returned 1 exit status SRC_hf/compile.msg:make[1]: *** [Makefile:202: hfc] Error 1 SRC_hf/compile.msg:make: *** [Makefile:185: complex] Error 2 SRC_lapw0/compile.msg:collect2: error: ld returned 1 exit status SRC_lapw0/compile.msg:make[1]: *** [Makefile:136: lapw0] Error 1 SRC_lapw0/compile.msg:make: *** [Makefile:125: seq] Error 2 SRC_lapw2/compile.msg:collect2: error: ld returned 1 exit status SRC_lapw2/compile.msg:make[1]: *** [Makefile:187: lapw2] Error 1 SRC_lapw2/compile.msg:make: *** [Makefile:169: real] Error 2 SRC_lapw2/compile.msg:collect2: error: ld returned 1 exit status SRC_lapw2/compile.msg:make[1]: *** [Makefile:190: lapw2c] Error 1 SRC_lapw2/compile.msg:make: *** [Makefile:173: complex] Error 2 SRC_nlvdw/compile.msg:collect2: error: ld returned 1 exit status SRC_nlvdw/compile.msg:make[1]: *** [Makefile:119: nlvdw] Error 1 SRC_nlvdw/compile.msg:make: *** [Makefile:110: seq] Error 2 SRC_nmr/compile.msg:collect2: error: ld returned 1 exit status SRC_nmr/compile.msg:make[1]: *** [Makefile:181: nmr] Error 1 SRC_nmr/compile.msg:make: *** [Makefile:163: real] Error 2 SRC_nmr/compile.msg:collect2: error: ld returned 1 exit status SRC_nmr/compile.msg:make[1]: *** [Makefile:184: nmrc] Error 1 SRC_nmr/compile.msg:make: *** [Makefile:167: complex] Error 2 The Options are Current settings: M OpenMP switch: -fopenmp O Compiler options: -ffree-form -O2 -ftree-vectorize -march=native -ffree-line-length-none -ffpe-summary=none L Linker Flags: $(FOPT) -L../SRC_lib P Preprocessor flags '-DParallel' R R_LIBS (LAPACK+BLAS): -L/home/shamik/OpenBLAS-0.3.26 -lopenblas -lpthread F FFTW options: -DFFTW3 -I/home/shamik/fftw-3.3.10/include FFTW-LIBS: -L/home/shamik/fftw-3.3.10/lib -lfftw-3.3.10 X LIBX options: -DLIBXC -I/home/shamik/libxc-6.2.2/include LIBXC-LIBS: -L/home/shamik/libxc-6.2.2/lib -lxcf03 -lxc Please suggest. -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 Email: peter.bl...@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] Struct file rounding errors from the output of VASP. Unable to solve after repeated attempts.
que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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 Email: peter.bl...@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] Struct file rounding errors from the output of VASP. Unable to solve after repeated attempts.
Your struct file seems ok, but you should do what the code tells you: > If this is supposed to be a hexagonal lattice, STOP and put H lattice type Edit case.struct and set H lattice instead of P Am 04.05.2024 um 11:01 schrieb Pranjal Nandi: Dear Community, I have a hexagonal lattice which I relaxed in VASP and then converted to cif and then cif2struct. Then I also changed the coordinates to fraction such as 2/3 and 1/3. However, still then I am receiving this warnings and suggestions from sgroup and x symmetry. SPACE GROUP DOES NOT CONTAIN INVERSION Angle Gamma is exactly 120. degrees. If this is supposed to be a hexagonal lattice, STOP and put H lattice type alpha(3) .gt. 91.0; reset to 90.1 0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w SPACE GROUP DOES NOT CONTAIN INVERSION Angle Gamma is exactly 120. degrees. If this is supposed to be a hexagonal lattice, STOP and put H lattice type alpha(3) .gt. 91.0; reset to 90.1 0.000u 0.003s 0:00.00 0.0% 0+0k 0+120io 0pf+0w Could someone be kind to explain what parameters in the struct file I need to change so that the rounding off errors doesn’t happen and by doing x symmetry and sgroup the symmetry is detected as H? I am unable to intrepret the issue. Requesting your assistance. With warm regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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 Email: peter.bl...@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] error in x wplot -wf
Check your struct file if the local rotation matrices are properly defined (and orthogonal). It could also be, that the test in SRC_wplot/modules_rc.F: all(abs( matmul(A, transpose(A)) - Id(size(A,1)) ) < MAT_TOL is too fine and a larger value of MAT_TOL should be set in this file. print A and all(abs( matmul(A, transpose(A)) - Id(size(A,1)) ) Am 29.04.2024 um 05:14 schrieb 夏宇阳: Dear all, When i use 'x wplot -wf 1' in wien2wannier, an error came out: Local rotation matrix not orthogonal i use the template, case.inwplot. what should i edit it? Looking for your reply. With regards! ___ 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
Re: [Wien] Optics/x joint working only with prec 1 and NOT with prec 2.
The optics package does not work with HDLOs. You must use: init -prec 2 -nohdlo Am 03.05.2024 um 14:15 schrieb Pranjal Nandi: Dear Community, Hello. W2K version 23.2. Runing in parallel mode with 10 locahosts. When I run the optics (and x joint) after running the scf with prec 1, everything works fine and I get a proper eloss file. When I do the same thing with prec 2, in the eloss file everything is zero. The attachment bato.eloss contains the data with prec 2. I have tried to increase the following in the prec 2 to see if it gives any proper output (after I got no results with the default parameters). But nothing happens. .in1c - K-VECTORS FROM UNIT:4 -9.0 20 85 emin / de (emax=Ef+de) / nband .inop - -5.0 20.0 Emin, Emax for matrix elements, NBvalMAX .injoint - 0. 0.0225 20. : EMIN DE EMAX FOR ENERGYGRID IN ryd It would be helpful if you could please suggest how can I obtain eloss data with the prec 2 (3, haven’t tried yet). Regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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
Re: [Wien] Logging output issue for parallel jobs?
enerated. This refers to lapw0 correctly. starting parallel lapw0 at Wed May 1 16:25:52 CDT 2024 2 <- done at Wed May 1 16:26:18 CDT 2024 3 - 4 starting parallel lapw0 at Wed May 1 18:55:36 CDT 2024 5 <- done at Wed May 1 18:56:00 CDT 2024 6 - Perhaps this is as intended, though I got confused by it. Daniel Straus Assistant Professor Department of Chemistry Tulane University 5088 Percival Stern Hall 6400 Freret Street New Orleans, LA 70118 (504) 862-3585 http://straus.tulane.edu/ <http://straus.tulane.edu/> ___ 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
Re: [Wien] error in 2X2X2 supercel MgO following guide
Most likely, you distorted case.struct. This file is POSITION sensitive, i.e. when you change Mg to Mg1, you MUST NOT use insertion mode, but replace. Am 02.05.2024 um 14:21 schrieb 夏宇阳: Dear all, When i follow the latest guide to make a supercell for MgO, an error came out. i mark the first Mg as Mg1.And then i face an error when i do x nn. Fortran runtime error: Bad value during integer read Error termination. Backtrace: #0 0xb3c5d623960 in ??? #1 0xb3c5d6244d9 in ??? #2 0xb3c5d62510f in ??? #3 0xb3c5d8753a7 in ??? #4 0xb3c5d879ae5 in ??? #5 0xb3c5d87ae55 in ??? #6 0x583a57ce8bad in ??? #7 0x583a57ce726e in ??? #8 0xb3c5d229d8f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #9 0xb3c5d229e3f in __libc_start_main_impl at ../csu/libc-start.c:392 #10 0x583a57ce7294 in ??? #11 0x in ??? Also, i cant use xcrysden to view the struct and setrmt for it. How can i fix it? Looking forward to your reply. With regards! ___ 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
Re: [Wien] Query regarding wien2k_scratch directory
ls -alsh Am 27.04.2024 um 17:57 schrieb shamik chakrabarti: Dear Prof. Gavin, Yes, wien2k is installed under the /home directory. I have also checked /var. there are log files as mentioned in your reference [1]. In this regard, which files should I remove to recover the lost spaces? with regards, On Sat, 27 Apr 2024 at 17:42, Gavin Abo wrote: If your WIEN2k cases are located somewhere under the /home directory, is this the directory you are seeing the space increase in? If your looking at the space of the entire storage drive before and after the calculation, another possibility is the increase could be due to normal usage logging by the operating system. So, if its the /var you are seeing increase after the calculation, it could potentially be due to that as log files could be stored there as seen for example at [1]. [1] https://ubuntu.com/tutorials/viewing-and-monitoring-log-files#2-log-files-locations Kind Regards, Gavin WIEN2k user On 4/26/2024 10:52 PM, shamik chakrabarti wrote: In that case, after deleting the case directory, the space in hd of Linux should be recovered. But the space is decreasing every time, I ran some calculations and after copying delete the whole directory. On Sat, 27 Apr 2024, 01:48 Tomas Kana, wrote: The dot and slash ./ means your current directory Dear Sir, After echo $SCRATCH the output is: ./ Any comments On Fri, 26 Apr 2024 at 22:14, Peter Blaha wrote: During userconfig you have specified a SCRATCH directory. Only you can know what you did there. PS: echo $SCRATCH will tell you, what you specified. Am 26.04.2024 um 13:30 schrieb shamik chakrabarti: Dear Wien2k users, After running calculations I am saving the data in external hdd while deleting the same from linux. However, at each time, after deleting data, I have found that some amount of spaces are not recovered. Wien2k is saving some files in Linux which I am not able to delete. My query is where are those extra files are stored? Whether there is some directory called as _scratch but then I am not able to find it either? Any response is eagerly awaited. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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
Re: [Wien] Query regarding wien2k_scratch directory
Guess what ./ means. Wien2k stores files ONLY in your "case" directories. Am 26.04.2024 um 20:05 schrieb shamik chakrabarti: Dear Sir, After echo $SCRATCH the output is: ./ Any comments On Fri, 26 Apr 2024 at 22:14, Peter Blaha wrote: During userconfig you have specified a SCRATCH directory. Only you can know what you did there. PS: echo $SCRATCH will tell you, what you specified. Am 26.04.2024 um 13:30 schrieb shamik chakrabarti: Dear Wien2k users, After running calculations I am saving the data in external hdd while deleting the same from linux. However, at each time, after deleting data, I have found that some amount of spaces are not recovered. Wien2k is saving some files in Linux which I am not able to delete. My query is where are those extra files are stored? Whether there is some directory called as _scratch but then I am not able to find it either? Any response is eagerly awaited. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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
Re: [Wien] Query regarding wien2k_scratch directory
During userconfig you have specified a SCRATCH directory. Only you can know what you did there. PS: echo $SCRATCH will tell you, what you specified. Am 26.04.2024 um 13:30 schrieb shamik chakrabarti: Dear Wien2k users, After running calculations I am saving the data in external hdd while deleting the same from linux. However, at each time, after deleting data, I have found that some amount of spaces are not recovered. Wien2k is saving some files in Linux which I am not able to delete. My query is where are those extra files are stored? Whether there is some directory called as _scratch but then I am not able to find it either? Any response is eagerly awaited. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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
Re: [Wien] band character plotting with eece
This is enough. Don't use -eece in lapw2. This would "destroy" your scf solution, since the dmats,... would come from a wrong k-mesh. Am 24.04.2024 um 21:50 schrieb Pavel Ondračka: Dear Wien2k mailing list, is this enough for spaghetti with band character for onsite hybrids? x lapw1 (-up/-dn) -orb -band x lapw2 (-up/-dn) -qtl -band or do I need also -eece -orb switches for lapw2? Best regards Pavel ___ 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
Re: [Wien] Warning during x symmetry
This space group has 2 settings, one with or without inversion at the origin of the cell. Wien2k uses the setting with inversion. You must accept the changes made by sgroup (case.struct_sgroup). Am 24.04.2024 um 13:04 schrieb shamik chakrabarti: Dear Wien2k users, I am started to simulate structure of NiS2 (file attached), which showed an warning during x symmetry SPACE GROUP CONTAINS INVERSION BUT ATOMS SHOULD BE SHIFTED BY -0. 2.76745775 -1.60073365 (NOTE: You must convert carthesian to internal coordinates) alpha(3) .lt. 89.8; reset to 90.1 0.003u 0.000s 0:00.00 0.0% 0+0k 0+32io 0pf+0w I have tried to change the origin by changing the coordinates. However, the changed structure exhibit Rmt overlap Any comment would be highly appreciated. with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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
Re: [Wien] error in exercise 6(MgO surface slab)
Try PBE instead of LDA. Which version are you using ? Which compiler ? My present version runs fine with LDA and I cannot remember that there were problems related to LDA. Peter Blaha Am 23.04.2024 um 11:35 schrieb 夏宇阳: It doesnt work with Si. Same error came out. - 原始邮件 - 发件人: "Rubel, Oleg" 收件人: "A Mailing list for WIEN2k users" 发送时间: 星期三, 2024年 4 月 10日 下午 4:06:59 主题: Re: [Wien] error in exercise 6(MgO surface slab) I see that the error occurs in the SCF cycle _before_ Wannier-related commands are called. This means that you cannot run GaAs with XC=LDA. You can test if Si runs with LDA (using identical initialization parameters). Oleg On Apr 9, 2024, at 11:32 AM, harri...@sjtu.edu.cn wrote: Caution: External email. run_lapw 发自我的手机 ___ 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 -- --- 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
Re: [Wien] SLURM cluster issues
Hi, I am trying to set up WIEN2k ver 23.2 to run on a SLURM cluster. I have gotten it to work with SCALAPACK, runnning with a slurm batch submission script through w2web by following the examples. I have two issues. 1. Is it possible to make the “x dstart” button in the initialize web interface submit its job with a script like is possible for running SCF? Right now, it runs on the w2web node, and I can’t use a preexisting .machines file because all jobs are submitted through SLURM so the .machines needs to be generated on the fly. If you really want to run this in parallel on a compute node (makes only sense for really big cases with 100 or more atoms/unit cell), you have to do it similar as with the scf calculation and execute it via a script. A user could activate the -nodstart option in the initialization and run dstart as "single program" with the submission method. 1. 2. I cannot seem to get ELPA to work. It compiles fine and passes the ELPA make check tests. However, when I try to run the TiC example in the usersguide, I always get an error. I have a feeling that ELPA is not using the correct kernel—is there a way to specify that though WIEN2k, or should I set a default ELPA kernel through ELPA ./configure? Here is a link to a zip file with what I hope are the relevant files: https://tulane.box.com/s/ozohfwe0xyoipb8jzxeh3ec15imq1eam. My email got blocked when I attached them directly. I guess the only problem is that the TiC case is too small to run in mpi parallel. In WIEN2k one has to adapt the parallelization to the case one is studying. The openMP parallelization (on one node) works always, but is efficient only up to 4 nodes. It should always be used. The k-point parallelization is the second option, it is helpful if one has many k-points in the input and the lapw1 step takes more than eg. 20 seconds. The last parllelization is via mpi using SCALAPACK and/or ELPA. The latter is much more efficient, but works only if the problem size (number of atoms ---> size of the eigenvalue problem) exceeds a few thousands. Even with such intermediate sizes (NMAT between 3000 -2) the number of cores should not be too large, otherwise communication wins and it takes longer than on fewer cores. For really large problems (NMAT up to 10x10) many cores (eg. 512) can be used efficiently. PS: I always compile ELPA without machine specific options and let it decide on runtime what is available on the specific hardware). PPS: I'd also suggest to run the w2web interface ONLY on a local workstation and setting up a case there. Only after the initialization I'd migrate (migrate_lapw) this to a supercomputer and run the scf there. Best regards -- ------- 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
Re: [Wien] Question of bad E(TOP) with no error
Yes, you should run either init -nohdlo -nodstart -prec xx or (better) you change the HDLO to a HELO: 2 0.30 0. CONT 1 2 0.30 0. CONT 2 the "2" indicates a HDLO. simply change this to: 2 1.30 0. CONT 1 the value of 1.3 is a "guess", depends on the atom/orbital and EF. It should be well above EF. No, don't change "all" 0.3 values, only the second one. Am 10.04.2024 um 10:23 schrieb 夏宇阳: Thanks, so i need to use -nohdlo in init_lapw and change all of the 0.30 of d to a higher number in file in1. Is that right? - 原始邮件 - 发件人: "Peter Blaha" 收件人: "wien" 发送时间: 星期三, 2024年 4 月 10日 下午 3:06:30 主题: Re: [Wien] Question of bad E(TOP) with no error Hi, The use of HDLOs gives you the ultimate solution for the total energy with virtually "exact" (for the given DFT functional) result. However, HDLOs have not been implemented for all "properties". For instance, you cannot use HDLOs for optics or for wien2wanner (you can use, however, one HELO (a LO at higher energy). Am 10.04.2024 um 08:32 schrieb 夏宇阳: Dear Prof.Blaha, Thanks for your reply. It really helps me a lot. Actually,i did the initialization with -nodstart before, and there was an error in the lapw2 calculation later.Now I know the reason. After plot the DOS and bandstructure of KFe2As2 slabs, i tried to use wien2wannier for it. I followed the guide step by step and when i do x wannier90 -up An error came out. After check the file generated by "x w2w -up", i found that all of the data in "*.mmnup" and the data at the bottom of "*.amnup" are "NaN". The possible reason for this is in the "*.outputwfup", the LO COEFFICIENT of Fe and As is NaN and "***" ATPAR ATOMIC PARAMETERS FOR Fe1 ENERGY PARAMETERS ARE 0.02 0.02 0.05 0.02 0.02 0.02 L U(R) U'(R) DU/DEDU'/DE NORM-U' 0 -0.551142E+00 0.124267E+00 0.109667E+00 0.340139E+00 1 0.640043E+00 0.161089E+00 -0.789075E-01 -0.334058E+00 2 0.186063E+00 -0.174896E+00 -0.572407E+00 -0.542898E+00 3 0.825200E+00 0.874714E+00 -0.593096E-01 -0.306556E+00 4 0.950759E+00 0.151315E+01 -0.398060E-01 -0.274852E+00 5 0.105105E+01 0.218939E+01 -0.301429E-01 -0.254103E+00 LO COEFFICIENT: l,A,B,C 0 0.86181 4.33109 0.0 0.0 LO COEFFICIENT: l,A,B,C 0 0.06758 0.0 0.99586 0.0 LO COEFFICIENT: l,A,B,C 1 0.74147 6.01428 0.0 0.0 LO COEFFICIENT: l,A,B,C 1 0.10317 0.0 0.98454 0.0 LO COEFFICIENT: l,A,B,C 2 0.97213 0.31600 0.0 0.0 LO COEFFICIENT: l,A,B,C 2 0.0 0.0 number of rad. functions per L: 3 3 3 2 2 2 ATPAR ATOMIC PARAMETERS FOR As2 ENERGY PARAMETERS ARE 0.42 0.02 0.02 0.02 0.02 0.02 L U(R) U'(R) DU/DEDU'/DE NORM-U' 0 -0.229133E+00 0.708995E+00 0.212786E+00 0.312661E+00 1 0.523646E+00 -0.223201E+00 -0.137651E+00 -0.366257E+00 2 -0.722238E+00 -0.403473E+00 0.544474E-01 0.338522E+00 3 0.867710E+00 0.895087E+00 -0.617087E-01 -0.320081E+00 4 0.101233E+01 0.163812E+01 -0.401997E-01 -0.284836E+00 5 0.112453E+01 0.241620E+01 -0.300851E-01 -0.262492E+00 LO COEFFICIENT: l,A,B,C 0 0.97291 1.04766 0.0 0.0 LO COEFFICIENT: l,A,B,C 0 1.87772 0.0-0.92893 0.0 LO COEFFICIENT: l,A,B,C 1 0.88419 3.36358 0.0 0.0 LO COEFFICIENT: l,A,B,C 1 NaN 0.0 NaN 0.0 LO COEFFICIENT: l,A,B,C 2 0.44520 5.90551 0.0 0.0 LO COEFFICIENT: l,A,B,C 2 0.09624 0.0 0.97840 0.0 number of rad. functions per L: 3 3 3 2 2 2 What cause it? And What should i do next? Looking forward to your reply. With redards. Yuyang Xia - 原始邮件 - 发件人: "Peter Blaha" 收件人: "wien" 发送时间: 星期三, 2024年 4 月 10日 下午 1:26:52 主题: Re: [Wien] Question of bad E(TOP) with no error Hi, The "crazy" E-top is NOT a problem. While for very low lying semicore states we expect to find E-top AND E-bottom (STOP in the corresponding line of case.in1), this is not necessary for higher states. (CONT in in1). We simply do not search for E-top much above EF, since this could lead to an E-parameter (expansion energy of the radial wavefunction) which is higher than EF and thus in the unoccupied region. Obviously, during scf we are interested on an accurate description of the OCCUPIED states below EF. Just one further remark
Re: [Wien] Question of bad E(TOP) with no error
Hi, The use of HDLOs gives you the ultimate solution for the total energy with virtually "exact" (for the given DFT functional) result. However, HDLOs have not been implemented for all "properties". For instance, you cannot use HDLOs for optics or for wien2wanner (you can use, however, one HELO (a LO at higher energy). Am 10.04.2024 um 08:32 schrieb 夏宇阳: Dear Prof.Blaha, Thanks for your reply. It really helps me a lot. Actually,i did the initialization with -nodstart before, and there was an error in the lapw2 calculation later.Now I know the reason. After plot the DOS and bandstructure of KFe2As2 slabs, i tried to use wien2wannier for it. I followed the guide step by step and when i do x wannier90 -up An error came out. After check the file generated by "x w2w -up", i found that all of the data in "*.mmnup" and the data at the bottom of "*.amnup" are "NaN". The possible reason for this is in the "*.outputwfup", the LO COEFFICIENT of Fe and As is NaN and "***" ATPAR ATOMIC PARAMETERS FOR Fe1 ENERGY PARAMETERS ARE 0.02 0.02 0.05 0.02 0.02 0.02 L U(R) U'(R) DU/DEDU'/DE NORM-U' 0 -0.551142E+00 0.124267E+00 0.109667E+00 0.340139E+00 1 0.640043E+00 0.161089E+00 -0.789075E-01 -0.334058E+00 2 0.186063E+00 -0.174896E+00 -0.572407E+00 -0.542898E+00 3 0.825200E+00 0.874714E+00 -0.593096E-01 -0.306556E+00 4 0.950759E+00 0.151315E+01 -0.398060E-01 -0.274852E+00 5 0.105105E+01 0.218939E+01 -0.301429E-01 -0.254103E+00 LO COEFFICIENT: l,A,B,C 0 0.86181 4.33109 0.0 0.0 LO COEFFICIENT: l,A,B,C 0 0.06758 0.0 0.99586 0.0 LO COEFFICIENT: l,A,B,C 1 0.74147 6.01428 0.0 0.0 LO COEFFICIENT: l,A,B,C 1 0.10317 0.0 0.98454 0.0 LO COEFFICIENT: l,A,B,C 2 0.97213 0.31600 0.0 0.0 LO COEFFICIENT: l,A,B,C 2 0.0 0.0 number of rad. functions per L: 3 3 3 2 2 2 ATPAR ATOMIC PARAMETERS FOR As2 ENERGY PARAMETERS ARE 0.42 0.02 0.02 0.02 0.02 0.02 L U(R) U'(R) DU/DEDU'/DE NORM-U' 0 -0.229133E+00 0.708995E+00 0.212786E+00 0.312661E+00 1 0.523646E+00 -0.223201E+00 -0.137651E+00 -0.366257E+00 2 -0.722238E+00 -0.403473E+00 0.544474E-01 0.338522E+00 3 0.867710E+00 0.895087E+00 -0.617087E-01 -0.320081E+00 4 0.101233E+01 0.163812E+01 -0.401997E-01 -0.284836E+00 5 0.112453E+01 0.241620E+01 -0.300851E-01 -0.262492E+00 LO COEFFICIENT: l,A,B,C 0 0.97291 1.04766 0.0 0.0 LO COEFFICIENT: l,A,B,C 0 1.87772 0.0-0.92893 0.0 LO COEFFICIENT: l,A,B,C 1 0.88419 3.36358 0.0 0.0 LO COEFFICIENT: l,A,B,C 1 NaN 0.0 NaN 0.0 LO COEFFICIENT: l,A,B,C 2 0.44520 5.90551 0.0 0.0 LO COEFFICIENT: l,A,B,C 2 0.09624 0.0 0.97840 0.0 number of rad. functions per L: 3 3 3 2 2 2 What cause it? And What should i do next? Looking forward to your reply. With redards. Yuyang Xia - 原始邮件 - 发件人: "Peter Blaha" 收件人: "wien" 发送时间: 星期三, 2024年 4 月 10日 下午 1:26:52 主题: Re: [Wien] Question of bad E(TOP) with no error Hi, The "crazy" E-top is NOT a problem. While for very low lying semicore states we expect to find E-top AND E-bottom (STOP in the corresponding line of case.in1), this is not necessary for higher states. (CONT in in1). We simply do not search for E-top much above EF, since this could lead to an E-parameter (expansion energy of the radial wavefunction) which is higher than EF and thus in the unoccupied region. Obviously, during scf we are interested on an accurate description of the OCCUPIED states below EF. Just one further remark (provided you did not have RMTs above 2.3 in the original setup with -prec 1): init_lapw -perc 1 -ecut -7.0 -sp runsp_lapw -i 1000 -fc 3 -p save_lapw unrelaxed runsp_lapw -i 1000 -min -fc 1 -p save_lapw relaxed init_lapw -prec 2 -ecut -7.0 -sp-nodstart<- this would save a lot of cpu time runsp_lapw -i 1000 -cc 0.0001 -p -nodstart will not produce a new density, but you would continue with the already converged one (from the previous runsp_lapw). Only if you had large spheres (above 2.3), prec 2 will reduce these spheres automatically and you must start over with dstart since the radial mesh has been changed. I am doing a project about KFe2As2 surface. After relaxing the surface slab in prec 1, i did a prec 2 calculation with cc 0
Re: [Wien] Question of bad E(TOP) with no error
lk calulation, the As still has a bad E(TOP). Looking forward to your reply. With regards! Yuyang Xia ___ 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
Re: [Wien] 回复： error in exercise 6(MgO surface slab)
At the moment you have to use init -prec 1 instead of 1n. After that, you can rerun x kgen with 30 total points, which should lead to a 6 6 1 mesh. - I'm not aware of the other problem, but maybe Oleg Rubel knows more ... Am 08.04.2024 um 23:48 schrieb harri...@sjtu.edu.cn: Dear Prof.Blaha, It is on my home computer with wien2k_23. And there is another error existing when i do the scf of GaAs following the guide of "wien2k + w2wannier+wannier90". I can't use LDA for initialization, and it will lead an error in scf calculation. But I can use PBE and WC.They perform well. Looking forward to your reply. With regards! Yuyang Xia 发自我的手机 原始邮件 发件人： Peter Blaha 日期： 2024年4月9日周二 凌晨4:07 收件人： wien@zeus.theochem.tuwien.ac.at 主 题： Re: [Wien] error in exercise 6(MgO surface slab) Hi, Where does this happen and with which version of WIEN2k. It is on the workshop nodes or on your home computer with WIEN2k_23. I'm aware of this problem and I think I fixed in on the workshop nodes. Of course it will still happen when using WIEN2k_23 and only the next release will have fixed it. Peter Blaha Am 08.04.2024 um 16:43 schrieb 夏宇阳: > Dear all, > I am doing the latest exercise 6(MgO surface slab),and there is a error when do "init_lapw -prec 1n" > > STOP KGEN ENDS > NUMK: 1000 > basic k-mesh: 12, 12, 2 = 288, kfactor = .1000 > NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K) > At line 243 of file main.f (unit = 5, file = 'stdin') > Fortran runtime error: Bad integer for item 1 in list input > > what should i do? > Looking forward to your reply. > > With regards! > ___ > 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 -- --- 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
Re: [Wien] error in exercise 6(MgO surface slab)
Hi, Where does this happen and with which version of WIEN2k. It is on the workshop nodes or on your home computer with WIEN2k_23. I'm aware of this problem and I think I fixed in on the workshop nodes. Of course it will still happen when using WIEN2k_23 and only the next release will have fixed it. Peter Blaha Am 08.04.2024 um 16:43 schrieb 夏宇阳: Dear all, I am doing the latest exercise 6(MgO surface slab),and there is a error when do "init_lapw -prec 1n" STOP KGEN ENDS NUMK: 1000 basic k-mesh: 12, 12, 2 = 288, kfactor = .1000 NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K) At line 243 of file main.f (unit = 5, file = 'stdin') Fortran runtime error: Bad integer for item 1 in list input what should i do? Looking forward to your reply. With regards! ___ 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
Re: [Wien] Bug / odd behavior: Can't change some of the session information
Hi,
the "session information" is meant as an information, and while one can
change some options, this would not make sense and should not be done.
Eg. when you make a spin-polarized initialization and later on switch
spin-polarization off, the calculations will crash. The same is true
vice versa.
The "complex" setting is in more recent versions of WIEN2k done
automatically based on the struct file. It checks if inversion is
present in case.struct. However, if there is no struct file, this test
yields "complex calculation" (obviously, inversion symmetry is not
present).
I've now modified checkcomplex_lapw such that it returns nothing when
the struct file is missing.
In essence: "session information" might give some information AFTER a
calculation has been done, but is not meant to change this info.
Best regards
Peter Blaha
Am 02.04.2024 um 22:01 schrieb Per-Anders Glans-Suzuki:
Dear Wien2k users,
I just did a fresh install of Wien2k 23.2 on a new computer and running
a sanity check with the TiC example.
Issue:
- I can’t turn ‘complex calculation’ off in session information..
- Upon further investigation I also can’t turn AFM calculation on.
- However, I *can* turn spin polarization on or off, and I can turn
parallel calculation on or off. I can also add comments.
For each of the three points above I clicked ‘Change session
information’, change one of the checkboxes, click ’save changes’, then
‘Click ro restart session’. When the session information is redisplayed,
‘complex calculation’ or ‘AFM calculation’ are unchanged no matter what
I do.
The session file ~/.w2web//sessions/ is not updated when
attempting to change complex or AFM, but is updated when changing spin
polarized or parallel. Hence, I don’t believe there is an issue with
permissions…?
The TiC directory is empty.
If I kill w2web and edit the file under ~/.w2web//sessions/ and
restart w2web, the ‘Complex calculation’ is unchecked. However, if I
click ‘Change session information’, and then click ’Save changes’ on the
next screen without doing any changes, the ‘Complex calculaiton’ check
box is again checked.
I haven’t found anything in the mailing list except for a similar
question in 2013 where the answer was to remove old files and start
over, which I have attempted (actually, the TiC directory is empty when
first staring a session and when these anomalies are observed). Unless
there are more files somewhere… Please let me know if I’ve missed
something obvious, or if you’d like more info.
This is a Tuxedo laptop running tuxedo OS, which is basically Ubuntu.
gfortran/gcc version 11.4.0.
Perl version 5.34.0
Thank you,
Anders Glans
___
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
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW: http://www.imc.tuwien.ac.at
-#!/bin/tcsh -f
if( "$1" == '-h' ) goto help
if($#argv != 1) goto help
set cmplx1=" "
set file=$1
if( -e $file.struct && ! -z $file.struct) then
set cmplx1=`cut -b -6 $file.struct |awk 'BEGIN{c="CHECKED"};{if ($0 == "-1 0
0") {getline; {if ($0 == " 0-1 0"){getline; {if ($0 == " 0 0-1"){c=
""}};END{print c}'`
endif
echo $cmplx1
exit 0
help:
echo usage: checkcomplex_lapw case.struct [-h ]
echo checks if inversion symmetry is present in case.struct
echo returns CHECKED if inversion is not present
exit 1
___
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] error in lapw1
x lapw1 -h Am 30.03.2024 um 16:08 schrieb 夏宇阳: Dear prof.Blaha, Thank you very much ,sir. i forget it is a spin-polarized calculation. But when i use "lapw1 -h", it doesnt give me help information,but creates a blank "-h" and "fort.12" file for me. is there anything wrong? With regards - 原始邮件 - 发件人: "Peter Blaha" 收件人: "wien" 发送时间: 星期六, 2024年 3 月 30日 下午 10:55:43 主题: Re: [Wien] error in lapw1 It is missing the spherical potential, case.vsp Why ?? We don't know what you have done before. Did you run the scf cycle before ?? Is this a spin-polarized calculation ? Then you need to add -up or -dn switches. PS: x lapw1 -hdoes not harm. All our scripts have a -h (help) switch which just gives you some information. Am 30.03.2024 um 15:36 schrieb 夏宇阳: Dear all, there is a error when i do lapw1. it said: 'INILPW' - can't open unit: 18 'INILPW' -filename: 001relaxed.vsp 'INILPW' - status: old form: formatted 'LAPW1' - INILPW aborted unsuccessfully. i think maybe the reason i wrongly used "lapw1 -h" to get help what should i do now? with regards ___ 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 Email: peter.bl...@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] error in lapw1
It is missing the spherical potential, case.vsp Why ?? We don't know what you have done before. Did you run the scf cycle before ?? Is this a spin-polarized calculation ? Then you need to add -up or -dn switches. PS: x lapw1 -hdoes not harm. All our scripts have a -h (help) switch which just gives you some information. Am 30.03.2024 um 15:36 schrieb 夏宇阳: Dear all, there is a error when i do lapw1. it said: 'INILPW' - can't open unit: 18 'INILPW' -filename: 001relaxed.vsp 'INILPW' - status: old form: formatted 'LAPW1' - INILPW aborted unsuccessfully. i think maybe the reason i wrongly used "lapw1 -h" to get help what should i do now? with regards ___ 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 Email: peter.bl...@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] Question in optimizing the position of a ferromagnetic material
First of all: I hope you have done KFe2As2 bulk first. Since it contains Fe, it could be that it is magnetic (FM or AFM ? check literature) and one should use runsp Check out if a magnetic moment persists, this answers your question if you should use run or runsp Why do you initialize with RKMAX=9.5 ??? This is not necessary but slows down the calculations by a factor of up to 100 !!! Use: init -prec 1 (for a reasonable accuracy) or 2 (for very good convergence, which I would use only at the very end once the surface is fully relaxed) For a magnetic surface it is not unusually that the scf needs many cycles (depending on your case even 100 or so), and the minimization may take several hundreds of cycles (therefore one does it with low RKMAX and fewer k-points). Am 28.03.2024 um 06:34 schrieb harri...@sjtu.edu.cn: Dear all, I am doing the optimization with the surface slab of KFe2As2. When i use "run_lapw",it can be convergent with fc 20 in 21 cycles. And when i use "runsp_lapw",it doesnt converge in fc 20. I would like to know if spin polarization calculation is necessary for optimization. They both do the initialization. "Init_lapw -b -vxc 13 -ecut -10 -rkmax 9.5 -numk 100 -fermit 0.002" "Init_lapw -b -vxc 13 -ecut -10 -rkmax 9.5 -numk 100 -fermit 0.002 -sp" With regards. Harriron 发自我的手机 ___ 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 Email: peter.bl...@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] Cholesky in supercell
I am trying to calculate a sufficiently large 2x3x15 supercell based on a tetragonal barium titanate (BaTiO3) cell. In this calculation, I create an oxygen vacancy and a surface. The calculation is successfully Sufficiently large ??? I'd say, it is MUCH too large. 2x3 ?? either use 2x2 or 3x3. (you want to separate the vacancies in x and y in the same way). 15 ?? One cell contributes 2 layers, so with 15 units (+ repetition on top) you have 31 layers. I'd guess 3-5 cells are enough. Do you have inversion ? You need to report how you ran the calculation. mpi-parallel ? How many cores, ... RKmax, ... initialized with the parameters of atomic spheres equal to Rmt(Ba)=2.30, Rmt(Ti)=1.82, Rmt(O)=1.65. However, when I run the calculation with PBE, iterative diagonalization, an error appears: ** Error in Parallel LAPW1 ** LAPW1 STOPPED ** check ERROR FILES! Cholesky INFO = 9896 'SECLR4' - POTRF (Scalapack/LAPACK) failed. I tried to find an answer in WIEN2k's letters – among the suggestions was rerun the calculation after setting other initial electron density parameters (dstart), changing the radii of atomic spheres, and others, but they did not help. What could I do to run this calculation correctly? Thank you in advance, Best Regards, Natalia Add reaction ___ 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 Email: peter.bl...@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] Compilation error of Libxc during installation of WIEN2K 23.2
The libxc site has been moved recently to: https://libxc.gitlab.io/ After download, you have to compile it. Did you do this ? Then you need to configure wien2k in siteconfig properly for using libxc. Am 25.03.2024 um 15:29 schrieb Pranjal Nandi: Dear All, Hello. While compiling the 23.2 version, the link mentioned in the pdf (which contains the codes used for the compilation) to install libxc was NOT working (http://www.tddft.org/programs/libxc/down.php?file=6.2.2/libxc-6.2.2.tar.gz <http://www.tddft.org/programs/libxc/down.php?file=6.2.2/libxc-6.2.2.tar.gz>). So I tried to download it from other websites and did the compilation. The only errors I saw are as the following. Fatal Error: Cannot open module file ‘xc_f03_lib_m.mod’ for reading at (1): No such file or directory compilation terminated. make[1]: *** [Makefile:176: libxc_mod.o] Error 1 make[1]: Leaving directory '/home/pranjal2/WIEN2K/SRC_lapw0' make: *** [Makefile:129: para] Error 2 It would be helpful if you could please guide me with the correct link to the libxc (I think it is because of downloading the libxc from other websites and not TDDFT). I also searched the forum regarding the same but I got comments about a very old version. Hence, I decided to ask the community for your assistance. Looking forward to your guidance. Thank you. With warm regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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 Email: peter.bl...@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] Inconsistency in kgen
However, when I look at the klist file with my understanding, I still find myself confused. You mentioned that "this vector points 'outside' the conventional 'cube,'" and I fully understand this statement. I understand that Cartesian coordinates may extend beyond the 0..1 range. However, what I am referring to are internal coordinates. In my understanding, the point "64 6 6 6 4 1.0" lies outside the 0..1 range of internal coordinates, which means it is outside the reciprocal unit cell. Therefore, in my understanding, this point needs to be mapped into the reciprocal unit cell. The klist file gives the k-point in cartesian fractional coordinates in the reciprocal lattice, not in internal coordinates . However, after it is mapped into the reciprocal unit cell, I believe it is equivalent to the point "22 2 2 2 4 1.0." No ! In cartesian coordinates the BZ does NOT go from 0 to 1 !!! As I wrote before, the transformation is done via multiplication of the vector with one of the bravais matrices listed in outputkgen. Yet, for an FBZ klist, I believe there shouldn't be two equivalent k points, and indeed, in output1, the eigenvalues of these two points are different. So, I have been requesting if you could provide the internal coordinates for these two points, as well as the transformation formula. I believe only by doing so can my confusion be resolved. Thank you again for your assistance. Best regards -- Original -- From: "A Mailing list for WIEN2k users" ; Date: Fri, Mar 22, 2024 04:36 PM To: "wien"; Subject: Re: [Wien] Inconsistency in kgen In outputkgen the direct and reciprocal bravais matrices are printed. They can be used to multiply the corresponding vectors (coordinates) and transfer them. For instance for B (body-centered) lattices the Bravaismatrix is: (-1 1 1 1 -1 1 1 1 -1 ) times the lattice constants a,b,c. So the first primitive lattice vector (0,0,1) looks in kartesian coordinates as (-1,1,1) (always times a,b,c). Thus you can immediately "see", that this vector points "outside" the conventional "cube". In essence, this is the reason why some coordinates in carthesian coordinates are outside the "cube" (outside (0 ... 1)) I guess, this is enough "geometry" and introduction Am 22.03.2024 um 09:14 schrieb balabi via Wien: > Dear Prof. Peter Blaha, > > I hope this message finds you well. > > I wanted to express my gratitude for your prompt reply. I truly > appreciate the time and effort you have taken to assist me with my query. > > However, I apologize for any misunderstanding. While I do have a grasp > of the concepts surrounding internal and Cartesian coordinates as > mentioned in your previous email, the mention of the "common > denominator" is new to me. > > Would it be possible for you to provide me with the formula for > transitioning from casename.klist to the internal coordinates within the > first reciprocal unit cell, as I had mentioned in my previous > correspondence? This information would greatly aid in clarifying my > understanding, particularly in relation to the following k points: > 22 2 2 2 4 1.0 > and > 64 6 6 6 4 1.0 > Knowing their corresponding internal coordinates would be immensely > helpful in resolving any confusion I may have. > > Once again, I sincerely appreciate your assistance with this matter. > > Thank you very much for your time and consideration. > ___ 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 Email: peter.bl...@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] Problem with dielectric function
Ok. Next, you must look into the generated files. case.output1up/dn are there eigenvalues listed ? case.scf2up/dn Ef and band ranges listed ? case.outputopup/dn any errors, NaN, ... $SCRATCH/case.symmaup/dn non-zero matrix elements ? case.jointup/dnat energies above the gap some non-zero values should be listed case.joint as above Regards Am 22.03.2024 um 12:14 schrieb Hamza BFA: Dear Prof. P. Blaha, emax =2.5 Ry was chosen 3000 Kpoints here are the steps followed emax =2.5 Ry was chosen x lapw1 -up/dn -p x lapw2 -fermi -up/dn -p x optic -up/dn -p x joint -up/dn -p adjoint-updan (YPdAs.joint has been created adding up+dn) x kram Sincerely Le ven. 22 mars 2024 à 02:01, Hamza BFA <mailto:hamza@gmail.com>> a écrit : Hi, after an optical calculation of a narrow gap semiconductor with PBEsol functional, I obtained a zero imaginary part and a constant real part (equal to 1) of the dielectric function. More details : 23.2 version init -prec 2 -numk 1500 -nohdlo -sp -b runsp -p -ec 0.1 input files are in attachment Do you have a solution to this problem.? Sincerely #YPdAs.epsilon # # Lorentzian broadening with gamma= 0.10 [eV] # Im(epsilon) shifted by 0. [eV] # No intraband contributions added # # Energy [eV] Re_eps_xx Im_eps_xx Re_eps_zz Im_eps_zz # 0.013610 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.040820 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.068030 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.095240 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.122450 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.149660 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.176870 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.204090 0.10E+01 0.00E+00 0.10E+01 0.00E+00 . . 13.265560 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.292770 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.319980 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.347190 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.374400 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.401610 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.428820 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.456030 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.483250 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.510460 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.537670 0.10E+01 0.00E+00 0.10E+01 0.00E+00 13.564880 0.10E+01 0.00E+00 0.10E+01 0.00E+00 ___ 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 Email: peter.bl...@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] Inconsistency in kgen
In outputkgen the direct and reciprocal bravais matrices are printed. They can be used to multiply the corresponding vectors (coordinates) and transfer them. For instance for B (body-centered) lattices the Bravaismatrix is: (-1 1 1 1 -1 1 1 1 -1 ) times the lattice constants a,b,c. So the first primitive lattice vector (0,0,1) looks in kartesian coordinates as (-1,1,1) (always times a,b,c). Thus you can immediately "see", that this vector points "outside" the conventional "cube". In essence, this is the reason why some coordinates in carthesian coordinates are outside the "cube" (outside (0 ... 1)) I guess, this is enough "geometry" and introduction Am 22.03.2024 um 09:14 schrieb balabi via Wien: Dear Prof. Peter Blaha, I hope this message finds you well. I wanted to express my gratitude for your prompt reply. I truly appreciate the time and effort you have taken to assist me with my query. However, I apologize for any misunderstanding. While I do have a grasp of the concepts surrounding internal and Cartesian coordinates as mentioned in your previous email, the mention of the "common denominator" is new to me. Would it be possible for you to provide me with the formula for transitioning from casename.klist to the internal coordinates within the first reciprocal unit cell, as I had mentioned in my previous correspondence? This information would greatly aid in clarifying my understanding, particularly in relation to the following k points: 22 2 2 2 4 1.0 and 64 6 6 6 4 1.0 Knowing their corresponding internal coordinates would be immensely helpful in resolving any confusion I may have. Once again, I sincerely appreciate your assistance with this matter. Thank you very much for your time and consideration. best regards -- Original -- From: "A Mailing list for WIEN2k users" ; Date: Fri, Mar 22, 2024 03:17 PM To: "wien"; Subject: Re: [Wien] Inconsistency in kgen Come on ! You can specify coordinates in absolute units, or in fractions of the (reciprocal) lattice vectors. E.g. an atom position can be given as (3.123,2.332,1.966) in units of Ang; or as (0.5,0.5,0.5) in units of a,b, and c. This is exactly what is done in outputkgen. 0.0 0.0 0.25000 0.22411 0.22411 0.0 fractions of primitive rec.lattice carthes. coord (bohr^-1) 0.25000 0.25000 0.0 2.0 2.0 0.0 fractional carth. coord same as left, but multiplied by 8 to find a common denominator. ___ 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 Email: peter.bl...@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] Problem with dielectric function
You did not specify the steps for the optics. Did you increase EMAX in case.in1 ??? Did you add spin-up and dn contributions after joint (see UG) ? Am 22.03.2024 um 02:01 schrieb Hamza BFA: Hi, after an optical calculation of a narrow gap semiconductor with PBEsol functional, I obtained a zero imaginary part and a constant real part (equal to 1) of the dielectric function. More details : 23.2 version init -prec 2 -numk 1500 -nohdlo -sp -b runsp -p -ec 0.1 input files are in attachment Do you have a solution to this problem.? Sincerely #YPdAs.epsilon # # Lorentzian broadening with gamma= 0.10 [eV] # Im(epsilon) shifted by 0. [eV] # No intraband contributions added # # Energy [eV] Re_eps_xx Im_eps_xx Re_eps_zz Im_eps_zz # 0.013610 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.040820 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.068030 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.095240 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.122450 0.10E+01 0.00E+00 0.10E+01 0.00E+00 0.149660 0.10E+01 0.00E+00 0.10E+01 0.00E+00-- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Inconsistency in kgen
Come on !
You can specify coordinates in absolute units, or in fractions of the
(reciprocal) lattice vectors.
E.g. an atom position can be given as (3.123,2.332,1.966) in units of
Ang; or as (0.5,0.5,0.5) in units of a,b, and c.
This is exactly what is done in outputkgen.
0.0 0.0 0.25000 0.22411 0.22411 0.0
fractions of primitive rec.lattice carthes. coord (bohr^-1)
0.25000 0.25000 0.02.0 2.0 0.0
fractional carth. coordsame as left, but multiplied by 8 to
find a common denominator.
Am 22.03.2024 um 06:21 schrieb balabi via Wien:
Dear Prof. Peter Blaha,
Thank you so much for your reply. But I think you might have
misunderstood me. I understand the difference between internal and
cartesian coordinates.
Let me take for example, Let us generate 4x4x4 mesh by 'x kgen -fbz' for
CaFe2As2 I4/mmm structure. The klist is as below:
1 0 0 0 4 1.0 -7.0 1.5
0 k, div: ( 4 4 4)
2 1 1 0 4 1.0
3 2 2 0 4 1.0
4 3 3 0 4 1.0
5 1 0 1 4 1.0
6 2 1 1 4 1.0
7 3 2 1 4 1.0
8 4 3 1 4 1.0
9 2 0 2 4 1.0
10 3 1 2 4 1.0
11 4 2 2 4 1.0
12 5 3 2 4 1.0
13 3 0 3 4 1.0
14 4 1 3 4 1.0
15 5 2 3 4 1.0
16 6 3 3 4 1.0
17 0 1 1 4 1.0
18 1 2 1 4 1.0
19 2 3 1 4 1.0
20 3 4 1 4 1.0
21 1 1 2 4 1.0
22 2 2 2 4 1.0
...
...
62 4 4 6 4 1.0
63 5 5 6 4 1.0
64 6 6 6 4 1.0
END
In the output from kgen, there's a block labeled "internal and cartesian
k-vectors" which states:
internal and cartesian k-vectors:
0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.25000 0.22411 0.22411 0.0
0.0 0.0 0.5 0.44822 0.44822 0.0
0.0 0.0 0.75000 0.67233 0.67233 0.0
...
...
0.75000 0.75000 0.0 0.67233 0.67233 0.18668
0.75000 0.75000 0.25000 0.89644 0.89644 0.18668
0.75000 0.75000 0.5 1.12055 1.12055 0.18668
0.75000 0.75000 0.75000 1.34465 1.34465 0.18668
NO. OF INEQUIVALENT K-POINTS 64
I clearly understand this "internal and cartesian k-vectors" block. The
left three columns represent coordinates relative to reciprocal vectors,
and the right three columns are coordinates in Cartesian, i.e.,
{x,y,z}.reciprocalVectorMatrix. All coordinates are unique and appear
very reasonable.
However, my confusion arises with the k-list. It seems that the order of
this block is not the same as that in the k-list file. For example, the
second line in the k-list is:
2 1 1 0 4 1.0
I think this corresponds to internal coordinate
0.25000 0.25000 0.0
right? But this is not the 2nd line in "internal and cartesian
k-vectors" block. Why is that?
Also, what is the relation between "internal and cartesian k-vectors"
block and klist? Why are they in different order?
Moreover, regarding the last line in the k-list:
64 6 6 6 4 1.0
What internal coordinate does it correspond to? Given that {6,6,6} is
outside the 4x4x4 range, should we not modulo it by 4 to get {2,2,2},
which corresponds to 0.5 0.5 0.5? If this is correct, then
this 64th point is a duplication of the 22nd point in the k-list. Why,
then, are the eigenvalues on the 22nd and 64th k points different? If
WIEN2k is using the correct k point, it suggests my understanding is
incorrect. Could you please provide me with a formula to convert x, y, z
in the klist to the correct internal coordinates for this particular
case? This would help me understand where my error lies.
Finally, in the last part of outputkgen, there is a block says
NKP,NDIV,afact 64 4 4 4
0.500
0.0 0.0 0.00
Re: [Wien] Inconsistency in kgen
Hi,
No, you should not modify the kmesh.
The k-vectors are generated in the primitive (non-orthogonal) basis, but
transformed afterwards to carthesian coordinates.
By this operation, some of the k-points may obtain values larger than one.
Note, that in carthesian coordinates, the BZ does not go from 0-1 in
kx,ky,kz.
You also noted that (0,0,0) yields different eigenvalues than (1,1,1).
Am 21.03.2024 um 04:39 schrieb balabi via Wien:
Dear Prof. Peter Blaha,
Thank you very much for your new fix.
I have another question. When we generate an fbz 10x10x10 non-shifted
kmesh for CaFe2As2, the klist file contains 1000 points. However, many
of these points fall outside the 10x10x10 range. For example, the 560th
point is listed as "14 14 10".
I guess applying the modulo operation by 10 is necessary, so "14 14 10"
would be equivalent to "4 4 0," correct? However, when I apply modulo to
all k-points, I find that many k-points are missing (e.g., {0,0,1},
{0,0,3}) and duplicated (in terms of modulo).
Why is this happening? In the context of the FBZ, shouldn't the klist
file contain 1000 unique k-points?
Specifically, the 556th k-point is "10 10 10," which should be
equivalent to "0 0 0" according to modulo. However, I checked the "0 0
0" k-point in output1 file has different eigenvalues compared to the
556th "10 10 10" k-point. I am confused by this discrepancy. Which k
point "10 10 10" really refers? Please help. Thank you very much.
Best regards,
-- Original --
*From:* "A Mailing list for WIEN2k users" ;
*Date:* Wed, Mar 20, 2024 05:48 AM
*To:* "wien";
*Subject:* Re: [Wien] Inconsistency in kgen
Hi,
Yes, my fix was not correct. The bct and bco lattices are special cases
and are also discussed in literature.
While the direct lattice vectors in bct have all the same length, the
reciprocal lattice is face-centered tetragonal and thus they have
different length. Nevertheless as far as I understand it is usually
recommended to use the same divisions of them, when constructing a
k-mesh. This was also enforced in WIEN2k, only the recent addition of
specifying a delta-k was breaking this, but led to wrong multiplicities.
The algorithm for finding the multiplicity does not work for bct, when
the divisions are not the same.
The present fix is to go back to the original bravai.f and use the new
basdiv.f, which enforces equal k-divisions in the bct/bco case.
Thanks for checking.
Peter 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
--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@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] Inconsistency in kgen
Hi, Yes, my fix was not correct. The bct and bco lattices are special cases and are also discussed in literature. While the direct lattice vectors in bct have all the same length, the reciprocal lattice is face-centered tetragonal and thus they have different length. Nevertheless as far as I understand it is usually recommended to use the same divisions of them, when constructing a k-mesh. This was also enforced in WIEN2k, only the recent addition of specifying a delta-k was breaking this, but led to wrong multiplicities. The algorithm for finding the multiplicity does not work for bct, when the divisions are not the same. The present fix is to go back to the original bravai.f and use the new basdiv.f, which enforces equal k-divisions in the bct/bco case. Thanks for checking. Peter Blaha Am 19.03.2024 um 08:09 schrieb balabi via Wien: Dear Prof. Peter Blaha, I think I found another issue with kgen -1 mode especially concerned with I4/mmm symmetry. As previously mentioned, the '-1' mode of kgen generates uneven k divisions, as you rightly pointed out. However, I've observed potential issues with the weight of the uneven k mesh, particularly in the context of I4/mmm symmetry (and possibly other symmetries as well). This discrepancy appears to lead to inaccuracies in determining the Fermi energy. Here is how I benchmarked: 1. run_lapw -p till converge for CaFe2As2 and 10 10 10 shift kmesh. save_lapw -d scf 2. x kgen generate 9 9 9 non shifted mesh | x lapw1 -p; x lapw2 -p -fermi | get Ef=0.5076760931 3. x kgen generate 9 9 13 non shifted mesh | x lapw1 -p; x lapw2 -p -fermi | get Ef=0.5028504280 2. x kgen -fbz generate full 9 9 9 non shifted mesh | x lapw1 -p; x lapw2 -p -fermi | get Ef=0.5076760047 3. x kgen -fbz generate full 9 9 13 non shifted mesh | x lapw1 -p; x lapw2 -p -fermi | get Ef=0.5077417577 You can observe the significant difference in the Ef obtained from the 9 9 13 kmesh in the irreducible Brillouin zone (IBZ). However, the Ef calculated from the full Brillouin zone (FBZ) using the same mesh appears normal. Consequently, I suspect there may be an issue with the weight of k-points in the 9 9 13 mesh generated by your modified kgen. On the other hand, equal division kmesh 9 9 9 gives consistent Ef for both ibz and fbz. What is more, for 9 9 13 IBZ kmesh, when viewing fermi surface. xcrysden 1.6.2 gives error. xcrysden 1.5.60 gives completely wrong fermi surface. Please help, thank you very much! best regards -- Original -- *From:* "A Mailing list for WIEN2k users" ; *Date:* Mon, Mar 11, 2024 08:33 PM *To:* "wien"; *Subject:* Re: [Wien] Inconsistency in kgen Ups. Here it comes. Am 11.03.2024 um 13:26 schrieb balabi via Wien: > Dear Prof. Peter Blaha > > Thank you so much for your reply! But I can not find your attachment of > bravai.f.gz > > best regards > > > > > > -- Original -- > *From:* "A Mailing list for WIEN2k users" ; > *Date:* Mon, Mar 11, 2024 04:03 PM > *To:* "wien"; > *Subject:* Re: [Wien] Inconsistency in kgen > > Hi, > > Thank you very much for your report. I can confirm the problem. > > Both, for bct and bco lattices (body-centered tetragonal or > orthorhombic) kgen enforced in default modes equal divisions of the > reciprocal lattice vectors (as it should be for bcc). This was not a > good choice and the selection made by option "-1" (mesh density in > bohr^-1) is correct. > > I attach a modified bravai.f.gz file, which should be copied and > unziped in SRC_kgen, then recompiled (make; cp kgen ..). > > PS: The prevous setting was not a problem if your k-mesh is converged > (besides the larger computational effort), but may lead to extra > inaccuracy for non-converged meshes. > > Peter Blaha > > Am 10.03.2024 um 14:48 schrieb 巴拉比 via Wien: >> Dear wien2k developers and users, >> >> I am using wien2k 23.2 and working with CaFe2As2 structure which has >> I4/mmm symmetry. I am trying to generate klist using kgen. The kgen >> has several mode: >> >> the 1st mode is to specify k-mesh density >> >> /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for >> delta-K)/ >> /-1/ >> / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ >> / Specify density of k-mesh in bohr^-1:/ >> /0.2/ >> / Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)/ >> /0/ >> / 17 k-points generated, ndiv= 5 5 7/ >> / delta-K (bohr^-1): 0.1796
Re: [Wien] Verifying if the ghostbands still exists or not (no error received).
Did you get ghostband (QTL-B) errors or warnings ? Usually, if there are no errors nor warnings, it should be fine. HOWEVER: I saw in you case.in1 file: WFFIL EF=.43350132150076419604 (WFFIL, WFPRI, ENFIL, SUPWF) 8.00 3 4 ELPA pxq BL 64 (R-MT*K-MAX,MAX L IN WF,V-NMT,LIB) Why the hell did you set MaX L to 3 This is complete nonsense. Never touch the original value. Am 13.03.2024 um 14:49 schrieb Pranjal Nandi: Dear Community, Hello. I was getting ghostbands error (version 21.1), so I changed the energy levels as per the various past online threads and guidelines. After changing the energy levels, I DID NOT receive any errors and the calculations ran fine. However in the scf1, I see that in many cases E(TOP) = -200. In my calculations of other samples, when I changed the energy levels after getting ghostbands error, the E(TOP) value also changed. Hence, I am worried if the results in this case are reliable or not? How can I be sure that there are no ghostbands now (does no error = no ghostbands?) Requesting your kind guidance on the same. Regards, Pranjal Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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 Email: peter.bl...@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] Query regarding settings of Rmt*Kmax
Putting RKmax=5 is almost right. Actually you should even put it accurately to 2 digits after the comma. Am 11.03.2024 um 14:15 schrieb shamik chakrabarti: Dear Wien2k users, I am trying to calculate lithiation voltage of AB2 compound. For that I have two optimized structures of AB2 & LiAB2. Now, the minimum Rmt at AB2 is 1.8 & hence if I put Rmt*Kmax=7, it would give Kmax 3.89. Again, the minimum Rmt of Li in LiAB2 is 1.28. Hence, with Rmt*Kmax=7 this would give Kmax 5.46, a huge mismatch with AB2. However, if I put Rmt*Kmax=5 I will get comparative Kmax 3.91. Hence, my query, is it proper that I use Rmt*Kmax 7 for AB2 while use Rmt*Kmax 5 or LiAB2 for simulating lithiation voltage? Eagerly waiting for a response, with regards, -- Dr. Shamik Chakrabarti Research Fellow Department of Physics Indian Institute of Technology Patna Bihta-801103 Patna Bihar, India ___ 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 Email: peter.bl...@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] Inconsistency in kgen
Ups. Here it comes. Am 11.03.2024 um 13:26 schrieb balabi via Wien: Dear Prof. Peter Blaha Thank you so much for your reply! But I can not find your attachment of bravai.f.gz best regards -- Original -- *From:* "A Mailing list for WIEN2k users" ; *Date:* Mon, Mar 11, 2024 04:03 PM *To:* "wien"; *Subject:* Re: [Wien] Inconsistency in kgen Hi, Thank you very much for your report. I can confirm the problem. Both, for bct and bco lattices (body-centered tetragonal or orthorhombic) kgen enforced in default modes equal divisions of the reciprocal lattice vectors (as it should be for bcc). This was not a good choice and the selection made by option "-1" (mesh density in bohr^-1) is correct. I attach a modified bravai.f.gz file, which should be copied and unziped in SRC_kgen, then recompiled (make; cp kgen ..). PS: The prevous setting was not a problem if your k-mesh is converged (besides the larger computational effort), but may lead to extra inaccuracy for non-converged meshes. Peter Blaha Am 10.03.2024 um 14:48 schrieb 巴拉比 via Wien: Dear wien2k developers and users, I am using wien2k 23.2 and working with CaFe2As2 structure which has I4/mmm symmetry. I am trying to generate klist using kgen. The kgen has several mode: the 1st mode is to specify k-mesh density /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /-1/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Specify density of k-mesh in bohr^-1:/ /0.2/ / Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)/ /0/ / 17 k-points generated, ndiv= 5 5 7/ / delta-K (bohr^-1): 0.1796 0.1796 0.1719/ /KGEN ENDS/ /0.004u 0.016s 1:03.31 0.0% 0+0k 0+88io 0pf+0w/ As you can see, the ndiv=5 5 7 The 2nd mode is to specify number of k points /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /1000/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)/ /0/ / 102 k-points generated, ndiv= 10 10 10/ / delta-K (bohr^-1): 0.0898 0.0898 0.1203/ /KGEN ENDS/ /0.026u 0.003s 0:09.41 0.2% 0+0k 0+344io 0pf+0w/ as you can see unlike -1 mode, the ndiv=10 10 10 which is even. The 3rd mode is to specify ndiv explicitly, and here comes the problem /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /0/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Specify 3 mesh-divisions (n1,n2,n3):/ /5,5,7/ / Lattice symmetry requires equal mesh in x and z direction/ / Specify 3 mesh-divisions (n1,n2,n3):/ If I set ndiv as 5 5 7 as -1 mode. It just does not work. kgen insists equal mesh on x and z. So I must input even ndiv like 5 5 5. So the current issue is why the ndiv obtained with the -1 mode in kgen is not uniform for the CaFe2As2 system, whereas ndiv obtained with the k-point mode is uniform, and using the 0 mode, it's impossible to set non-uniform ndiv at all？ finally, I am attaching the struct file of CaFe2As2 as below /blebleble / /B LATTICE,NONEQUIV.ATOMS: 3 139 I4/mmm / / RELA / / 7.383336 7.383336 21.922849 90.00 90.00 90.00/ /ATOM -1: X=0. Y=0. Z=0./ / MULT= 1 ISPLIT=-2/ /Ca1 NPT= 781 R0=0.5000 RMT= 2.5 Z: 20.0 / /LOCAL ROT MATRIX: 1.000 0.000 0.000/ / 0.000 1.000 0.000/ / 0.000 0.000 1.000/ /ATOM -2: X=0.5000 Y=0. Z=0.2500/ / MULT= 2 ISPLIT=-2/ / -2: X=0. Y=0.5000 Z=0.2500/ /Fe1 NPT= 781 R0=0.5000 RMT= 2.28 Z: 26.0 / /LOCAL ROT MATRIX: 0.7071068-0.7071068 0.000/ / 0.7071068 0.7071068 0.000/ / 0.000 0.000 1.000/ /ATOM -3: X=0. Y=0. Z=0.63490625/ / MULT= 2 ISPLIT=-2/ / -3: X=0. Y=0. Z=0.36509375/ /As1 NPT= 781 R0=0.5000 RMT= 2.17 Z: 33.0 / /LOCAL ROT MATRIX: 1.000 0.000 0.000/ / 0.000 1.000 0.000/ / 0.000 0.000 1.000/ / 16 NUMBER OF SYMMETRY OPERATIONS/ / 1 0 0 0./ / 0 1 0 0./ / 0 0 1 0./ / 1/ /-1 0 0 0./ / 0-1 0 0./ / 0 0 1 0./ / 2/ / 0-1 0 0./ / 1 0 0 0./ / 0 0 1 0./ / 3/ / 0 1 0 0./ /-1 0 0 0./ / 0 0 1 0./ / 4/ /-1 0 0 0./ / 0 1 0 0./ / 0 0-1 0./ / 5/ / 1 0 0 0./ / 0-1 0 0./ / 0 0-1 0./ / 6/ / 0 1 0 0./ / 1 0 0 0./
Re: [Wien] Inconsistency in kgen
Hi, Thank you very much for your report. I can confirm the problem. Both, for bct and bco lattices (body-centered tetragonal or orthorhombic) kgen enforced in default modes equal divisions of the reciprocal lattice vectors (as it should be for bcc). This was not a good choice and the selection made by option "-1" (mesh density in bohr^-1) is correct. I attach a modified bravai.f.gz file, which should be copied and unziped in SRC_kgen, then recompiled (make; cp kgen ..). PS: The prevous setting was not a problem if your k-mesh is converged (besides the larger computational effort), but may lead to extra inaccuracy for non-converged meshes. Peter Blaha Am 10.03.2024 um 14:48 schrieb 巴拉比 via Wien: Dear wien2k developers and users, I am using wien2k 23.2 and working with CaFe2As2 structure which has I4/mmm symmetry. I am trying to generate klist using kgen. The kgen has several mode: the 1st mode is to specify k-mesh density /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /-1/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Specify density of k-mesh in bohr^-1:/ /0.2/ / Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)/ /0/ / 17 k-points generated, ndiv= 5 5 7/ / delta-K (bohr^-1): 0.1796 0.1796 0.1719/ /KGEN ENDS/ /0.004u 0.016s 1:03.31 0.0% 0+0k 0+88io 0pf+0w/ As you can see, the ndiv=5 5 7 The 2nd mode is to specify number of k points /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /1000/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)/ /0/ / 102 k-points generated, ndiv= 10 10 10/ / delta-K (bohr^-1): 0.0898 0.0898 0.1203/ /KGEN ENDS/ /0.026u 0.003s 0:09.41 0.2% 0+0k 0+344io 0pf+0w/ as you can see unlike -1 mode, the ndiv=10 10 10 which is even. The 3rd mode is to specify ndiv explicitly, and here comes the problem /NUMBER OF K-POINTS IN WHOLE CELL: (0 for 3 divisions of K, -1 for delta-K)/ /0/ / length of reciprocal lattice vectors (bohr^-1): 0.898 0.898 1.203/ / Specify 3 mesh-divisions (n1,n2,n3):/ /5,5,7/ / Lattice symmetry requires equal mesh in x and z direction/ / Specify 3 mesh-divisions (n1,n2,n3):/ If I set ndiv as 5 5 7 as -1 mode. It just does not work. kgen insists equal mesh on x and z. So I must input even ndiv like 5 5 5. So the current issue is why the ndiv obtained with the -1 mode in kgen is not uniform for the CaFe2As2 system, whereas ndiv obtained with the k-point mode is uniform, and using the 0 mode, it's impossible to set non-uniform ndiv at all？ finally, I am attaching the struct file of CaFe2As2 as below /blebleble / /B LATTICE,NONEQUIV.ATOMS: 3 139 I4/mmm / / RELA / / 7.383336 7.383336 21.922849 90.00 90.00 90.00/ /ATOM -1: X=0. Y=0. Z=0./ / MULT= 1 ISPLIT=-2/ /Ca1 NPT= 781 R0=0.5000 RMT= 2.5 Z: 20.0 / /LOCAL ROT MATRIX: 1.000 0.000 0.000/ / 0.000 1.000 0.000/ / 0.000 0.000 1.000/ /ATOM -2: X=0.5000 Y=0. Z=0.2500/ / MULT= 2 ISPLIT=-2/ / -2: X=0. Y=0.5000 Z=0.2500/ /Fe1 NPT= 781 R0=0.5000 RMT= 2.28 Z: 26.0 / /LOCAL ROT MATRIX: 0.7071068-0.7071068 0.000/ / 0.7071068 0.7071068 0.000/ / 0.000 0.000 1.000/ /ATOM -3: X=0. Y=0. Z=0.63490625/ / MULT= 2 ISPLIT=-2/ / -3: X=0. Y=0. Z=0.36509375/ /As1 NPT= 781 R0=0.5000 RMT= 2.17 Z: 33.0 / /LOCAL ROT MATRIX: 1.000 0.000 0.000/ / 0.000 1.000 0.000/ / 0.000 0.000 1.000/ / 16 NUMBER OF SYMMETRY OPERATIONS/ / 1 0 0 0./ / 0 1 0 0./ / 0 0 1 0./ / 1/ /-1 0 0 0./ / 0-1 0 0./ / 0 0 1 0./ / 2/ / 0-1 0 0./ / 1 0 0 0./ / 0 0 1 0./ / 3/ / 0 1 0 0./ /-1 0 0 0./ / 0 0 1 0./ / 4/ /-1 0 0 0./ / 0 1 0 0./ / 0 0-1 0./ / 5/ / 1 0 0 0./ / 0-1 0 0./ / 0 0-1 0./ / 6/ / 0 1 0 0./ / 1 0 0 0./ / 0 0-1 0./ / 7/ / 0-1 0 0./ /-1 0 0 0./ / 0 0-1 0./ / 8/ /-1 0 0 0./ / 0-1 0 0./ / 0 0-1 0./ / 9/ / 1 0 0 0./ / 0 1 0 0./ / 0 0-1 0./ / 10/ / 0 1 0 0./ /-1 0 0 0./ / 0 0-1 0./ / 11/ / 0-1 0 0./ / 1 0 0 0./ / 0 0-1 0./ / 12/ / 1 0 0 0./ / 0-1 0 0./ / 0 0 1 0./ / 13/ /-1 0 0 0.000
Re: [Wien] ABNiO_4
third place close to the plane. Or the atom tends to enter the carbon plane? What is distance between the planes? Where is the starting position of the added atom? I'd start from usual calculation, without nlvdw. And then repeat with nlvdw. Best wishes Lyudmila Dobysheva -- http://ftiudm.ru/content/view/25/103/lang,english/ <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 <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 <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 -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Requesting your help in "running qtl in parallel mode"
I can only suggest to update to the latest version. Am 10.03.2024 um 14:11 schrieb Pranjal Nandi: Dear WIEN2K Community, It would be helpful if someone could please help me with the following as I am using up too much time in doing serial calculation as the TELNES is not working in parallel mode. In serial mode, everything is working fine. In parallel mode, SCF runs well, Optic package runs well (version 21.1). But when I run x qtl -p -telnes (from w2web), I get the following error running QTL in parallel mode calculating QTL's from parallel vectors so: Undefined variable. 0.035u 0.043s 0:00.09 77.7% 0+0k 0+24io 0pf+0w error: command /home/WIEN2k/WIEN2k/qtlpara qtl.def failed I checked the forum too and found the following suitable threads. Looks like everything is fine with my files (maybe something I am unable to spot) http://zeus.theochem.tuwien.ac.at/pipermail/wien/2021-May/031757.html (the thread looks incomplete) https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21125.html (I should check set so in the qtlpara_lapw and also run x lapw2 -fermi (-p)? I am asking because I use the w2web and in that there is no x lapw2 -fermi (-p) in the TELNES pack, there is one in Optics, which once I tried first and then ran TELNES but the same error happened) https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20660.html (vec2old_lapw -p -local $so -$updn is already mentioned in the qtlpara_lapw file in the root folder) I have attached some of the relevant files. Please let me know if you need more information. It would be helpful if you could kindly guide me on the right track. Thank you and with regards, Pranjal Nandi Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir informació confidencial o protegida legalment i s’adreça exclusivament a la persona o entitat destinatària. Si no consteu com a destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant el missatge com els fitxers adjunts que hi pugui haver. Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener información confidencial o legalmente protegida y está exclusivamente dirigido a la persona o entidad destinataria. Si usted no consta como destinatario final ni es la persona encargada de recibirlo, no está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a revelar su contenido. Si lo ha recibido por error, informe de ello al remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos que pueda contener. This email message and any attachments it carries may contain confidential or legally protected material and are intended solely for the individual or organization to whom they are addressed. If you are not the intended recipient of this message or the person responsible for processing it, then you are not authorized to read, save, modify, send, copy or disclose any part of it. If you have received the message by mistake, please inform the sender of this and eliminate the message and any attachments it carries from your account. ___ 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] wien2k workshop
Dear wien2k users, This is some information about our wien2k workshop in April in Trieste, in particular to those of you who were rejected. For this workshop we had money for 20 supported participants from 3rd world countries and because of the computer infrastructure a limit of 50 total participants. However we had almost 350 applications in total, many of them asking for support. It was therefore a tough decision how to select the participants and I apologize to all of you, who were rejected. It was simply impossible to accept (and fund) all applications, ad we had to consider the references, poster presentation, scientific experience, but also gender and diversity of nationality. I'm looking forward to see those of you who were selected in Trieste and hope the others understand the difficulty and are not too depressed. Best regards Peter Blaha -- --- 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
Re: [Wien] Error in optimization
The "NN-error" is pretty clear. You have overlapping spheres, either because you did not reduce the spheres at all, or not enough for the big 10% coa reduction. If you have use some RMT-reduction during setup, you may try to rerun x optimized (or 2Doptimize ?) and use a smaller change, eg. of max 6%. If this does not work, the fix this is a bit tricky, so my recommendation is to make make a new directory and copy the *vol___0.0.struct file (not the present case.struct) into this directory and rename it. Please check the lattice parameters in the struct file that you got the proper starting setup. Then use setrmt with a larger reduction. Am 04.03.2024 um 19:00 schrieb Neetu Malik: Dears, During volume optimization getting below error. Please help me to resolve this issue. ERROR status in Sr2CoWO6_coa__-10.00 > stop error grep: lapw2*.error: No such file or directory grep: lapw2*.error: No such file or directory grep: lapw2*.error: No such file or directory grep: lapw2*.error: No such file or directory grep: lapw2*.error: No such file or directory grep: lapw2*.error: No such file or directory NN - Error LAPW0 END clmextrapol_lapw has generated a new Sr2CoWO6.clmsum 0.043u 0.000s 0:00.04 100.0%0+0k 0+2960io 0pf+0w 1.105u 0.007s 0:00.32 343.7%0+0k 0+2976io 0pf+0w DSTART ENDS C T F running dstart in single mode 1.100u 0.022s 0:00.34 329.4%0+0k 0+2984io 0pf+0w DSTART ENDS C T F running dstart in single mode ___ 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
Re: [Wien] Unable to see Li K edges in ELOSS file. Kindly guide.
I analysed your problem. It has nothing to do with WIEN2k, but is much
more fundamental.
A Li-K edge is per se not a "real edge". It's energy is so low, that it
may overlap with many other excitations, they could be from Fe-3p (or
from other shallow core levels ), but of course also from excitations
from all other valence states into the conduction band.
You can analyse the different contributions to case.joint nicely, by
playing with the band-indices. Download the 4 images
http:www.wien2k.at/Depository/LiFePO4.joint-total.png
http:www.wien2k.at/Depository/LiFePO4.joint-without-Fe-3p.png
http:www.wien2k.at/Depository/LiFePO4.joint-without-Fe-3p-zoom.png
http:www.wien2k.at/Depository/Li-K-edge.png from
They show case.joint ( unbroadened eps_xx) with the following band
ranges in case.injoint (1st line):
1 : LOWER,UPPER and (optional) UPPER-VAL
BANDINDEX (total eps_xx)
13 : LOWER,UPPER and (optional) UPPER-VAL
BANDINDEX (eps_xx without Fe-3p statesI
13 16 : LOWER,UPPER and (optional) UPPER-VAL
BANDINDEX (eps_xx only from Li-1s
The Li-1s plot (Li-K-edge) starts as expected only at about 50 eV and
its shape follows closely the Li-2p DOS (not shown), since the Li-1s
bands are really flat (around -2.9 Ry) and "JDOS = DOS". Please look at
the small y-scale (Note, such a selective absorption is not
possible experimentally)
The total eps-xx is very large at low energy, and around 53 eV a sharp
peak appears .
However, when you cut-off the Fe-3p states (first 12 bands) this peak
is gone, which identifies it as the Fe-3p ("Fe-M--2,3 edge", not the
usual Fe-L-2,3 edge) contribution. Only a very shallow structure can be
seen and when you zoom in, the Li-1s absorption is visible, but only a
"part of the eps2".
Am 01.03.2024 um 21:50 schrieb Pranjal Nandi:
Dear Peter,
Thanks for the reply. I would like to clarify some misunderstandings.
There are two files for which I am doing the simulation, they are for LiFePo4
and LiTi2(PO4)3. (Note the addition of Ti in the second sample)
The image I had shared was from Optics. I am discussing both the results below.
For the optics results.
- For LiFePO4, I do not see any Li edge structure.
- For LiTi2(PO4)3, I do not see any Li edge structure. What I see is a
new peak compared to LiFePO4 at around 35 eV whose shape is very close to the
shape of Ti and not of Li.
--
------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@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] Unable to see Li K edges in ELOSS file. Kindly guide.
13. Once the scf is converged, I do the following for the ELOSS 14. Edit .in1 file put the value of MAX L IN WF to 10 and set nbans to 200 15. x kgen 16. x lapw 1 -p 17. x lapw2 -fermi – p 18. Edit .inop file (set Emax for matrix elements = 10) Probably nonsense. More important is Emin (-5.0), but probably the Li-1s eigenvalue is anyway at higher energy). 19. x optic -p 20. Edit .injoint file (emax set at 10.00) 21. x joint 22. x kram (with the default values in .inkram) 23. Then I plot the eloss files. So the plot was from optics, not from telnes3 ? I saw a peak near 55 eV in that plot. This corresponds probably to the Li 1s--2p transition. Why do yu say you do not see anything at 55 eV ? Note, that absolute DFT energies are wrong, so the position of this peak will usually not coincide with experiment. As I said before, the shape is important. For the TELNES3 24. Edit .innes file (choose the atom as Li, edge K, n=1, l=0, edge onset 55 ev, energy grid 0 – 100 eV in steps of 0.05 eV, rest I leave it at their default values ) 25. .in1, same as step no 7 26. x lapw1 27. x telnes3 28. x broadening 29. Plot and save What do you see there ?? The image which you saw in larger mail, the extra peaks are due to Ti in one of them. But no Li signature is found. Was the image from optics or telnes3 ? 2. Even when I do the Telness of Li , I only get the details till 15 eV (55+15). I would like to have it for more range from 55-100 eV for example. I want to get a proper Li edge As I said before, you don't get absolute positions in Telnes. You can consider the 0 eV in the plot as 55 eV for the spectrum. So you need only the 15 eV or so. -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Unable to see Li K edges in ELOSS file. Kindly guide.
You have to tell us exactly the steps you did to get the eloss spectra.
What do you mean by that ?
However, despite multiple variations and calculations, I am unable to
see the K edge of Li (55 eV) in any of them. Could you kindly suggest
if there is something I need to do (read something about core hole
excitation but have no knowledge how to do it or if it is needed in
this case).
In one of your larger mails, I could see a plot and also a significant
difference between the 2 compounds, so why don't you see the Li K-edge
??? (EELS and XAS calculations do not yield the absolute position of the
edge (55 eV), but the shape and intensity of the near-edge region. The
plot starts at zero (which is set to your EF). Compare the shapes !
Yes, in insulating cases you should use a supercell with a core hole.
This is a bit tricky for Li, since the 1s state is treated as valence.
It can be done with a 2-window ("semicore") calculation. If I remember
correctly, I described this some time ago in the mailing list (search it).
PS: Read some wien2k papers with ELOSS spectra (even the UG has some
references ...; lecture notes from previous workshops, ...
--
-------
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
Re: [Wien] How to assign kz to slab bands?
Yes, I know. But usually the model is to make a supercell (without vacuum) and put some impurity into it. Then you can fold the supercell back becaus it is a multiple of the small unit cell, and find bulk and impurity bands. In your case, you don't have just a supercell, but a supercell + vacuum. Thus c' is not just 3 x c (for a cell with 3 unitcells in c direction), but vacuum has been added. I don't know if backfolding would work in this case, maybe you can use the trick I mentioned last time. Am 25.02.2024 um 12:45 schrieb pluto via Wien: Dear Prof. Blaha, Thank you for the comment. fold2Bloch might be exactly what I need! There are papers where it is mentioned in relation to ARPES. Best, Lukasz On 2024-02-24 16:05, Peter Blaha wrote: Hi, There is no automatic tool for this. I detected surface states by an analysis of the partial charges of the atoms in the various layers. A surface state should have charge only in the surface (maybe a bit in the subsurface layer). Note, there is fold2bloch, which does backfolding of supercells, but I don't know what to do with the vacuum. One could try to give him a supercell in z direction without vacuum and still use the eigenvectors from the supercell+vacuum calculation, but it may give complete nonsense. Best regards Peter Blaha Am 23.02.2024 um 17:02 schrieb pluto via Wien: Dear All, Everyone who has done a slab calculation knows that it contains some surface states and some projected bulk bands. These projected bulk bands are typically nearly identical to the bulk projected bands. If we have a 10ML slab, they will essentially look like cutting the bulk BZ 10 times along kz. In case of bulk bands obviously each cut is assigned to some kz. Now, we can compare bulk projected bands and slab bands, and then we will more or less know which of the slab bands relate to which kz (besides the surface states that don't have kz). Is there a simple way to automatically assign kz to the slab bands? One solution to this problem would be to calculate something like , which is essentially a Fourier transform of the initial wave function for some energy and k_paral, i.e. for one eigenvalue point in the band structure. Is that kind of matrix element hidden somewhere in the WIEN2k output files? Actually, this would also assign kz to the surface states, which could also be useful in the photoemission context. Best, Lukasz ___ 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 -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] How to assign kz to slab bands?
Hi, There is no automatic tool for this. I detected surface states by an analysis of the partial charges of the atoms in the various layers. A surface state should have charge only in the surface (maybe a bit in the subsurface layer). Note, there is fold2bloch, which does backfolding of supercells, but I don't know what to do with the vacuum. One could try to give him a supercell in z direction without vacuum and still use the eigenvectors from the supercell+vacuum calculation, but it may give complete nonsense. Best regards Peter Blaha Am 23.02.2024 um 17:02 schrieb pluto via Wien: Dear All, Everyone who has done a slab calculation knows that it contains some surface states and some projected bulk bands. These projected bulk bands are typically nearly identical to the bulk projected bands. If we have a 10ML slab, they will essentially look like cutting the bulk BZ 10 times along kz. In case of bulk bands obviously each cut is assigned to some kz. Now, we can compare bulk projected bands and slab bands, and then we will more or less know which of the slab bands relate to which kz (besides the surface states that don't have kz). Is there a simple way to automatically assign kz to the slab bands? One solution to this problem would be to calculate something like , which is essentially a Fourier transform of the initial wave function for some energy and k_paral, i.e. for one eigenvalue point in the band structure. Is that kind of matrix element hidden somewhere in the WIEN2k output files? Actually, this would also assign kz to the surface states, which could also be useful in the photoemission context. Best, Lukasz ___ 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 Email: peter.bl...@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] Wannier
Hi, Yes, for sure you can forget the "Blm" and most important are the "Alm". There are 2 problems: You may have some "Clm" (local orbitals), which could be dominating ! While this is probably less important for real "semicore states" as you may not use them for PES, it might be important for something like C or O s states or Ti-4s,4p valence states. The problems can be avoided when modifying case.in1 and removing the local orbitals for the atoms with low valence states like O-2s, ; and for the atoms with semicore states, put the 4s as APW and the 3s as LO (2nd line in case.in1). The more critical problem is that the ALMs give you only the amplitude and phase INSIDE the atomic sphere. Checkout case.outputst, and you will see how much l-like charge of a particular atom is within the atomic sphere. For instance for Ti (RMT=2.25) 3D* -0.355365 -0.246227 2.00 0.00 0.8136 F 4S -0.342909 -0.306636 1.00 1.00 0.1495 F ++ it means that 81 % of the 3d charge is inside the sphere, but only 15% of 4s charge. This has the consequence that a pure 3d state might have a "alm=sqrt(0.8)", but a PURE 4s state has only alm=sqrt(0.15). This is the reason, why we introduced the "renormalized partial DOS", where the interstital DOS is removed and the 3d PDOS will be slightly, the 4s PDOS strongly enhanced. You should probably use a similar concept and use the renormalization factors given in the output of a rendos calculation. Regards Peter Blaha Am 16.02.2024 um 23:28 schrieb pluto: Dear Oleg, Mikhail, dear Prof. Blaha, Thank you for the quick answers! It seems that the Alm (related to the "u") coefficient might be what I need, because it refers to the "atomic-like" potential. Perhaps the Blm coefficient, related to the "u-dot", is "small" in most cases, also maybe it somehow represents the non-atomic (i.e. non-LCAO) correction to the electronic state inside the MT sphere? I apologize if calling "u" of LAPW as being "atomic" is wrong, but maybe it is not totally wrong in the spirit of my problem. I am fine with approximate numbers here, everything in the order of 80%-90% (say referring to the final ARPES intensity) would be fine, I think. (The Alm of different atoms would just control the amplitude and phase interference of the spherical waves photoemitted from these atoms.) Does that way of thinking make some sense? Perhaps it is also the case, that a very large LCAO basis can explain any band structure, but I think this is not the point, here the goal is to simplify the problem. In this physical problem, I cannot live without the complex coefficients. This is easily understood in graphene, where the "dark corridor" of ARPES results from the k-dependent phases of the wave-functions on sites A and B. Best, Lukasz On 2024-02-15 08:40, Peter Blaha wrote: Hi, I do not know too much about Wannerization and LCAO models. However, I'd like to mention the PES program, which is included in WIEN2k. It uses the atomic cross sections (as you mentioned), but not the wavefunctions, but the "renormalized" partial DOS. (This will omitt the interstital and renormalize in particular the delocalized orbitals). It does NOT include phases (interference), but our experience is quite good - although limited. Check out the PES section in the UG and the corresponding paper by Bagheri Regards Am 15.02.2024 um 01:41 schrieb 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 t
Re: [Wien] Wannier
Hi, I do not know too much about Wannerization and LCAO models. However, I'd like to mention the PES program, which is included in WIEN2k. It uses the atomic cross sections (as you mentioned), but not the wavefunctions, but the "renormalized" partial DOS. (This will omitt the interstital and renormalize in particular the delocalized orbitals). It does NOT include phases (interference), but our experience is quite good - although limited. Check out the PES section in the UG and the corresponding paper by Bagheri Regards Am 15.02.2024 um 01:41 schrieb 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 -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Few questions about onsite hybrids and so
ece (that seemed straightforward) but than I thought I should also fix case.in2eece. Reading UG gives the impression that case.in2eece is normal case.in2 with extra EECE on the first line and than the optional 3a and 3b lines. In the case.in2eece created automatically with init_orb_lapw - eece the 3a and 3b lines looked like: 1 1 1 3 However reading UG this actually seems wrong? Because UG says (Section 7.9 page 166) the format for optional 3b is just two values: jatom rho, l rho so I wonder if the UG is wrong or if I'm actually applying the hybrid correction to p instead of f? This is an error in the UG. You would see it quickly, if you correct p states instead of f. PS: The only important input file is case.ineece (and maybe case.in0eece_lda). The runeece script (and not init_orb) generates the other *in*eece files on the fly in every iteration. Also, is there anything else I should fix manually after intializing the so on top of eece? Or should I do it the other way around (first so and then eece)? The reasoning for doing first eece was that I get a metal with plain PBE and an insulator with the onsite hybrid, so I thought it might be easier to converge if I start so from insulator (but I still use TEMP smearing just to be sure I don't end with convergence problems if I get a metal during the convergence as the expected unoccupied occupied f-f distance is very small.) I was also considering mBJ later, just to get some feeling how the conduction bad would shift but I'm not sure if this would work or not on top of eece and so? One last question is regarding the forces. From reading the UG I understood that it should be OK to relax the oxygen positions with onsite hybrid and so (as long as I don't have so or eece enabled for O atoms). Is this correct? So will just switching to MSR1a and running normal runsp -so -eece work or are some other fixes needed? Best regards Pavel ___ 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 Email: peter.bl...@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] DOS with Spin-orbit coupling
Hi, I guess you mean lapwso when you typed palwso. when you run x lapwso -h you can see all possible allowed switches. -dn is not allowed. In a magnetic case lapwso couples (mixes) spin-up and dn, so both spins are always considered. A "better" switch would be -sp, just indicating spinpolarization, but we opted for -up to indicate that the system in spinpolarized and when you look into lapwso.def you will see both, vspup and dn is listed. When you run x lapwso -dn the script neglects -dn and uses case.vsp (i.e. a non-spinpolarized potential), which does not exist in a spinpolarized calculation. So there is no error (in the program). Am 07.02.2024 um 11:16 schrieb susanta mohanta: Dear Prof Blaha and wien2k users. I am facing a problem while plotting dos with so. For up spin, all the commands are running but for dn spin x palwso -dn I am getting an error like ERROR IN OPENING UNIT: 18 FILENAME: CeMg_3.vsp STATUS: old FORM:formatted OPEN FAILED 0.008u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w N.B: For dn spin all the steps are also not visible in interactive mode. I am using wien2k 23.1 version. In older versions, this problem was not there. I have checked the .vsp files and present for both spins. Any help in this regards would be appreciated. with regards Susanta *Dr. Susanta Kumar Mohanta* Assistant Professor in Physics Dept. of Basic Sciences Government College ofEngineering Kalahandi, Bhwanipatna-766002, Odish 7328025509, 8249969717 ___ 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
Re: [Wien] Sub: Regarding determination of optical constants and their plotting by using wien2k
The sequence below seems ok except that you missed/added some blanks (maybe just. In particular adjoint -updn lapw It should be: addjoint-updn or adjoint-updn_lapw (no blank and a "_" before lapw) --- x kram produces a couple of files (cat kram.def to get the names). They contain the energy and corresponding optical constants in a readable form. These files also have some header, explaining the different columns. Look into them !!! The opticplot utility is just a first simple interface for plotting them. You can plot the data with any x-y plotting program. In Linux the "hardcore program" would be gnuplot or xmgrace or ..., but also under Windows in Excel if you like this more. Just transfer the files to windows and import them into an excel sheet. I am using WIEN2k version 2019 for evaluation of all optical constants of orthorhombic V2O5 and obtain plots for photon frequency/energy dependence of these quantities with legends on both axes and plot titles and obtaining plots for different polarisations viz. xx, yy, zz on the same plot for various quantities, viz, epsilon1 , epsilon2, real and imaginary parts of optical conductivity, absorbable, reflactance, refractive index, extinction coefficient, loss function etc. However, after running scf for spin polarized case for V2O5 orthorhombic case, when I run optic task and do steps as follows: edit test.in1 xkgen xlapw1 -up xlapw1 -dn xlapw2 -fermi -up edit test.inop (selecting for 3 columns xx, yy and zz) x optic -up edit test. injoint (choosing 3columns and switch 4 as V2O5 is semiconductor) x joint -up view test.output -joint up Then after repeating above steps for dn spin adjoint -updn lapw edit test.inkram ( choosing 0 for ignoring intraband transitions for semiconductor) x kram optic plot when I plot the quantities calculated, I obtain 6 columns for epsilon giving 3 plots for epsilon1 and 3 plots for epsilon2 for polarisations xx, yy and zz, but we obtain separate 6 plots and those too without any legends on y axis and heading/title of the plots. How 3 plots of epsilon1 for polarisations xx, yy and zz can be obtained on same graph with relevant legends on y axis and heading/title of the plot? and Similarly for epsilon2? are not known to me. Can any of the esteemed users or Wien administrators can help me to resolve this problem? We also obtain data in 6 columns for sigmak, which appears to be relevant for optical conductivity. From this we obtain 6 plots, 3 for real part and 3 for imaginary part, without any legend on y axis and heading/title of the plots. How we can obtain 2plots one for real part and other for imaginary part for 3polarizations xx, yy and zz and with legends on y axis and heading/title of the plots? We also obtain 3 column data for eloss, giving us 3 plots for xx, yy and zz polarisations, without any legend on y axis and no title/heading of the plots. Can we obtain 3 plots on same graph with proper legend on y axis and title of the plot? 6 columns data for joint giving 6 plots and 6 column data for sum total is also obtained, giving 6 plots in each case, but looking to values on y axis, it is not becoming possible to interpret the same. No data. or plots are obtained for refractive index, extinction coefficient, absorption coefficient, reflectivity of the material. If possible, Kindly let me know how it can be done. Thanking you in advance. Yours Sincerely Dr. K. S. Sharma Professor IIS Deemed to be University Jaipur (India) ___ 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
Re: [Wien] NbNiO3 antiferromagnetic
Hi, I can confirm the problem. It is funny that this has never been reported before. The reason for the crash is that the program orb requires the atoms sorted in ascending order. The init_orb script gives: 1 4 0nmod, natorb, ipt PRATT 1.0 1 1 3 index of atom, number of l, l 8 1 3 index of atom, number of l, l 2 1 2 index of atom, number of l, l 3 1 2 index of atom, number of l, l ... but in order to work properly it should be 1 4 0nmod, natorb, ipt PRATT 1.0 1 1 3 index of atom, number of l, l 2 1 2 index of atom, number of l, l 3 1 2 index of atom, number of l, l 8 1 3 index of atom, number of l, l ... Edit case.indm and inorb and sort the atoms properly (don't forget also to sort the U values). PS: rm *.dmat* *.vorb* Regards Am 03.02.2024 um 03:31 schrieb delamora: Dear WIEN2k users; I am calculating NdNiO3 I did a ferromagnetic calculation without any problems. I wanted to calculate the antiferromagnetic case, so I splited the 4 Nd positions into 2 up and 2 dn, and when I ran the system, I had a problem; In the second cycle, when the 'orb -up' was executed, the system stopped, and I found that NdNiO3.vorbup contained only 1 line, when it should have many lines. Any suggestion? Pablo ___ 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 Email: peter.bl...@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] WIEN2k fails to run: "TiC.clmsum no such file"
Hi, As I said, we need more information. Execute in a terminal window: which dstart Does it find the dstart executable ? If no, the error is in the compilation. Goto $WIENROOT/SRC_dstart and check compile.msg for errors. If yes, execute in the TiC directory x dstart Does it run or do you get some error message ? Regards Am 31.01.2024 um 21:55 schrieb Douglas Barlow via Wien: All: As I mentioned yesterday, we recently purchased a license to WIEN2k and after downloading and compiling we are not able to run the first example in the book. We get the error cp: cannot stat "TiC.clmsum" No such file or directory. Since we are unfamiliar with this code, we do not know where or how this error has occurred. I have searched through other comments on this site and do not find any solution there. Any help would be appreciated. Doug Barlow Dept. of Physics The University of the South Sewanee, TN USA ___ 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 Email: peter.bl...@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] .clmsum file question
Not much information. TiC.clmsum should have been created in the dstart step of the initialization. Are you sure the compilation (siteconfig) worked properly without errors at the end ? A typical problem would be an error with the fftw libraries. Can you run in a terminal in the TiC directory: x dstart ??? Am 30.01.2024 um 20:53 schrieb Douglas Barlow via Wien: Hello, I recently installed and compiled WIEN2k 23.2 for Linux , Ubuntu. I am trying to run the example "TiC" from the WIEN2k book using w2web. I go through the outlined steps but SCF calculations fail. The SCF calculation fails with the error: cp: cannot stat 'TiC.clmsum' No such file or directory. Thanks for any help. Doug Barlow ___ 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 Email: peter.bl...@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] Empty orbital band character in case.qtl
With spin-orbit coupling you have 2D degenerate eigenstates. This means you have 2 solutions with the same eigenvalue and as you may recall, any linear combination of 2 such solutions are again a solution. Thus the eigensolver forms 2 "arbitrary" wavefunctions, only obeying the above mentioned constrain. You can see that for the first pair you have charges on the second atom of 0 and 0.548; while for the second pair you have 0.249 and 0.299. Thus in each of the degenerate states you have about 0.55 electrons. Everything is ok and only the SUM of these 2 contributions makes sense ! I performed the initialization ( Ecut= -6.0, rkmax=7.0,lvns=8, vxc=13 and a 9 9 1 kmesh) without warnings. Then, I ran the scf calculation first without SOC (run_lapw -ec 0.1 -cc 0.0001 -p) and then with SOC (run_lapw -ec 0.1 -cc 0.0001 -p -so), the convergence was achieved and no warnings were presented in the case.scf file. The valence (77 & 78) and conduction (79 & 80) bands present a double degeneracy at this k-point. For calculating the orbital projection I ran the command 'x lapw2 -p -so -qtl', resulting in the case.qtl file. For the interpretation, as I am interested in the (0 0 0) point which corresponds to the first line of the case.klist file, I extracted the first block for the bands in question (attaching header as well): ---> LATTICE CONST.= 7.7606 7.7606 72.1324 FERMI ENERGY= -0.12049 1 < NMAT < 2291 SPIN=1 NAT= 3 SO 2 JATOM 1 MULT= 2 ISPLIT= 4 tot,0,1,PZ,PX+PY,2,DZ2,DX2Y2+DXY,DXZ+DYZ,3 JATOM 2 MULT= 2 ISPLIT= 4 tot,0,1,PZ,PX+PY,2,DZ2,DX2Y2+DXY,DXZ+DYZ,3 JATOM 3 MULT= 2 ISPLIT= 4 tot,0,1,PZ,PX+PY,2,DZ2,DX2Y2+DXY,DXZ+DYZ,3 BAND 77 -0.15197 1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -0.15197 2 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -0.15197 3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -0.15197 4 0.9 BAND 78 -0.15197 1 0.00889 0.0 0.00146 0.0 0.00146 0.00279 0.0 0.00075 0.00204 0.00015 -0.15197 2 0.54843 0.0 0.25833 0.0 0.25833 0.01476 0.0 0.01260 0.00216 0.00100 -0.15197 3 0.02904 0.0 0.01444 0.0 0.01444 0.5 0.0 0.3 0.2 0.2 -0.15197 4 0.41364 BAND 79 -0.08923 1 0.00454 0.00124 0.00082 0.00070 0.00012 0.2 0.0 0.1 0.0 0.00019 -0.08923 2 0.24891 0.09282 0.02634 0.02625 0.9 0.00404 0.00403 0.1 0.0 0.00121 -0.08923 3 0.02288 0.00175 0.00960 0.00939 0.00021 0.8 0.6 0.1 0.1 0.1 -0.08923 4 0.72367 BAND 80 -0.08923 1 0.00535 0.00149 0.00094 0.00084 0.00010 0.1 0.0 0.1 0.0 0.00022 -0.08923 2 0.29867 0.11140 0.03158 0.03150 0.8 0.00484 0.00484 0.1 0.0 0.00146 -0.08923 3 0.02729 0.00211 0.01144 0.01127 0.00017 0.9 0.8 0.1 0.1 0.1 -0.08923 4 0.66869 < The unexpected behaviour encountered and the reason for this inquiry concerns the band 77, which presents a practically 0 orbital character. Could this be a numerical error or should this be physically interpreted? Thank you in advance for your time and help. ___ 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 Email: peter.bl...@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] strange(?) LOPW - Error
I crosschecked lopw.f again. It has a remark about an "experimental check", that not only the Overlap matrix elements including phase factors are orthogonal, but already the K-vectors are not linear dependent. The latter is a much faster check, but maybe too restrictive. When I remove this additional check, it runs through and the eigenvalues look reasonable (and for k-vectors which run through, the eigenvalues are identical (although the K attachments are different). You may want to test this version. Regards Peter Am 28.01.2024 um 12:20 schrieb Fecher, Gerhard: -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at - SUBROUTINE LOPW(NAT) ! use matrices, only: HSROWS, KZZ, XK, YK, ZK use lolog, only : nlo, ilo use lstapw, only : NV use rotmat, only: ROTIJ, ROTLOC use struk, only : POS, MULT, NDF use parallel, only: myid,abort_parallel IMPLICIT NONE INCLUDE 'param.inc' ! !Scalar Arguments ! INTEGERNAT ! ! .. ! !generates the LAPW (K+G)-vector for local orbitals ! ! .. ! !Locals ! INTEGERIA1, IEQ, IIX, INDEX, J, K, KOFF, L, LM, LMDN INTEGERLMUP, LMX, N, NATX, NATXX, NB, NBM INTEGERJLO,ipass DOUBLE PRECISION HL, RKGM, SX, TPI, check DOUBLE PRECISION ROTV1(3), ROTV2(3), VEC(3) COMPLEX*16 CC ! COMPLEX*16 HH((LOMAX+1)**2*NDF,(LOMAX+1)**2*NDF) COMPLEX*16 HH((2*LOMAX+1)*48,(2*LOMAX+1)*48) COMPLEX*16 SF(NDF), YL(0:(LOMAX+1)**2) !,nv:HSROWS) ! !External Subroutines ! EXTERNAL ROTATE, YLM ! !Intrinsic Functions ! INTRINSIC ATAN, DCMPLX, DCONJG, EXP, SQRT ! ! ** Maybe Experiment ** DOUBLE PRECISION VEC2(3), TMP1, TMP2 ! TPI = 8.0D+0*ATAN(1.0D+0) ! check=2.0D-2 ipass=0 1continue check=check/2.d0 KOFF = NV IA1 = 0 DO 140 N = 1, NAT DO 130 L = 0, LOMAX !IF (LOOR(L,N)) THEN do jlo=1,ilo(l,n) LMDN = L*L + 1 LMUP = (L+1)*(L+1) INDEX = 0 NB = 0 NBM = MULT(N)*(1+LMUP-LMDN) DO 120 IEQ = 1, MULT(N) DO 110 LM = LMDN, LMUP NB = NB + 1 K = KOFF + NB 10CONTINUE INDEX = INDEX + 1 IF (INDEX .GT. NV) GOTO 900 ! WRITE (6,*) 'INDEX,K,N,L,IEQ,LM',INDEX,K,N,L,IEQ,LM KZZ(1,K) = KZZ(1,INDEX) KZZ(2,K) = KZZ(2,INDEX) KZZ(3,K) = KZZ(3,INDEX) XK(K) = XK(INDEX) YK(K) = YK(INDEX) ZK(K) = ZK(INDEX) RKGM = SQRT(XK(K)*XK(K)+YK(K)*YK(K)+ZK(K)*ZK(K)) IF (NBM .NE. 1) THEN DO 20 NATX = 1, MULT(N) NATXX = IA1 + NATX SX = KZZ(1,K)*POS(1,NATXX) + & KZZ(2,K)*POS(2,NATXX) + & KZZ(3,K)*POS(3,NATXX) ! SF(NATX) = EXP(DCMPLX(0.0D+0,TPI*SX)) SF(NATX) = DCMPLX(DCOS(TPI*SX),DSIN(TPI*SX)) 20 CONTINUE IIX = 0 DO 50 NATX = 1, MULT(N) IF (RKGM .LE. 1.0D-5) THEN DO 30 LMX = LMDN, LMUP !YL(LMX-1,K) = (0.0D+0,0.0D+0) YL(LMX-1) = 0.0D0 30 CONTINUE ! YL(0,K) = (1.0D+0,0.0D+0) YL(0) = 1.D0 ELSE VEC(1) = XK(K) VEC(2) = YK(K) VEC(3) = ZK(K) CALL ROTATE(VEC,ROTIJ(1,1,IA1+NATX),ROTV1) CALL ROTATE(ROTV1,ROTLOC(1,1,N),ROTV2) CALL YLM(ROTV2,LOMAX,YL(0)) !,K)) ENDIF DO 40 LMX = LMDN, LMUP IIX = IIX + 1 HH(IIX,NB) = SF(NATX)*YL(LMX-1) !,K) 40 CONTINUE 50 CONTINUE IF (NB .NE. 1) THEN DO 80 J = 1, NB - 1
Re: [Wien] strange(?) LOPW - Error
Dear Gerhard, This is (at least for me) a well known behavior. We attach to each local orbital a fictitious plane wave with a k-vector K. In addition we require that LOs are orthogonal to each other and this requirement becomes a problem if you have many equivalent atoms (8 Ga in your case) and high l=2 (makes 5 d-LOs per atom) and a small RKmax, because then we run out of K vectors. Maybe we are doing the orthogonality check too stupid and could reduce the requirements when running over equivalent atoms, but I've never tested this in details. In your case, a quick test seems to run through when RKmax = 7.5 or bigger. Alternatively, you may want to split the 8 Ga in 4+4 , but in such a way that more symmetry survives and not just in P1. Peter Am 28.01.2024 um 12:20 schrieb Fecher, Gerhard: Hallo Peter, I observed some unexpected (maybe strange) behaviour of lapw1 (Wien2k Version 23.2 compiled with OneAPI 23.1) I wanted to test if there is a ferro- or antiferromagnetic coupling in MnGa4 1) I started with the regular structure (just spin polarized) I m-3m 1 Mn atom 4 Ga atoms (MnGa4_aexp.struct) this one was running without problems (a small (ferro) magnetic moment of 0.6 seems to exist, I did not check energy and higher precesions), 2) then I made the antiferromagnetic structure P m-3m with 2 Mn atoms and 8 Ga atoms (MnGa4_afm-failes.struct) and named the Mn by 1 and two here the LOPW - Error (at the Ga atom, see below), 3) I splitted the Ga atoms in two groups P 4mm with 2 Mn and 2x4 Ga atoms (MnGa4_afm-2.struct) and named both Mn and Ga toms to distinguish same. this one was running without problems, too (an antiferromagnetic mpoment of +-1.2 muB seems to exist). (indeed, this splitting doesn't make much sense, from symmetry point of view) In all three cases the structure in reduced P1 symmetry has the same lattice parameters and positions (2 Mn and 8 Ga) all calculations were simply initialized with precision 1, the parameters in case.in1 are principally always the same, changing the precesion or other parameters in case 2) did not help. The error appeared independet on the magnetic setting in case.inst (ferro, antiferro, with and without magnetic moment at Ga). (the same LOPW error appears when I replace Ga Z=31 by Ge Z=32 (not with Al or Au)) I wonder why this LOPW error appears in the P m-3m structure but not in the others. (as the P 4mm structure has only 8 symmetry operations it would be faster to run the P m-3m structure (48 symmetry operations)) some detail of the error (note: running lapw1 -dn by hand has the same result as lapw1 -up): the message at the end of case.scf1up (or output1up) is :INFO : LOPW-exhausted for atom3 PASS 1 had to reduce check 0.01 :INFO : LOPW-exhausted for atom3 PASS 2 had to reduce check 0.005000 :INFO : LOPW-exhausted for atom3 PASS 3 had to reduce check 0.002500 :INFO : LOPW-exhausted for atom3 PASS 4 had to reduce check 0.001250 :INFO : LOPW-exhausted for atom3 PASS 5 had to reduce check 0.000625 Ciao I don't expect an answer today, better have a nice weekend, Gerhard ___ 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 Email: peter.bl...@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] Intels Oneapi 2024: Compiler bug ?
Yes, ifx cannot be used at the moment. It is very limited by now and produces many errors during compilation. It is a bit worrying, since ifort (2024) gives an info that it will be disabled next year Most of the time I tried -O3 it did: not significantly improve timing (sometimes it was even slower) sometimes it produced even errors during execution. The performance of -O3 depends a lot on the compiler version and may change with each version. You will have to benchmark it yourself, but don't expect too much. using AVX flags or -Xhost is possible when you have only one type of cpu where the code should run. But again, all you gain is that the executables get smaller and may load faster, because by default code for all kind of cpus will be generated. The overhead of determining which one to use is in my experience small, although I have not tested this much since I usually have several different kind of cpus available. Peter Blaha Am 26.01.2024 um 15:06 schrieb Michael Fechtelkord via Wien: Hello all, I tried also to use ifx .. it works for elpa, mpich, fftw and libxc, but the compilation of WIEN2k has too many errors. With the classic compiler ifort the compilation works fine and also the workaround for SRC_wplot does resolve the compilation error. Elpa recommends flags for certain cpu structures using AVX512, AVX2 etc and uses -O3 instead. I was wondering if using "-O3 -xAVX2" in the compiler flags brings better performance of the WIEN2k code or if its counterproductive and I should stay with the recommendations? Best regards, Michael Am 25.01.2024 um 23:54 schrieb Laurence Marks: From what I can see, ifx is not ready, too much is missing. I suggest sticking with ifoft. --- Professor Laurence Marks (Laurie) www.numis.northwestern.edu <http://www.numis.northwestern.edu> https://scholar.google.com/citations?user=zmHhI9gJ=en <https://scholar.google.com/citations?user=zmHhI9gJ=en> "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi On Fri, Jan 26, 2024, 07:21 Jan Doumont wrote: Dear Peter, Interestingly, I get the same error when using IFORT with the newest oneapi... ifort -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2024.0/include -DHAVE_PTR_ALLOC_GENERICS -Ilib -free -gen-interface nosource -traceback -g -I../SRC_w2w/lib -I../SRC_w2w/lib -c modules.f -olib/modules.o -module lib ifort: remark #10448: Intel(R) Fortran Compiler Classic (ifort) is now deprecated and will be discontinued late 2024. Intel recommends that customers transition now to using the LLVM-based Intel(R) Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. Use '-diag-disable=10448' to disable this message. modules.f(195): error #6911: The syntax of this substring is invalid. [CART] inw%grid%len = (/ ( sqrt(sum( inw%grid%Cart(:,i)**2 )), i=1,3 ) /) --^ compilation aborted for modules.f (code 1) make: *** [Makefile:140: lib/modules.o] Error 1 However, I found the following workaround works with both ifort and ifx on oneapi 2024: do i=1,3 inw%grid%len(i) = sqrt(sum(inw%grid%cart(:,i)**2 )) end do i.e. to replace the implicit loop by an explicit one. BW Jan Doumont On 25/01/2024 19:52, Jan Doumont wrote: > Dear Peter, > > I could compile wien2k 23.2 with no issues using gfortran 13.2.1 (the > version supplied with Fedora 39). I double checked the compile.msg of > SRC_wplot and there are no errors. > > Best Wishes > > Jan Doumont > > > > On 25/01/2024 19:00, Peter Blaha wrote: >> Dear users, >> >> Maybe there is a Fortran expert who knows if this syntax is correct >> or not. >> >> A user reported recently a compilation problem using the most >> recent ifort (or ifx, which will become soon the new fortran >> compiler) (oneapi-2024.0) in SRC_wplot: >> >> ifx -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback >> -assume buffered_io -I/home/aarav/intel/mkl/2024.0/include >> -DHAVE_PTR_ALLOC_GENERICS -Ilib -free -gen-interface nosource >> -traceback -g -I../SRC_w2w/lib -I../SRC_w2w/lib -c modules.f >> -olib/modules.o -module lib >> modules.f(195): error #6911: The syntax of this substring is invalid. >> [CART] >> inw%grid%len = (/( sqrt(sum( inw%grid%Cart(:,i)**2 )), i=1,3 )/) >> -^
[Wien] wien2k workshop
Dear wien2k users, This is just a reminder that the general deadline for the 27th WIEN2k workshop ends 5. February 2024. The workshop will be held at ICTP (Trieste, Italy) from 08 April to 19 April 2024. As far as I know, the grants to support the attendance of selected participants have been distributed, but I will emphasize that still all participants from developing countries will receive a free (!) WIEN2k license. The participation format will be “in-person” only. The program will have a balance of lectures with illustrative examples and hands-on sessions. We plan to cover a range of topics from basic functionality to advanced developments: density functional theory, band structure, magnetism, relativistic effects, phonons, charge transport, spectroscopy (optics, XANES, EELS, XPS), NMR, Mössbauer, Wannier functions, Berry phase, mapping Berry curvature, topological materials, surfaces. There will be a possibility to show your research by presenting a poster. We anticipate hosting about 50 participants. In order to make the workshop easy accessible we have eliminated the registration fee for all participants. Registration applications will be accepted ONLY through the ICTP portal: https://indico.ictp.it/event/10467 We are looking forward to welcome you in Trieste. Your organizing committee (Peter Blaha, Oleg Rubel, and Nicola Seriani) Peter Blaha -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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
[Wien] Intels Oneapi 2024: Compiler bug ?
Dear users, Maybe there is a Fortran expert who knows if this syntax is correct or not. A user reported recently a compilation problem using the most recent ifort (or ifx, which will become soon the new fortran compiler) (oneapi-2024.0) in SRC_wplot: ifx -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume buffered_io -I/home/aarav/intel/mkl/2024.0/include -DHAVE_PTR_ALLOC_GENERICS -Ilib -free -gen-interface nosource -traceback -g -I../SRC_w2w/lib -I../SRC_w2w/lib -c modules.f -olib/modules.o -module lib modules.f(195): error #6911: The syntax of this substring is invalid. [CART] inw%grid%len = (/( sqrt(sum( inw%grid%Cart(:,i)**2 )), i=1,3 )/) -^ So the error is in line 195 of SRC_wplot/modules.f. It appear ONLY with the most recent oneapi 2024.0, not with older versions nor with gfortran-12. Thus the question is: Is this a compiler bug or is this due to a very new fortran-standard which this version enforces ? Has anybody an even newer gfortran (higher than version 12) and can test it with this compiler ? Best regards Peter Blaha -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Atomic muffin tin potential output
The muffin tin (spherically symmetric potential inside spheres, zero in interstitial) is stored in case.vsp (up/dn). It is stored as r*V in Ry (so that the first point is nearly 2*Z). Regards Peter Blaha Am 14.01.2024 um 02:14 schrieb pluto via Wien: Dear All, An electron scattering program I am testing can take atomic muffin-tin potential as an input. Is there a convenient way to output such muffin tin potentials from WIEN2k? If not, then I would appreciate if you could advise on how to generate such muffin tin potentials conveniently. Best, Lukasz ___ 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 Email: peter.bl...@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] NMR Chemical Shift NMR-LOs - here: possibilty to focus on more then one atom
The only specific option besides the number of LOs for mode in1 is -focus nat-nr But this will set NMR-los only for the atom with index nat-nr. Your desired in1_nmr file needs to be done by hand, maybe by copy/paste from 2 different runs with 3 and 10 LOs. Regards Am 03.01.2024 um 16:25 schrieb Michael Fechtelkord via Wien: Dear All, I have a short question concerning the NMR Chemical Shift calculations. I am calculating Chemical Shifts on Lepidolites, e.g. Trilithionite which is K(Li1.5Al1.5)[Si3AlO10]F2 . To reduce the calculation time and reduce the number of NMR-LOs I am asking myself if it is possible to focus on more than one atom, e.g., I am interested in Chemical Shifts of F, Al, and Si, but not in those of K, Li and O, where a reduced number of LOs (n=3) is ok. I think I could do this by merge the values in the in1_nmr files together using the values of n=3 for K, Li and O and n=10 for F, Al, and Si. Is there an easier way to create a in1_nmr file? Thanks in advance and happy new year to all! Best regards, Michael Fechtelkord -- --- 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
Re: [Wien] WIENncm installation error
el64/libmkl_intel_thread.so
2ac961223000-2ac96135d000 rw-p 00cac000 08:02 2119752
/opt/intel/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_intel_thread.so
.
Sir I request to you to please help me to sort out this problem.
Kind Regards,
Safikul Islam
On Sun, Nov 19, 2023 at 10:44 AM Safikul Islam
mailto:safikul.physics1...@gmail.com>> wrote:
Dear Sir,
Even though I have added the path for
WIENncm the error persists. Here is my bashrc file. How
will I add the path of WEIN2k and WIENncm simultaneously?
..
# added by WIEN2k: BEGIN
#
alias lsi="ls -aslp *.in*"
alias lso="ls -aslp *.output*"
alias lsd="ls -aslp *.def"
alias lsc="ls -aslp *.clm*"
alias lss="ls -aslp *.scf* */*.scf"
alias lse="ls -aslp *.error"
alias LS="ls -aslp | grep /"
alias pslapw="ps -ef |grep "lapw""
alias cdw="cd /home/19ph92r03/WIEN2k"
export OMP_NUM_THREADS=1
#export LD_LIBRARY_PATH=.
export EDITOR="gedit"
export SCRATCH=./
#export WIENROOT=/scratch/19ph92r03/safikul/wien2k
export WIENROOT=/scratch/19ph92r03/safikul/WIENNCM/WIENNCM
export W2WEB_CASE_BASEDIR=/home/19ph92r03/WIEN2k
export STRUCTEDIT_PATH=$WIENROOT/SRC_structeditor/bin
export PDFREADER=acroread
export
PATH=$WIENROOT:$STRUCTEDIT_PATH:$WIENROOT/SRC_IRelast/script-elastic:$PATH:.
export OCTAVE_EXEC_PATH=${PATH}::
export OCTAVE_PATH=${STRUCTEDIT_PATH}::
export PATH=$PATH:$WIENROOT:.
ulimit -s unlimited
alias octave="octave -p $OCTAVE_PATH"
# --- BERRYPI START ---
export BERRYPI_PATH=$WIENROOT/SRC_BerryPI/BerryPI
export BERRYPI_PYTHON=/usr/bin/python2.7
alias berrypi="${BERRYPI_PYTHON} ${BERRYPI_PATH}/berrypi"
# --- BERRYPI END ---
#
# added by WIEN2k: END
...
with kind regards,
Safikul Islam
--
*SAFIKUL ISLAM*
[Ph.D Research Scholar]
---
Department of Physics.
Indian Institute of Technology,
Kharagpur.
West Bengal, India.
_Pin Code_:- 721302.
---
_Contact_:- 9832979985
--
*SAFIKUL ISLAM*
[Ph.D Research Scholar]
---
Department of Physics.
Indian Institute of Technology,
Kharagpur.
West Bengal, India.
_Pin Code_:- 721302.
---
_Contact_:- 9832979985
--
*SAFIKUL ISLAM*
[Ph.D Research Scholar]
---
Department of Physics.
Indian Institute of Technology,
Kharagpur.
West Bengal, India.
_Pin Code_:- 721302.
---
_Contact_:- 9832979985
--
*SAFIKUL ISLAM*
[Ph.D Research Scholar]
---
Department of Physics.
Indian Institute of Technology,
Kharagpur.
West Bengal, India.
_Pin Code_:- 721302.
---
_Contact_:- 9832979985
--
*SAFIKUL ISLAM*
[Ph.D Research Scholar]
---
Department of Physics.
Indian Institute of Technology,
Kharagpur.
West Bengal, India.
_Pin Code_:- 721302.
---
_Contact_:- 9832979985
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien
Re: [Wien] WIENncm installation error
It does not help when you let us know that you get an error . Am 15.12.2023 um 17:40 schrieb Safikul Islam: Dear Sir, I am getting errors while executing "x tetra" for dos and "x spaghetti" for band structure calculations with WIENNCM. Perhaps the executing commands for WIENNCM are different from WIEN2k commands to calculate band and dos. Eagerly waiting for your suggestions for sorting out this problem. Kind Regards, Safikul Islam x.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
Re: [Wien] WIEN2k-3233
Please look into the documentation (web) of module and how to load modules. However, from what you listed as available modules, I can see only rather old ifort compilers and no fftw. You can install OneApi (ifort+mkl from Intel) and fftw yourself also as a user. (This is free software, for fftw also see the UG installation tips). Am 30.11.2023 um 14:27 schrieb Safae Benyoussef: Hello, Thank you for your response. The managers of the center, gave us the hand to install the code only in our account, but I have a problem with the libraries the wien2k code requires: ifort, libxc, fftw3. these libraries exist when I type module avail: module avail - /trinity/shared/modules/groups/ - userspace/custom userspace/tr17.10 - /home/.pgi/modulefiles/ - openmpi/2.1.2/2018 pgi/2018 PrgEnv-pgi/18.4(default) pgi/18.4(default) pgi-llvm - /trinity/shared/modules/tr17.10/x86_64/compiler - cuda/7.5 gcc/7.2.0 intel-suite python3/3.6.3 cuda/8.0 intel-compiler/32/2018.0.128 oracle-jdk/1.8.0_171 cuda/9.1 intel-compiler/64/2018.0.128 python2/2.7.14 - /trinity/shared/modules/tr17.10/x86_64/mpi - intel-mpi/64/2018.0.128 mvapich2/gcc72/ofed/2.2 mvapich2/icc18/psm2/2.2 openmpi/icc18/ofed/3.0.0 mpich/gcc72/psm2/3.2.1 mvapich2/gcc72/psm2/2.2 openmpi/gcc72/ofed/3.0.0 openmpi/icc18/psm2/3.0.0 mpich/icc18/psm2/3.2.1 mvapich2/icc18/ofed/2.2 openmpi/gcc72/psm2/3.0.0 - /trinity/shared/modules/tr17.10/x86_64/libraries - blas/3.7.1 fftw3/icc18/3.3.6-pl2 intel-tbb/32/2018.0.128 blas/gcc72/3.7.1 fftw3/icc18/impi/3.3.6-pl2 intel-tbb/64/2018.0.128 blas/icc18/3.7.1 fftw3/icc18/mvapich2/3.3.6-pl2 lapack/3.7.1 boost/gcc72/1.65.1 fftw3/icc18/openmpi/3.3.6-pl2 lapack/gcc72/3.7.1 boost/gcc72/mvapich2/1.65.1 hdf5/gcc72/1.10.1 lapack/icc18/3.7.1 but how can I call them and declare the paths for the compilation (which command) If there is any way to copy the path in bachrc file ? if you do me a favor and send me a link or a method to solve this problem, I will be grateful. Cordially, Safae Benyoussef Le mar. 28 nov. 2023 à 15:30, Safae Benyoussef mailto:safaebenyous...@gmail.com>> a écrit : Hello, I would like to inform you that I am trying to install the code in my account on a supercomputer. I would greatly appreciate your guidance. Thank you in advance for your assistance. Cordially, Safae Benyoussef Le mar. 28 nov. 2023 à 12:59, Safae Benyoussef mailto:safaebenyous...@gmail.com>> a écrit : Hello, I am writing to seek your assistance in the installation of the code. Could you tell me how to install the code in the user account and call the libraries: ifort, fftw... I would greatly appreciate your guidance. Thank you in advance for your assistance. Cordially, Safae Benyoussef ___ 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 Email: peter.bl...@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
[Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co
Initially I executed calculation in the "spirit of force theorem" with just one iteration and obtained well converged K value calculated from EIGEN. However reviewer mentioned that force theorem is not obeyed in case of +U calculation - corrections are not in second order. He is right, the K value obtained from full scf calculations and total energy difference is ~40% higher. For just GGA both approaches gives the same result. --- This depends on how you start the EIGN calculation. From a scalar relativistic GGA+U calculation or just from GGA ?? And in addition it is probably again a problem of symmetry. Reliable values can only be obtained with identical symmetry in the scalarel and SO calculation. So you have to perform the scalarel. calc with the same struct file (symmetry operations) and case.in2c (LM combinations) as the 2 SO calculations. It is NOT only a matter of k-points and cannot be "fixed by x kgen -fbz --- --- What surprises me is the non-monotonic dependence of K value as a number of k-points. At the same time K calculated from the total energy converged. While, the band structure energy is part of the total energy. -- Not a big surprise. During the scf cycle the potential changes. Remember, by adding a constant potential, the EIGEN values would change by shift*NE, but the potential energy would also shift in opposite direction by -shift*NE, so Etot remains constant, but EIGEN not. (NE .. number of electrons) -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co
A couple of remarks inlined: I did self consistent calculations for each magnetization orientations 1. in directory with name 100 run init_so_lapw 2. choose [1 0 0] magnetization orientation 3. copy directory to the new one with name 001 4. in directory 001 rename names 100 to 001 5. in directory 001 change magnetization orientation in 001.inso to 001 6. runsp -so -orb -dm -p -ec 0.01 -NI -i 200 on both directories after finishing for total energy grep :ENE case.scf for band structure part grep EIGN case.scf With this procedure you can only rely on the total energy, EIGN relys on the "force theorem" and must be done non-selfconsistently. This requires, however, to make one scalarelativistic calc (+U) in a common symmetry, i.e. you must use a struct file which fits both magnetization directions. Then you run init_so (it must not change the symmetry) with eg. 001 direction, runsp -so -orb -i 1 grep EIGN case.scf restore scalarelativistic calc init_so with other direction runsp -so -orb -i 1 grep EIGN case.scf PS: In some cases it is also necessary to run the scf SO calculations for the different directions ALSO with ONE common symmetry, otherwise numerical inconsistencies could occur (eg. in one direction hexagonal symmetry, in another one something else --> may lead to inconsistent k- or FFT-meshes) PPS: Wien2k_19 has a couple of bugs for spin-orbit, see update section in wien2k.at. Please be careful ! to increase k mesh 1. go to directory 100 2. x kgen -so 3. cp 100.klist ../001/001.klist; cp 100.kgen ../001/001.kgen This is not ok in general. One cannot use the 100 k-mesh for 001 direction (except you already have a common symmetry). 4. runsp -so -orb -dm -p -ec 0.01 -NI -i 200 on both directories after finishing for total energy grep :ENE case.scf for band structure part grep EIGN case.scf Dr. German D Samolyuk Materials Theory Group Materials Science & Technology Division Oak Ridge National Laboratory Post Office Box 2008 Oak Ridge, TN 37831-6138 (865) 241-5394 (865) 241-3650 (FAX) *From:* Wien on behalf of Peter Blaha *Sent:* Wednesday, November 29, 2023 4:37 PM *To:* wien@zeus.theochem.tuwien.ac.at *Subject:* Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co For Eigen you do just ONE iteration ? But how did you start the calculations ? I need your commands, exactly as you typed them (not only the last one, but all the essential history ...) Am 29.11.2023 um 21:07 schrieb Samolyuk, German D. via Wien: I take last set from >grep EIGEN case.scf for two orientations The values in case.scf2up and case.scf2dn are the same Dr. German D Samolyuk Materials Theory Group Materials Science & Technology Division Oak Ridge National Laboratory Post Office Box 2008 Oak Ridge, TN 37831-6138 (865) 241-5394 (865) 241-3650 (FAX) *From:* Wien on behalf of Peter Blaha *Sent:* Wednesday, November 29, 2023 2:57 PM *To:* wien@zeus.theochem.tuwien.ac.at *Subject:* [EXTERNAL] Re: [Wien] YCo5 magnetic anisotropy calculations with GGA+U on Co Please list all the steps you do for the EBND calculation for the GGA+U case. I'd expect you do something wrong in this case. Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien: Dear colleagues, I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with U-J=0.08 Ry Co d-states, wien2k_19. To obtain the MAE, K, value the fully self-consistent calculations were executed for in plane and along z-axis magnetic moment orientation. the self-consistency is important for case of GGA+U. Three sets of calculations were executed 1) keep 8 symmetry operation obtained for [100] moment orientation, 2) keep 8 symmetry operations obtained for [110] operations, 3) one E symmetry operation - full BZ integration. The MAE energy is calculated 1) as total energy difference 2) as a difference of band structure energy, EBND. Following results were obtained: >1) 100 - 8 SYM OP: nk=16x16x17-5000: K = 6.53575196338352 meV/fu nk=18x18x20-7000: K = 6.49467997718602 meV/fu nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND >2) [110] - 8 SYM OP: 16x16x17-5000: K = 6.56594401516486 meV/fu 18x18x20-7000: K = 6.47836000134703 meV/fu 16x16x17-5000: K = 23.350166399905 meV/fu - EBND 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND >3) FBZ - 1 SYM OP: 16x16x17-5000: K = 6.48733603011351 meV/fu 18x18x20-7000: K = 6.45932000479661 meV/fu 16x16x17-5000: K = -23.450821642 meV/fu - EBND 18x18x20-7000: K = -14.726882399907 meV/fu - EBND The total energy results for MAE, K, are well converged and insensitive to in-plane magnetization orientation. While, K value calculated from band structure energy, EBND, behaved strange. Expectedly,
Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co
For Eigen you do just ONE iteration ? But how did you start the calculations ? I need your commands, exactly as you typed them (not only the last one, but all the essential history ...) Am 29.11.2023 um 21:07 schrieb Samolyuk, German D. via Wien: I take last set from >grep EIGEN case.scf for two orientations The values in case.scf2up and case.scf2dn are the same Dr. German D Samolyuk Materials Theory Group Materials Science & Technology Division Oak Ridge National Laboratory Post Office Box 2008 Oak Ridge, TN 37831-6138 (865) 241-5394 (865) 241-3650 (FAX) *From:* Wien on behalf of Peter Blaha *Sent:* Wednesday, November 29, 2023 2:57 PM *To:* wien@zeus.theochem.tuwien.ac.at *Subject:* [EXTERNAL] Re: [Wien] YCo5 magnetic anisotropy calculations with GGA+U on Co Please list all the steps you do for the EBND calculation for the GGA+U case. I'd expect you do something wrong in this case. Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien: Dear colleagues, I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with U-J=0.08 Ry Co d-states, wien2k_19. To obtain the MAE, K, value the fully self-consistent calculations were executed for in plane and along z-axis magnetic moment orientation. the self-consistency is important for case of GGA+U. Three sets of calculations were executed 1) keep 8 symmetry operation obtained for [100] moment orientation, 2) keep 8 symmetry operations obtained for [110] operations, 3) one E symmetry operation - full BZ integration. The MAE energy is calculated 1) as total energy difference 2) as a difference of band structure energy, EBND. Following results were obtained: >1) 100 - 8 SYM OP: nk=16x16x17-5000: K = 6.53575196338352 meV/fu nk=18x18x20-7000: K = 6.49467997718602 meV/fu nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND >2) [110] - 8 SYM OP: 16x16x17-5000: K = 6.56594401516486 meV/fu 18x18x20-7000: K = 6.47836000134703 meV/fu 16x16x17-5000: K = 23.350166399905 meV/fu - EBND 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND >3) FBZ - 1 SYM OP: 16x16x17-5000: K = 6.48733603011351 meV/fu 18x18x20-7000: K = 6.45932000479661 meV/fu 16x16x17-5000: K = -23.450821642 meV/fu - EBND 18x18x20-7000: K = -14.726882399907 meV/fu - EBND The total energy results for MAE, K, are well converged and insensitive to in-plane magnetization orientation. While, K value calculated from band structure energy, EBND, behaved strange. Expectedly, both ways of K calculation gives close result for regular GGA (the force theorem). Do you know what is source of such irregular EBND difference behavior for GGA+U calculaions? Thank you, German Dr. German D Samolyuk Materials Theory Group Materials Science & Technology Division Oak Ridge National Laboratory Post Office Box 2008 Oak Ridge, TN 37831-6138 (865) 241-5394 (865) 241-3650 (FAX) ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90= <https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90=> SEARCH the MAILING-LIST at: https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=FG4ImVhTGdAMvrN_wwV3CigER_LipQfvTaP957uSDjE= <https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=FG4ImVhTGdAMvrN_wwV3CigER_LipQfvTaP957uSDjE=> -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.at WIEN2k: https://urldefense.us/v2/url?u=http-3A__www.wien2k.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=IitTpMm41OFhN-Au4l57q3yUam7I8dV_VlmLzKwEpMg= <https://urldefense.us/v2/url?u=http-3A__www.wien2k.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GA
Re: [Wien] YCo5 magnetic anisotropy calculations with GGA+U on Co
Please list all the steps you do for the EBND calculation for the GGA+U case. I'd expect you do something wrong in this case. Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien: Dear colleagues, I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with U-J=0.08 Ry Co d-states, wien2k_19. To obtain the MAE, K, value the fully self-consistent calculations were executed for in plane and along z-axis magnetic moment orientation. the self-consistency is important for case of GGA+U. Three sets of calculations were executed 1) keep 8 symmetry operation obtained for [100] moment orientation, 2) keep 8 symmetry operations obtained for [110] operations, 3) one E symmetry operation - full BZ integration. The MAE energy is calculated 1) as total energy difference 2) as a difference of band structure energy, EBND. Following results were obtained: >1) 100 - 8 SYM OP: nk=16x16x17-5000: K = 6.53575196338352 meV/fu nk=18x18x20-7000: K = 6.49467997718602 meV/fu nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND >2) [110] - 8 SYM OP: 16x16x17-5000: K = 6.56594401516486 meV/fu 18x18x20-7000: K = 6.47836000134703 meV/fu 16x16x17-5000: K = 23.350166399905 meV/fu - EBND 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND >3) FBZ - 1 SYM OP: 16x16x17-5000: K = 6.48733603011351 meV/fu 18x18x20-7000: K = 6.45932000479661 meV/fu 16x16x17-5000: K = -23.450821642 meV/fu - EBND 18x18x20-7000: K = -14.726882399907 meV/fu - EBND The total energy results for MAE, K, are well converged and insensitive to in-plane magnetization orientation. While, K value calculated from band structure energy, EBND, behaved strange. Expectedly, both ways of K calculation gives close result for regular GGA (the force theorem). Do you know what is source of such irregular EBND difference behavior for GGA+U calculaions? Thank you, German Dr. German D Samolyuk Materials Theory Group Materials Science & Technology Division Oak Ridge National Laboratory Post Office Box 2008 Oak Ridge, TN 37831-6138 (865) 241-5394 (865) 241-3650 (FAX) ___ 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 Email: peter.bl...@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] WIEN2k-3233
On a supercomputer usually all the required software is installed. However, in most cases it is not available as default, but with some commands you can get it. Many systems use "modules", which one can load (best in .bashrc). But we cannot know of your supercomputer deployes software via modules or some other software. As was said, you have to ask the sysadmin or study any online docu for your supercomputer. Am 28.11.2023 um 21:46 schrieb Safae Benyoussef: Hello, Thank you for your response. I think that my previous email was not very clear. I followed the commands from the code installation. First, I got a clean license for me only, I copied the code folder and put it on my account and the technicians of the supercomputer asked me to ask you the question if I could install the code on my user account only. I tried to do it but there is a problem to specify the compiler I typed ifort then it detects that the compiler path and the fftw n blas packages ... do not exist on the account then the question how I can specify the packages path and install it. Cordially, Safae Benyoussef Le mar. 28 nov. 2023 à 15:30, Safae Benyoussef mailto:safaebenyous...@gmail.com>> a écrit : Hello, I would like to inform you that I am trying to install the code in my account on a supercomputer. I would greatly appreciate your guidance. Thank you in advance for your assistance. Cordially, Safae Benyoussef Le mar. 28 nov. 2023 à 12:59, Safae Benyoussef mailto:safaebenyous...@gmail.com>> a écrit : Hello, I am writing to seek your assistance in the installation of the code. Could you tell me how to install the code in the user account and call the libraries: ifort, fftw... I would greatly appreciate your guidance. Thank you in advance for your assistance. Cordially, Safae Benyoussef ___ 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 Email: peter.bl...@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] Cholesky error in slab structure
You did not list the RMTs, so I cannot comment on this part. You also did not report :DIS for the first 5 cycles. However, for a complicated structure including metallic Co ?? I would recommend to pre converge the scf WITHOUT -min first, otherwise the calculations may diverge. Due to too large charge fluctuations it could happen that the E-parameters of APWs and LOs get too close leading to linear dependency. rm *.bro* *scf x dstart vi case.inm change MSR1a to MSR1 run_lapw -fc 5 # crude scf without -min run_lapw -min . One more remark: You mentioned Co on your slab ? This must be done spin-polarized. Am 24.11.2023 um 10:02 schrieb Natalia Andreeva: Dear WIEN2k users, I am trying to perform a calculation on a large LSMO/BTO/Co slab. I start the calculation with automatically determined RMT values. At the StructGen stage, I reduce RMT by 5% because I want to perform force minimization. I have successfully initialized structure with the command: init_lapw -hdlo -prec 0n -red 3 -rkmax 5.5 -lvns 5 -numk 0 5 5 1 To minimize the forces, I use MSR1a with some atomic positions fixed. I run run_lapw -ec 0.005 -cc 0.05 -fc 1 -p –min. After 1-5 execution cycles SCF is interrupted with an error: Cholesky INFO = 5974 'SECLR4' - POTRF (Scalapack/LAPACK) failed What could be a problem? I tried to decrease or increase RMT or use it in run_lapw, but it does not help. There are no atoms with the same positions in the case.struct file. With Best Regards, Natalia ___ 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 Email: peter.bl...@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] lapwso segfault
Hi, Such segfaults have been reported before and I also had this in one or two cases. As far as I know, it is not well reproducible, seems to depend on the computer and in particular on the specific input. Changing emax a bit, already makes lapwso running again. A couple of years ago I had such a case and it was fixed by a 10 times larger workspace for routine ZHEEVR (see comments in hmsec.F a few lines before 836). ! segfault in zheevr, fixed by larger workspace, PB 25.10.19 CH32SnTe3 LWORK = WORK(1) *10 !4 LIWORK = IWORK(1) LRWORK=RWORK(1) I concluded at that time that it is a problem with Intels mkl library. Maybe also multiply liwork and lrwork by 10 and/or use another (bigger) factor. Since you seem to have the problem also in connection with OMP_NUM_THREADS (this is new for me), maybe setting a larger stacksize helps. call KMP_SET_STACKSIZE_S(1) (somewhere at the beginning of lapwso) One could also test it with gfortran/openblas and see if the problem persists or my conclusion about a mkl error is correct. Sorry, but I'm afraid I do not know a perfect solution. Peter Blaha Am 20.11.2023 um 15:20 schrieb Mikhail Nestoklon via Wien: 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 -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] WIENncm installation error
do ll cputim.* you should find a couple of cputim* routines. Nowadays, we use only cputim.c in wien2k, which has to be compiled using cc, gcc or icc compilers. I remember that previously we had a couple of different cputim routines ... Am 17.11.2023 um 18:01 schrieb Safikul Islam: Dear Professor Peter Blaha, I followed your suggestion. I have adopted all the libraries and Makefiles from the WIEN2k installation directory. Now the errors have been reduced. Only one error is coming. .. Error: Compile time errors (if any) were: SRC_dstart/compile.msg:ifort: error #10236: File not found: 'cputim.o' SRC_dstart/compile.msg:make: *** [dstart] Error 1 .. Sir please help me to resolve this issue. Kind Regards, Safikul Islam On Fri, Nov 17, 2023 at 8:19 PM Safikul Islam mailto:safikul.physics1...@gmail.com>> wrote: Dear Professor Peter Blaha, You are right. The path of ifortran compiler was not adjusted properly in the bashrc file. After giving the proper path of ifortran compiler I am getting the following errors during compilation of the WIENncm software. I have pasted the error of the compile.msg file of the SRC_displacement folder. . *Compile time errors (if any) were: SRC_displacement/compile.msg:make: *** [displacement] Error 1 SRC_dstart/compile.msg:ifort: error #10236: File not found: 'cputim.o' SRC_dstart/compile.msg:make: *** [dstart] Error 1 SRC_lapw0/compile.msg:make[1]: *** [lapw0] Error 1 SRC_lapw0/compile.msg:make: *** [seq] Error 2 SRC_lapw1/compile.msg:make[1]: *** [lapw1c] Error 1 SRC_lapw1/compile.msg:make: *** [complex] Error 2 SRC_lapw2/compile.msg:make[1]: *** [lapw2c] Error 1 SRC_lapw2/compile.msg:make: *** [complex] Error 2 SRC_lapwdm/compile.msg:make[1]: *** [lapwdmc] Error 1 SRC_lapwdm/compile.msg:make: *** [complex] Error 2 SRC_mixer/compile.msg:make: *** [mixer] Error 1 SRC_mixer_old/compile.msg:make: *** [mixer] Error 1 SRC_ncmsymmetry/compile.msg:make: *** [ncmsymmetry] Error 1* *SRC_displacement/compile.msg error* *ifort -o ./displacement module.o gtfnam.o errflg.o errclr.o outerr.o displacement.o determinant.o euler.o inversa.o make_point_groups.o find_displacement.o lapack.o lapack2.o -L../SRC_lib -L/opt/intel/mkl60/lib/32 -Vaxlib -static -lmkl_lapack -lmkl_p4 -lguide -lpthread ifort: command line remark #10010: option '-Vaxlib' is deprecated and will be removed in a future release. See '-help deprecated' ld: cannot find -lmkl_lapack ld: cannot find -lmkl_p4 ld: cannot find -lguide /usr/lib/../lib64/libpthread.a(libpthread.o): In function `sem_open': (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use `mkstemp' make: *** [displacement] Error 1* *..* * * * * Sir, how should I proceed now? I kindly request you to please help me to sort out this problem. Kind Regards, Safikul Islam On Fri, Nov 17, 2023 at 1:28 PM Safikul Islam mailto:safikul.physics1...@gmail.com>> wrote: Dear Wien2k users and developers, I am trying to install WIENncm using ifortran compiler version 18.0.0. But I am getting many errors. The error has been attached with this mail. I have looked into the previous messages regarding the installation of WIENncm. It has been suggested that WIENncm is compatible with ifortran compiler version 11.xxx. But right now I am unable to change ifortran compiler version from 18.0.0 to ifortran 11.xxx. Could anyone suggest to me how I will install WIENncm using ifortran 18.0.0? If anyone has installed it by changing the makefiles I am requesting you to please help me regarding this issue. I will remain thankful to you. Kind Regards, *SAFIKUL ISLAM* [Ph.D Research Scholar] --- Department of Physics. Indian Institute of Technology, Kharagpur. West Bengal, India. _Pin Co
Re: [Wien] WIENncm installation error
Hi, Please note: For wienncm and wienbse wie do NOT provide full support. This was clearly stated on the website. In particular, these codes require some knowledge of Linux as the installation is not so automatic as in WIEN2k and in particular, there are no updates, so the user has to adapt the Makefile himself. Anyway: i) Do you have the MKL in your path (echo $MKLROOT) ? You may have to source some configuration script. ii) You have to modify your Makefiles. In general, most of the options should be the same as for a WIEN2k compilation. Check your Makefiles in WIEN2k and adopt the libraries and options from there. > *ifort -o ./displacement module.o gtfnam.o errflg.o errclr.o outerr.o > displacement.o determinant.o euler.o inversa.o make_point_groups.o > find_displacement.o lapack.o lapack2.o -L../SRC_lib > -L/opt/intel/mkl60/lib/32 -Vaxlib -static -lmkl_lapack -lmkl_p4 -lguide > -lpthread Obviously, this Makefile is still for a 32 bit machine and a very old compiler. You have to adopt it to your path (-L/opt/intel/mkl60/lib/32 ) change/remove some options (-Vaxlib), modify the names of some mkl-libraries to the present version (-lmkl_p4 -lguide) The proper info for your system can be found in your WIEN2k compilation. Am 17.11.2023 um 15:49 schrieb Safikul Islam: Dear Professor Peter Blaha, You are right. The path of ifortran compiler was not adjusted properly in the bashrc file. After giving the proper path of ifortran compiler I am getting the following errors during compilation of the WIENncm software. I have pasted the error of the compile.msg file of the SRC_displacement folder. . *Compile time errors (if any) were: SRC_displacement/compile.msg:make: *** [displacement] Error 1 SRC_dstart/compile.msg:ifort: error #10236: File not found: 'cputim.o' SRC_dstart/compile.msg:make: *** [dstart] Error 1 SRC_lapw0/compile.msg:make[1]: *** [lapw0] Error 1 SRC_lapw0/compile.msg:make: *** [seq] Error 2 SRC_lapw1/compile.msg:make[1]: *** [lapw1c] Error 1 SRC_lapw1/compile.msg:make: *** [complex] Error 2 SRC_lapw2/compile.msg:make[1]: *** [lapw2c] Error 1 SRC_lapw2/compile.msg:make: *** [complex] Error 2 SRC_lapwdm/compile.msg:make[1]: *** [lapwdmc] Error 1 SRC_lapwdm/compile.msg:make: *** [complex] Error 2 SRC_mixer/compile.msg:make: *** [mixer] Error 1 SRC_mixer_old/compile.msg:make: *** [mixer] Error 1 SRC_ncmsymmetry/compile.msg:make: *** [ncmsymmetry] Error 1* *SRC_displacement/compile.msg error* *ifort -o ./displacement module.o gtfnam.o errflg.o errclr.o outerr.o displacement.o determinant.o euler.o inversa.o make_point_groups.o find_displacement.o lapack.o lapack2.o -L../SRC_lib -L/opt/intel/mkl60/lib/32 -Vaxlib -static -lmkl_lapack -lmkl_p4 -lguide -lpthread ifort: command line remark #10010: option '-Vaxlib' is deprecated and will be removed in a future release. See '-help deprecated' ld: cannot find -lmkl_lapack ld: cannot find -lmkl_p4 ld: cannot find -lguide /usr/lib/../lib64/libpthread.a(libpthread.o): In function `sem_open': (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use `mkstemp' make: *** [displacement] Error 1* *..* * * * * Sir, how should I proceed now? I kindly request you to please help me to sort out this problem. Kind Regards, Safikul Islam On Fri, Nov 17, 2023 at 1:28 PM Safikul Islam mailto:safikul.physics1...@gmail.com>> wrote: Dear Wien2k users and developers, I am trying to install WIENncm using ifortran compiler version 18.0.0. But I am getting many errors. The error has been attached with this mail. I have looked into the previous messages regarding the installation of WIENncm. It has been suggested that WIENncm is compatible with ifortran compiler version 11.xxx. But right now I am unable to change ifortran compiler version from 18.0.0 to ifortran 11.xxx. Could anyone suggest to me how I will install WIENncm using ifortran 18.0.0? If anyone has installed it by changing the makefiles I am requesting you to please help me regarding this issue. I will remain thankful to you. Kind Regards, *SAFIKUL ISLAM* [Ph.D Research Scholar] --- Department of Physics. Indian Institute of Technology, Kharagpur. West Bengal, India. _Pin Code_:- 721302. --- _Contact_:- 9832979985 -- *SAFIKUL ISLAM* [
Re: [Wien] Problem in All compilation
You have error in almost all programs, also in thos which do not use fftw. You need to look directly into compile.msg to get more info about your problem. Am 16.11.2023 um 02:52 schrieb Shahid Mahmood Chaudhry via Wien: Dear Sir Where is the problem and how to solve it Ubuntu 23.1 Wien2k 23.2 Libxc Openblas fftw3 gfortran compiler Compile time errors (if any) were: SRC_3ddens/compile.msg:Fatal Error: Cannot open included file ‘fftw3.f03’ SRC_3ddens/compile.msg:make: *** [Makefile:84: fft_modules.o] Error 1 SRC_afmsim/compile.msg:collect2: error: ld returned 1 exit status SRC_afmsim/compile.msg:make: *** [Makefile:68: afmsim] Error 1 SRC_aim/compile.msg:collect2: error: ld returned 1 exit status SRC_aim/compile.msg:make[1]: *** [Makefile:93: aim] Error 1 SRC_aim/compile.msg:make: *** [Makefile:85: real] Error 2 SRC_aim/compile.msg:collect2: error: ld returned 1 exit status SRC_aim/compile.msg:make[1]: *** [Makefile:96: aimc] Error 1 SRC_aim/compile.msg:make: *** [Makefile:88: complex] Error 2 SRC_clminter/compile.msg:collect2: error: ld returned 1 exit status SRC_clminter/compile.msg:make: *** [Makefile:52: clminter] Error 1 SRC_dipan/compile.msg:collect2: error: ld returned 1 exit status SRC_dipan/compile.msg:make: *** [Makefile:68: dipan] Error 1 SRC_dstart/compile.msg:collect2: error: ld returned 1 exit status SRC_dstart/compile.msg:make[1]: *** [Makefile:99: dstart] Error 1 SRC_dstart/compile.msg:make: *** [Makefile:90: seq] Error 2 SRC_eosfit6/compile.msg:collect2: error: ld returned 1 exit status SRC_eosfit6/compile.msg:make: *** [Makefile:36: eosfit6] Error 1 SRC_filtvec/compile.msg:collect2: error: ld returned 1 exit status SRC_filtvec/compile.msg:make[1]: *** [Makefile:82: filtvec] Error 1 SRC_filtvec/compile.msg:make: *** [Makefile:72: real] Error 2 Thanks Disclaimer: This communication is intended for the above named person and is confidential and / or legally privileged. Any opinion(s) expressed in this communication are not necessarily those of KSU (King Saud University). If it has come to you in error you must take no action based upon it, nor must you print it, copy it, forward it, or show it to anyone. Please delete and destroy the e-mail and any attachments and inform the sender immediately. Thank you. KSU is not responsible for the political, religious, racial or partisan opinion in any correspondence conducted by its domain users. Therefore, any such opinion expressed, whether explicitly or implicitly, in any said correspondence is not to be interpreted as that of KSU. KSU may monitor all incoming and outgoing e-mails in line with KSU business practice. Although KSU has taken steps to ensure that e-mails and attachments are free from any virus, we advise that, in keeping with best business practice, the recipient must ensure they are actually virus free. ___ 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 Email: peter.bl...@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] WIENncm installation error
Betreff: WIENncm installation error Von: Safikul Islam I am trying to install WIENncm using ifortran compiler version 18.0.0. But I am getting many errors. The error has been attached with this mail. I have looked into the previous messages regarding the installation of WIENncm. It has been suggested that WIENncm is compatible with ifortran compiler version 11.xxx. But right now I am unable to change ifortran compiler version from 18.0.0 to ifortran 11.xxx. Could anyone suggest to me how I will install WIENncm using ifortran 18.0.0? If anyone has installed it by changing the makefiles I am requesting you to please help me regarding this issue. I will remain thankful to you. -- It has nothing to do with a particular ifort version. Your error says (for all programs): make: Error 127 The error 127 usually means program not found. Typewhich ifort Do you have ifort in your path ? Please look into the detailed error info in compile.msg (in some program). You get more info about the source of the problem. -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] [WIEN2k] forrtl IO error in x_nmr_lapw for Heavy metal structures (TlF3, HgF2)
I recompiled lapw1 with LOMAX = 4 but then the scf cycle fails. As I said before, you also need to recompile lapw2, lapwso and nmr. The real problem was the used cut off energy of -11 Ry in init_lapw. That introduces also too much orbitals in x_nmr -mode in1 and a qtl-b errors in the first two loops. After using the default value of -6 Ry for core / valence separation, scf cycles converge without QTL-B errors and the x_nmr initializations starts with less atomic orbitals and the calculations (x_nmr -p) no longer produces forrtl I/O errors. Yes, such a low E-cut is dangerous and only necessary if you have extremely small spheres. Note: Sometimes it is better to use -ecut 0.999 (or similar). This would not use the energy as core/valence separation, but the amount of charge inside the sphere for each orbital. In particular for 5d elements this is useful as it can put the 4f states into core, but lower energy 5p states remain valence. Thanks again for the help! Best regards, Michael Fechtelkord Am 12.11.2023 um 23:28 schrieb Peter Blaha: Once I've seen your in1 file, the solution is probably very simple: I did not know that you included the 4f states of Tl (near -8 Ry) as valence. The nmr code constructs by default NMR-local orbitals up to "l-exception" + 1, i.e. up to l=4 when you have l=3 states listed in the regular case.in1 While this is possible, it requires to recompile lapw1/2,nmr with a modified parameter LOMAX =4 (param.inc in lapw1, in other codes in modules - do a search). This is necessary if you handle 4f elements or early 5d metals, however, I very much doubt that it is a good idea to include the 4f states for Tl (with RMT=2.5) as valence. I would not use -ecut -11. All it produces is noise as the 4f convergence can be quite problematic and SO effects might be of importance. Best regards Peter Blaha Am 12.11.2023 um 22:12 schrieb Michael Fechtelkord: Lieber Herr Blaha, schon mal vorab herzlichen Dank für die schnelle Hilfe auch am Wochenende. Anbei die gewünschten Daten und folgendermaßen bin ich vorgegangen: im Verzeichnis TlF3 1) cif2struct TlF3.cif 2) Kontrolle und Nachbearbeitung mit struct generator in w2web 3) rmt gesetzt mit 0% Reduktion in w2web struct Generator (set automatically RMT and continue editing) 4) Structfile abgeschlossen (save file and cleanup) Weiter im Terminalfenster: 5) init_lapw -b -rkmax 7 -numk 1000 -ecut -11 (endete mit ok) 6) run_lapw -p -ec 0.0001 -cc 0.0001 (konvergierte nach ca. 13 Zyklen) 7) save_lapw TlF3_pbe_rkmax_7_numk_1000_ecut_11_cc_0001 8) x kgen auf 1 k points (habe es auch mit weniger probiert, daran liegt es wohl nicht) 9) x_nmr_lapw -mode in1 10) x_nmr_lapw -p Ich hänge auch das cif File und das machines File der Vollständigkeit halber an. NTMATMAX ist 4, NUME 6000, OMP_NUM_THREADS 2 Sollten Sie zusätzliche Daten benötigen, schreiben Sie mich kurz an. Viele Dank schon mal und einen guten Wochenstart wünscht Michael Fechtelkord -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Parallel LAPW1 job suspended without any error message
The .machines file you show is for k-parallelization on the local host only. Thus: i) mpi is not used and all mpi settings are irrelevant for this. ii) The k-point parallelization is stirred by the variable USE_REMOTE in $WIENROOT/WIEN2k_parallel_options If set to 0, you can run ONLY on your localhost. It will simply start N lapw1 lapw1_n.def jobs in the background. Nothing else is needed. If set to 1, you can run on the local host and on remote hosts, when you meet the following requirements: i) a common NFS file system, i.e. your data must be available under the same path on all nodes. ii) you need passwordless ssh (or what you have configured during siteconfig), i.e. a command like ssh localhost hostname must execute without any further input/confirmation (to all nodes you specified) This can be done using "keys", (see 5.5.1 in the UG). I'd expect that whenx lapw1 -p is hanging, you would see 4 ssh localhost ... commands which are waiting forever using ps -ef|grep ssh PS: WIEN2k_19 is outdated, I strongly recommend using 23.2. It has a much better initialization and produces more efficient input files. Am 15.11.2023 um 08:09 schrieb heungsi...@kangwon.ac.kr: Dear Wien2k users, I’ve recently encountered a strange situation in parallel execution of Wien2k (version 19). Normally I run wien2k jobs using OpenMP and they works without any trouble. But recently there has been a project that I need to run wien2k using k-point parallelization, and I am having a trouble that I couldn’t solve. Issue: * When running wien2k using k-point parallelization (with the -p option in run_lapw and .machines file), the job suspends at the lapw1 stage and does not produce any lapw1 output (such as case.vector_* files) or error messages. * Terminating the job and running the command “x lapw1 -p” reproduces the symptom. Checking active processes in the compute node while the “x lapw1 -p” command is on does now show any lapw1 jobs running, except the signature of suspended lapw1para script. * Removing the -p option and running in serial or using OpenMP multithreads work totally OK. Further info. on my system: * Wien2k version: 19.1 (also unofficially tried with version 23, the same problem persists) * System: Ubuntu 20.04 LTS * Compiler, math library: Intel oneapi 2023 version, with intel icc, ifort, mpiifort, and MKL (lapack, blacs, scalapack). * FFTW: FFTW3, compiled using intel compilers from source (ver. 3.3.8) * MPI: Intel MPI included in the Intel oneapi package, and with MPI_REMOTE = 0 o Tried both using / not using mpi parallelization. The same lapw1 suspension persists. My .machines file looks like below (for a 4 core test job): granularity:1 1:localhost 1:localhost 1:localhost 1:localhost extrafine:1 I checked that, after running x lapw1 -p, a list of case.klist_* files and lapw1_*.def files are created in the working directory (and also “.machine* files). Running each of k-divided case using lapw1 (for example, using commands like “lapw1 lapw1_1.def”) works fine and creates case.vector_* files correctly. Strangely, actual "x lapw1 -p" (or “lapw1para_lapw lapw1.def”) does not enter the lapw1-running stage and suspends somewhere before that. Because this suspension does not create any error or other messages, I have no idea on how to solve this issue. Currently what I tried are as follows: * Recompiling wien2k without any mpi-related options (which means, even with setting MPI_REMOTE to be 1) * Tuning DELAY and SLEEPY in lapw1para * Running the parallel job on a local storage (not on a NFS storage) * As mentioned above, using newer wien2k version 23 (just as a test purpose! I am not producing any scientific results with that) * Removing fftw3. But this should not matter, because lapw1 does not seem to use fftw which all were not successful in rectifying the issue. I tried searching the previous wien2k mailing list, I might missed, but I couldn’t find any issue similar to mine. Any of your comments will be highly appreciated! Best regards, Heung-Sik --- *Heung-Sik Kim* /Assistant Professor// Department of Physics Kangwon National University/ email: heungsi...@kangwon.ac.kr <mailto:heungsi...@kangwon.ac.kr> https://sites.google.com/view/heungsikim/ <https://sites.google.com/view/heungsikim/> ___ 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 Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at WW
Re: [Wien] Error in bandstructure using x spaghetti
It is obvious that the error occurs while reading the input file *.insp Most likely you did not put the correct Fermi energy into this file. By default there is a x. laceholder and this has to be replaced by your EF (which you can find in your scf file (grep :FER case.scf). Regards Am 15.11.2023 um 08:12 schrieb 夏宇阳: Hi, I am facing a error in the bandstructure with the commandline x spaghetti.My compiler is gfortran and openblas in Ubuntu.Program input is: "" At line 37 of file inview.f (unit = 5, file = 'TiC_2.insp') Fortran runtime error: Bad real number in item 2 of list input Error termination. Backtrace: #0 0x14c33ec23960 in ??? #1 0x14c33ec244d9 in ??? #2 0x14c33ec2510f in ??? #3 0x14c33ee701b6 in ??? #4 0x14c33ee715fd in ??? #5 0x14c33ee722aa in ??? #6 0x55d306f3fc93 in ??? #7 0x55d306f43ef2 in ??? #8 0x55d306f3731e in ??? #9 0x14c33e829d8f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x14c33e829e3f in __libc_start_main_impl at ../csu/libc-start.c:392 #11 0x55d306f37344 in ??? #12 0x in ??? 0.083u 0.015s 0:00.09 100.0%0+0k 0+16io 0pf+0w error: command /home/xyy/wien2k/spaghetti spaghetti.def failed Could you help me to solve it? Thank you very much! Best wishes! ___ 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 Email: peter.bl...@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] semicore band ranges too large error: for MoSi2N4
Well, at the end it is exactly as I said: Your manual RMT settings are very bad. One of the rules is, that smallest and largest RMTs must not be too different. With your spheres you get "effective" R(Si)Kmax of more than 12 and this gives numerical linear dependency. With your struct file: RMT(N)=1.2 (Si)=2.1 init set RKmax=7 run > gives the semicore error you describe due to some ghostbands. init run save rkm6 set RKmax=7 run ---> runs through and converges. However, increasing RKmax to 8 gives ghost bands again. - setrmt cp case.struct_setrmt case.struct ( similar RMTs for Si and N, around 1.6) init -ecut -8 (to avoid core leakage) set rkmax=7 run ---> converges without problems. One can increase Rkmax further to 8 and even 9. -- PS: These ghostbands are located in the interstital, give no qtl-b errors. Once such a state is taken into the density, you get these "select"-errors. Am 14.11.2023 um 19:19 schrieb hajar.nejatipoor--- via Wien: Dr. Blaha sometimes, *semicore* error appears in iteration3, sometime in 6, and ... (with changing rmts). I tried with the struct attached here and the default init_lapw. After finalized initialization, I changed RKm=7 (and Emax=3) in case.in1c attached here, and run dstart. This time, semicore error was appeared in the *first* iteration! I have been confused why? (I see that default init_lapw for above setting (RKm=7 and Emax=3)) contains 24 kpoints. and error is appeared. (In another scf with above struct (RKm=7 and Emax=1.5), default number of kpoints was 7! ). and scf ended successfully. May this error be dependent on the number of k-point and the number of cores in .machines file? .machines file in two calculations contained 7 cores. On Tuesday, November 14, 2023 at 03:08:50 PM GMT+3:30, Peter Blaha wrote: Again, your message gets too big. You must delete the older content. --- grep :DIS in case.scf: :DIS : CHARGE DISTANCE ( 0.0122755 for atom 3 spin 1) 0.0083335 :DIS : CHARGE DISTANCE ( 0.0117894 for atom 3 spin 1) 0.0077543 :DIS : CHARGE DISTANCE ( 0.0405700 for atom 1 spin 1) 0.0200036 :DIS : CHARGE DISTANCE ( 0.2010006 for atom 1 spin 1) 0.0741310 :DIS : CHARGE DISTANCE ( 0.0164221 for atom 1 spin 1) 0.0107305 :DIS : CHARGE DISTANCE ( 0.1052329 for atom 1 spin 1) 0.0370176 :DIS : CHARGE DISTANCE ( 0.0075476 for atom 1 spin 1) 0.0021153 :DIS : CHARGE DISTANCE ( 0.0848258 for atom 1 spin 1) 0.0300654 :DIS : CHARGE DISTANCE ( 0.0018758 for atom 1 spin 1) 0.0007564 :DIS : CHARGE DISTANCE ( 0.0008796 for atom 3 spin 1) 0.0006306 :DIS : CHARGE DISTANCE ( 0.0013281 for atom 3 spin 1) 0.0008331 after iteration 3, the semicore error is appeared for rkm=7. -- Nobody knows what you were sending. Is this from the RKM=6 calculation ? You have done a scf with RKmax=6. This should be saved. Then you have an empty scffile, and you should increase RKmax to 7 and run the scf. If the error occurs after iteration 3, we expect to see exactly 3 lines. ??? Did you ever save the rkm6 results ? restore them in a new directory, increase rkmax and then run_lapw. When it crashes, show us :dis. -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.at <mailto:peter.bl...@tuwien.ac.at> WIEN2k: http://www.wien2k.at <http://www.wien2k.at> WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at> - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at <mailto:Wien@zeus.theochem.tuwien.ac.at> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <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 <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 -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at - _
[Wien] wien2k workshop
Dear wien2k users, This is just a reminder that the deadline for "financial support" ends 18.November 2023 !!! Of course the registration keeps open for those who do not need extra support. For more info follow the workshop links on www.wien2k.at Peter Blaha -- ------ Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] Speed of cluster nodes
Am 14.11.2023 um 14:24 schrieb pluto via Wien: Dear Prof. Blaha, Reducing the energy window in case.inso seems to work, but there are some minor issues. I would like to clarify them. Normally I run the sequence: x lapw1 -band -up -p x lapw1 -band -dn -p x lapwso -up -p x qtl -up -p -band -so x qtl -dn -p -band -so When I limit the range a lot in case.inso before starting this sequence, I don't have Fermi energy in the case.scf2up/dn (I paste such "bad" file below). This then leads to an error when running "x qtl". This sequence is ok. Note, the x qtl step will automatically recalculate x lapw2 -fermi -so ..., so you get a new case.scf2up/dn file. When you get as EF, something must be wrong. When you reduce Emin in case.inso, you also have to adjust properly the number of electrons NOE in case.in2c (Check from the band ranges in case.output2 of a "normal" calculation how many bands you will cut away and reduce NOE accordingly). In any case, EF will be wrong since your k-mesh is not a regular one. And of course Emax must still be large enough to cover all electrons ... It seems there is no error when first running "x lapw1 up/dn" and "x lapwso" with the default case.inso, then limiting the range in case.inso, and then re-running only "x lapwso". When you rerun x lapwso with modified inso file, all previous data from the lapwso step are overwritten. What you describe is not possible. PS: "x qtl" needs case.in1c for running correctly. So, if that file does not exist then I simply make a copy of the case.in1. Is that OK? Yes. TEMP.-SMEARING WITH 0.00200 Ry -S / Kb = -6.57973595 -(T*S)/2 = -0.00328987 Chem Pot = Bandranges (emin - emax) and occupancy: Energy to separate low and high energystates: 0.39949 :NOE : NUMBER OF ELECTRONS = 1440.000 :FER : F E R M I - ENERGY(FERMI-SM.)= ** :GMA : POTENTIAL AND CHARGE CUT-OFF 16.00 Ry**.5 On 2023-11-11 18:20, Peter Blaha wrote: For your problem, you just need to reduce the Energy window in case.inso when you do the fine k-mesh (no scf with this k-mesh). Make sure, your emin does not cut bands, but falls in a "gap". Usually, all k-points take the same time (within 10 % or so). It looks more as if one node is (temporarely) overloaded or has network (disk) problems. Try to check it by logging into this node and use eg. "top". Am 10.11.2023 um 18:53 schrieb pluto via Wien: Dear Prof. Blaha, dear All, Thank you for you comment. When changing numbers as you suggested the convergence over few cycles didn't look very good. So I decided to redo the calculation with init_lapw -prec 1 -ecut 0.999, I think this is safer and I hope the files will be smaller. Once this is done, I will try to reduce emax in case.inso. The origin of the problem is that I would like to make a kx-ky mesh for the slab, this means maybe 2000-3000 kpoints to see bands as surfaces nicely. Then the output files become very large, and case.qtl files are large too (I typically do a SOC and FM calculation). One can limit the energy range in case.inq to e.g. from -1 to 1, but this sometimes (for unknown reasons) leads to some counting issues of the bands, i.e. different k-points have different bands order. This might be related to the lower energy cutting though a band, but some time ago I tried different ranges in case.inq and it was not very helpful (but I need to try more). Anyway, not a big deal, in the end this can be sorted out in many ways. In general most of the time I only need bands from say -10 to 10 eV around the Fermi level, so in general it is good to learn how to calculate only that, perhaps increasing the calculation speed and reducing the output file sizes. Another question: I often run on the older cluster. All nodes should be the same and I distribute k-points uniformly (e.g. 8 k-points per node). I noticed that sometimes some nodes are calculating much slower (e.g. lapw1 or lapwso) than other nodes. Is that normal? I would expect maybe small fluctuations due to the particular CPU cooling efficiency etc., but nothing dramatic. Or perhaps sometimes some k-points need more time? Best, Lukasz On 2023-11-07 18:42, Peter Blaha wrote: I'm not quite sure what you mean. restore your saved calculation and: i) Reduce emax in case.inso This reduces the size of case.vectorso, but has no influence on the scf. (One iteration is enough). ii) reduce Ecut in case.in1. However, this will make your spinorbit calculation much less accurate. You need to run the scf, but it should converge quicker . Am 07.11.2023 um 18:26 schrieb pluto via Wien: Dear All, I have a larger FM-SOC calculation converged (and saved) with the default Ecut. I would like to converge with smaller E
Re: [Wien] semicore band ranges too large error: for MoSi2N4
Again, your message gets too big. You must delete the older content. --- grep :DIS in case.scf: :DIS : CHARGE DISTANCE ( 0.0122755 for atom3 spin 1) 0.0083335 :DIS : CHARGE DISTANCE ( 0.0117894 for atom3 spin 1) 0.0077543 :DIS : CHARGE DISTANCE ( 0.0405700 for atom1 spin 1) 0.0200036 :DIS : CHARGE DISTANCE ( 0.2010006 for atom1 spin 1) 0.0741310 :DIS : CHARGE DISTANCE ( 0.0164221 for atom1 spin 1) 0.0107305 :DIS : CHARGE DISTANCE ( 0.1052329 for atom1 spin 1) 0.0370176 :DIS : CHARGE DISTANCE ( 0.0075476 for atom1 spin 1) 0.0021153 :DIS : CHARGE DISTANCE ( 0.0848258 for atom1 spin 1) 0.0300654 :DIS : CHARGE DISTANCE ( 0.0018758 for atom1 spin 1) 0.0007564 :DIS : CHARGE DISTANCE ( 0.0008796 for atom3 spin 1) 0.0006306 :DIS : CHARGE DISTANCE ( 0.0013281 for atom3 spin 1) 0.0008331 after iteration 3, the semicore error is appeared for rkm=7. -- Nobody knows what you were sending. Is this from the RKM=6 calculation ? You have done a scf with RKmax=6. This should be saved. Then you have an empty scffile, and you should increase RKmax to 7 and run the scf. If the error occurs after iteration 3, we expect to see exactly 3 lines. ??? Did you ever save the rkm6 results ? restore them in a new directory, increase rkmax and then run_lapw. When it crashes, show us :dis. -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@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] semicore band ranges too large error: for MoSi2N4
I used exactly the struct file you sent (with your RMTs, even if I would not choose them this way). init -prec 1n run_lapw save rkm6 edit case.in1 to change RKmax run_lapw no problems. I do not understand, how you can get your error: (SELECT E-top/bottom not found) when you just change RKMAX. RKmax has nothing to do with finding E-parameters. Does it happen immediately after increasing RKmax ? or after a few iterations. How is :DIS in this case ? Am 14.11.2023 um 10:17 schrieb hajar.nejatipoor--- via Wien: Yes, I use WIEN2k_23.2 Let me know how are rmt of atoms in structure file which you used. Sent from Yahoo Mail on Android <https://mail.onelink.me/107872968?pid=nativeplacement=Global_Acquisition_YMktg_315_Internal_EmailSignature_sub1=Acquisition_sub2=Global_YMktg_sub3=_sub4=10604_sub5=EmailSignature__Static_> On Tue, Nov 14, 2023 at 11:31, Peter Blaha wrote: As I wrote before: I cannot reproduce this. For me it converges fine even with RKmax=7. No errors. Thus, I don't know how to help you. Are you using WIEN2k_23.2 ?? Am 13.11.2023 um 15:39 schrieb hajar.nejatipoor--- via Wien: > Dear Dr. Blaha > I act as you said, but the problem "LAPW2' - semicore band-ranges too > large, ghostbands" exists again!! > LO for N-2s orbitals in case.in1c were removed, but it worked just for > rkm=6 (with or without LO for N). > I tried your way with changing rmt of atoms but the problem remained. > > I tried a normal scf with RKm=7, from the beginning, at a different > directory, but nothing was changed. Just, crashing LAPW2 is postponed in > some more cycles. > On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha > mailto:peter.bl...@tuwien.ac.at>> wrote: > > > I tried your struct file, converged with RKM=6, saved, increased RKMax > to 7 and continued with run_lapw. > No problem. As expected with your RMTs rather small change from 6 to 7 > and quick convergence. > > You must have changed something else, like mixing a density with > different RMTs, > > > Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien: > > Dear Dr. Blaha > > The way you proposed, just worked for RKm=6, and the error below > > appeared for the case of RKm=7: > > 'SELECT' - no energy limits found for atom 1 L= 0 > > 'SELECT' - E-bottom -520.0 E-top -520.0 > > > > It is worth to mention that since for Si-muffin tin radius 1.68, there > > is a huge charge leak out, I set the muffin tin raddii as: > > > > 1 42.0 2.12 2.2 > > 2 14.0 1.68 2.1 > > 3 7.0 1.61 1.2 > > 4 7.0 1.60 1.2 > > > > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha > > mailto:peter.bl...@tuwien.ac.at> <mailto:peter.bl...@tuwien.ac.at>> wrote: > > > > > > First of all, setrmt gives: > > 1 42.0 2.12 2.12 > > 2 14.0 1.68 1.68 > > 3 7.0 1.61 1.60 > > 4 7.0 1.60 1.60 > > > > So the N radii are much larger and Si and Mo smaller. > > > > It might be that the ghostband comes from N-2s, as the small RMT may not > > allow for 2 radial functions. You could try to remove the LO for N-s > > (only keep: > > 0.30 2 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global > > APW/LAPW) > > 0 -1.07 0.0010 CONT 1 > > 1 0.30 0. CONT 1 > > for the N atoms (maybe use instead a HDLO). > > > > > > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien: > > > MoSi2N4 > > > H LATTICE,NONEQUIV.ATOMS: 4 187_P-6m2 > > > MODE OF CALC=RELA unit=bohr > > > 5.502431 5.502431 38.534460 90.00 90.00120.00 > > > ATOM -1: X=0. Y=0. Z=0. > > > MULT= 1 ISPLIT= 4 > > > Mo1 NPT= 781 R0=0.1000 RMT= 2.2000 Z: 42.000 > > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > > 0.000 1.000 0.000 > > > 0.000 0.000 1.000 > > > ATOM -2: X=0. Y=0.3334 Z=0.14710600 > > > MULT= 2 ISPLIT= 4 > > > -2: X=0.6668 Y=0.3334 Z=0.85289400
Re: [Wien] semicore band ranges too large error: for MoSi2N4
As I wrote before: I cannot reproduce this. For me it converges fine even with RKmax=7. No errors. Thus, I don't know how to help you. Are you using WIEN2k_23.2 ?? Am 13.11.2023 um 15:39 schrieb hajar.nejatipoor--- via Wien: Dear Dr. Blaha I act as you said, but the problem "LAPW2' - semicore band-ranges too large, ghostbands" exists again!! LO for N-2s orbitals in case.in1c were removed, but it worked just for rkm=6 (with or without LO for N). I tried your way with changing rmt of atoms but the problem remained. I tried a normal scf with RKm=7, from the beginning, at a different directory, but nothing was changed. Just, crashing LAPW2 is postponed in some more cycles. On Sunday, November 12, 2023 at 08:42:25 PM GMT+3:30, Peter Blaha wrote: I tried your struct file, converged with RKM=6, saved, increased RKMax to 7 and continued with run_lapw. No problem. As expected with your RMTs rather small change from 6 to 7 and quick convergence. You must have changed something else, like mixing a density with different RMTs, Am 12.11.2023 um 07:30 schrieb hajar.nejatipoor--- via Wien: > Dear Dr. Blaha > The way you proposed, just worked for RKm=6, and the error below > appeared for the case of RKm=7: > 'SELECT' - no energy limits found for atom 1 L= 0 > 'SELECT' - E-bottom -520.0 E-top -520.0 > > It is worth to mention that since for Si-muffin tin radius 1.68, there > is a huge charge leak out, I set the muffin tin raddii as: > > 1 42.0 2.12 2.2 > 2 14.0 1.68 2.1 > 3 7.0 1.61 1.2 > 4 7.0 1.60 1.2 > > On Saturday, November 11, 2023 at 10:43:42 PM GMT+3:30, Peter Blaha > mailto:peter.bl...@tuwien.ac.at>> wrote: > > > First of all, setrmt gives: > 1 42.0 2.12 2.12 > 2 14.0 1.68 1.68 > 3 7.0 1.61 1.60 > 4 7.0 1.60 1.60 > > So the N radii are much larger and Si and Mo smaller. > > It might be that the ghostband comes from N-2s, as the small RMT may not > allow for 2 radial functions. You could try to remove the LO for N-s > (only keep: > 0.30 2 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global > APW/LAPW) > 0 -1.07 0.0010 CONT 1 > 1 0.30 0. CONT 1 > for the N atoms (maybe use instead a HDLO). > > > Am 11.11.2023 um 19:26 schrieb hajar.nejatipoor--- via Wien: > > MoSi2N4 > > H LATTICE,NONEQUIV.ATOMS: 4 187_P-6m2 > > MODE OF CALC=RELA unit=bohr > > 5.502431 5.502431 38.534460 90.00 90.00120.00 > > ATOM -1: X=0. Y=0. Z=0. > > MULT= 1 ISPLIT= 4 > > Mo1 NPT= 781 R0=0.1000 RMT= 2.2000 Z: 42.000 > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > ATOM -2: X=0. Y=0.3334 Z=0.14710600 > > MULT= 2 ISPLIT= 4 > > -2: X=0.6668 Y=0.3334 Z=0.85289400 > > Si1 NPT= 781 R0=0.0001 RMT= 2.1000 Z: 14.000 > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > ATOM -3: X=0. Y=0.6667 Z=0.82807700 > > MULT= 2 ISPLIT= 4 > > -3: X=0.3334 Y=0.6667 Z=0.17192300 > > N 1 NPT= 781 R0=0.0001 RMT= 1.2000 Z: 7.000 > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > ATOM -4: X=0. Y=0.3334 Z=0.93855400 > > MULT= 2 ISPLIT= 4 > > -4: X=0.6668 Y=0.3334 Z=0.06144600 > > N 2 NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 7.000 > > LOCAL ROT MATRIX: 1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > -- > -- > Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna > Phone: +43-1-58801-165300 > Email: peter.bl...@tuwien.ac.at <mailto:peter.bl...@tuwien.ac.at> <mailto:peter.bl...@tuwien.ac.at> > WIEN2k: http://www.wien2k.at <http://www.wien2k.at> <http://www.wien2k.at <http://www.wien2k.at>> > WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at> <http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at>> > > -
