[Wien] Superposition of charged atoms
Dear WIEN2k users, I have a somewhat strange question: I have read (and tested) the advice in the FAQ concerning charged cells. The according HowTo leads to a "charged cell SCF" which is not want I want. What I want is somewhat simpler, namely a superposition of independent charged atoms which in sum form a neutral cell, i.e. create a new_super.clmsum of non-interacting Na+0.4 and Cl-0.4 atoms, for example. As described in the FAQ, messing around with the case.inst to create the cation works, but fails when trying to include the anion in the same way. Is there any other trick to do this in Wien2k? Thanks in advance and best regards, Georg Eickerling ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] init_lapw in batch mode
Dear WIEN2k users, I want to report a minor issue in init_lapw I just encountered: When invoking init_lapw in batch mode (WIEN 19.1) and using params like lmax beyond their limits, the params are re-set to sane values and lines like echo lvns set to maximal value (10) try to give some feedback to the user about it. This fails for example on Ubuntu 18.04.2 LTS where csh is sym-linked to tcsh 6.20.00 with the message Badly placed ()'s. and init_lapw stops. The simple fix is to use quotes for the arguments echo 'lvns set to maximal value (10)' regards, Georg Eickerling ___ 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] NaN output in lapw3 17.1
On 01.06.2018 16:17, Peter Blaha wrote: > A bit strange, but it seems it can happen for certain cases. Yes, I agree. > b) Therefore my expectations are that this is due to a different > compiler ?? and in the older version all variables were initialized to > zero, while they are not with the new compilation. > There were definitely different ifort versions involved, as 17.1 was compiled with intels compiler-suite 2018 and I did not recompile the old WIEN versions. So that's probably the simple explanation. > d) I would, however, suggest a different fix, because in case there was > no jump out (I don't know if it can happen, but anyway), you would miss > the last contribution (probably very small anyway). Instead, put > > rhouse=0.d0 right after the allocate statement. > That's obviously a better solution than just skipping a term, so I'll use that. > Thanks for the report and the analysis. Thank you for the immediate response! > > > On 06/01/2018 03:40 PM, Georg Eickerling wrote: >> Dear WIEN users, >> >> I found a possible issue with lapw3 in WIEN 17.1. >> >> The bottom line is, that in some cases lapw3 from 17.1 instead of >> values for >> Fs produces this in the output: > >> My debugging results: >> == >> >> I found that the problem is triggered when the trimming of the INDMAX >> values >> happens in fourir.frc starting from line 170. >> >> In my particular case, INDMAX = 36353 >> this gets trimmed down to nuse = 21889 >> >> However, the last value for rhouse(NUSE) I saw created in line 195 >> >> rhouse(NUSE)=RHOK(IIZ)/INST(IIZ)*TAUK(KP) >> >> was >> >> NUSE rhouse(NUSE) >> 21888 -1.357441708557500E-010 >> >> so that later >> >> DO 35 KP=1,NUSE >> F=F+RHOUSE(KP)*U >> 35 ENDDO >> >> yields NaN, because RHOUSE(21889) is missing. >> >> On the other hand, in line 175 I see >> >> allocate(rhouse(INDMAX)) >> >> so I assume the array is initialized large enough and lapw3 can read >> "something" from it for the N+1 element? >> >> I.e., for my diamond case, the according numbers are >> indmax 2229 >> nuse 1105 >> >> the last rhouse created in 195: >> >> NUSE rhouse(NUSE) >> 1104 7.02105129166E-010 >> >> so that in this case (by conincidence?): >> >> rhouse(nuse) = 0.000E+000 >> >> and the case works. >> >> >> The fix for me up to now was a >> >> DO 35 KP=1,NUSE-1 >> >> to make it work for my original case with 17.1. >> >> Any thoughts on this from the experts? >> >> >> best regards, >> >> >> Georg Eickerling >> >> >> >> >> >> >> >> >> >> >> >> >> ___ >> 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 >> > -- PD Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerl...@physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ = ___ 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] NaN output in lapw3 17.1
Dear WIEN users, I found a possible issue with lapw3 in WIEN 17.1. The bottom line is, that in some cases lapw3 from 17.1 instead of values for Fs produces this in the output: X - RAY STRUCTURFACTORS K-VECTOR SIN O/L (A-1)F 000 0.000 NaN 0 -10 0.0490923 NaN -100 0.0951928 NaN 0 -20 0.0981846 NaN This happens only in some special cases as it seems: 1. lapw3 from WIEN 14.2 on the same set of files: = X - RAY STRUCTURFACTORS K-VECTOR SIN O/L (A-1)F 000 0.000 171.994533 0 -10 0.04909230.00 -100 0.09519280.00 0 -20 0.0981846 -15.8811296486 => the clmsum seems to be "intact", there are indeed 172 electrons in my cell. 2. lapw3 from 17.1 for a 17.1 calculation on diamond: = X - RAY STRUCTURFACTORS K-VECTOR SIN O/L (A-1)F 000 0.000 11.999251 -1 -1 -1 0.2427814 -4.6602717246 00 -2 0.2803398 -0.00 0 -2 -2 0.3964603 -3.9467736723 -1 -1 -3 0.4648909 -2.3980119816 -2 -2 -2 0.48556270.2291402630 => my lapw3 binary from 17.1 is working in this case 3. run lapw3 from 17.1 on 13.1 calculation of the same compound: X - RAY STRUCTURFACTORS K-VECTOR SIN O/L (A-1)F 000 0.000 171.994164 0 -10 0.0494237 -0.00 -100 0.0960836 -0.00 0 -20 0.0988474 -15.6330077799 => cross-check on my lapw3 binary also works What I can also tell is, that the atomic contributions in output3 from my 17_1 calculation also look OK: 0 0 0 0. 19.4565 19.4565 => that's a scandium atom or 0 0 0 0. 4.1588 4.1588 => that's a carbon atom and the values compare quite well with the ones from the "old" lapw3, but starting from here: STRUCTURFACTORS FOR OUT: Number of hkl trimmed down to 21889 000 NaN 0. 0 -10 NaN 0.0490922829131512 -100 NaN 0.0951927607312776 0 -20 NaN 0.0981845658263024 things break in the output. My debugging results: == I found that the problem is triggered when the trimming of the INDMAX values happens in fourir.frc starting from line 170. In my particular case, INDMAX = 36353 this gets trimmed down to nuse = 21889 However, the last value for rhouse(NUSE) I saw created in line 195 rhouse(NUSE)=RHOK(IIZ)/INST(IIZ)*TAUK(KP) was NUSErhouse(NUSE) 21888 -1.357441708557500E-010 so that later DO 35 KP=1,NUSE F=F+RHOUSE(KP)*U 35ENDDO yields NaN, because RHOUSE(21889) is missing. On the other hand, in line 175 I see allocate(rhouse(INDMAX)) so I assume the array is initialized large enough and lapw3 can read "something" from it for the N+1 element? I.e., for my diamond case, the according numbers are indmax 2229 nuse 1105 the last rhouse created in 195: NUSErhouse(NUSE) 1104 7.02105129166E-010 so that in this case (by conincidence?): rhouse(nuse) = 0.000E+000 and the case works. The fix for me up to now was a DO 35 KP=1,NUSE-1 to make it work for my original case with 17.1. Any thoughts on this from the experts? best regards, Georg Eickerling ___ 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] Poisson and clmsum
Dear Wien users, now I have to join this thread, because this last piece of information sounds interesting also to me. I am doing topological analyses of electron densities/Laplacians via WIEN2k and the discontinuities at the MT radii spoil basically any nabla² rho(r) map one tries to make with WIEN2k. I have tried many things (large RKMAX, lmax, APW vs. LAPW) but tiny steps at the MT boundary remain in rho(r) and therefore in all its derivatives. The information about generating a ".lcore" file is new to me - what does this file actually do if it exists and when should it be generated, already for the init or the scf step? best regards Georg Eickerling On 11/22/2016 07:51 PM, Laurence Marks wrote: > N.B., there can also be a discontinuity in the charge (small) due to the > tails of the core states which can be eliminated by doing "touch .lcore". > > On Mon, Nov 21, 2016 at 8:36 AM, Laurence Marks > wrote: > >> APW+lo methods have a step in the gradient of the density at the RMT. To >> avoid this use a lapw basis set: to reduce it increase RKMAX. >> >> --- >> Professor Laurence Marks >> "Research is to see what everybody else has seen, and to think what nobody >> else has thought", Albert Szent-Gyorgi >> http://www.numis.northwestern.edu >> Corrosion in 4D http://MURI4D.numis.northwestern.edu >> Partner of the CFW 100% gender equity project, www.cfw.org/100-percent >> Co-Editor, Acta Cryst A >> >> >> On Nov 21, 2016 07:39, "John Rundgren" wrote: >> >>> Dear Peter Blaha and Gavin Abo, >>> >>> Non-overlapping muffin-tin spheres are used by WIEN2k and my LEED program >>> eeasisss (Elastic Electron-Atom Scattering in Solids and Surface Slabs). >>> But RMT(setrmt_lapw) is not automatically the best choice for >>> RMT(eeasisss). LEED touching radii of atoms depend on exchange-correlation >>> interaction between crystal electron gas (the WIEN2k electrons) and an >>> incident LEED electron (energy 20-500 eV). >>> >>> This is a N+1 electron scattering situation, where "N" signifies the >>> WIEN2k electrons and "1" an alien LEED electron. >>> >>> W2k can be reconciled with LEED using an atomic sphere approximation >>> (ASA) extending into the Fourier expansion realm of W2k. A while ago you >>> (P.B. and G.A.) suggested an ASA routine, in which I now use Poisson >>> differentiation of vcoul_ASA in order to obtain clmsum_ASA. I consider the >>> case LM=(0,0), sufficient for current LEED. >>> >>> The considered structure is a supercell = a surface slab 15 layers thick, >>> where layers 1-2 and 14-15 are C-O and O-C, respectively. Mirror symmetry >>> about layer 8. At the C-O layers vcoul_ASA(0,0) is continuous across the >>> RMT radius, but clmsum_ASA(0,0) versus radius shows a step of the order of >>> 10%. >>> >>> Is the step k-point dependent? It does not seem so. With 16 and 48 >>> k-points the clmsum_ASA(0,0) steps are preserved within 6 digits. >>> >>> I shall be glad to supply the code. When the described numerical error is >>> fixed, WIEN2k and eeasisss can be re-run self-consistently within the model >>> of non-overlapping muffin-tin atoms. >>> >>> Regards, >>> John Rundgren >>> >>> KTH >>> >>> >>> >>> > > > > > ___ > 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 > -- PD Dr. Georg Eickerling Universität Augsburg Institut für Physik Lehrstuhl für Chemische Physik und Materialwissenschaften Universitätsstr. 1 86159 Augsburg E-Mail: georg.eickerl...@physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ = ___ 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] The mail to wien2k mailing list.
> Do you really run WIEN2k in Windows 8 OS?! > I doubt it looking at the commands that are used: head, cat, tail, cp, rm, sed, time... But anyways, I think WIEN itself is quite verbose on timings. Are you sure you need more information than is given already? Looking in for example case.output1 I see things like Time for al,bl(hamilt, cpu/wall) : 0.2 0.1 Time for legendre (hamilt, cpu/wall) : 0.3 0.2 Time for phase(hamilt, cpu/wall) : 1.2 1.1 Time for us (hamilt, cpu/wall) : 3.3 1.7 Time for overlaps (hamilt, cpu/wall) : 0.8 0.8 Time for distrib (hamilt, cpu/wall) : 0.2 0.2 Time sum iouter (hamilt, cpu/wall) : 6.1 4.3 number of local orbitals, nlo (hamilt) 124 allocate YL 2.8 MB dimensions15 2913 4 allocate phsc 0.0 MB dimensions 2913 Time for los (hamilt, cpu/wall) : 0.3 0.2 Time for alm (hns) : 0.3 Time for vector (hns) : 2.2 Time for vector2 (hns) : 2.1 Time for VxV (hns) : 7.4 Wall Time for VxV(hns) : 0.1 In case.output2 there is =>>> CPU TIME SUMMARY TOTAL :563.5 ... 100. PERCENT PART FERMI : 0.2 ... 0. PERCENT PART CLM:517.0 ... 92. PERCENT PART FOURIR : 46.3 ... 8. PERCENT =>>> WALL TIME SUMMARY TOTAL :352.4 ... 100. PERCENT PART FERMI : 0.2 ... 0. PERCENT PART CLM:305.9 ... 87. PERCENT PART FOURIR : 46.3 ... 13. PERCENT So even the sub-steps are printed and finally, in the case.dayfile you get > lapw0 (08:04:23) 7.516u 0.032s 0:07.64 98.6% 0+0k 0+5120io 0pf+0w > lapw1 (08:04:31) 10444.316u 116.259s 47:57.92 366.9% 0+0k > 0+1223432io 0pf+0w > lapw2 (08:52:29) 565.815u 17.037s 5:53.52 164.8% 0+0k 0+6080io > 0pf+0w > lcore (08:58:22) 0.044u 0.000s 0:00.04 100.0% 0+0k 0+552io 0pf+0w > mixer (08:58:23) 0.772u 0.032s 0:00.52 153.8% 0+0k 0+8616io 0pf+0w for each cycle and sub-step in the SCF which seems to be exactly the output you want to generate by your time command? And to answer your specific question: You need to check whether "wien2k.32bits.in0" really exists, the missing "unit 5" is the in0 file as the error message states. Hint: The steps you are quoting before running lapw0 just do some search/replace/rename tricks, but won't create the input itself apart from the .def, so the question is which files this "cp *.*" includes and if the case was properly initiated by init_lapw before. cheers Georg > With regards > K. Balamurugan > > Quoting muhammed thaha hashim : > > > I am running Wien2k 32bits with windows 8 operating system . > > > > I am a grad student. My goal is evaluate the performance of Wein2k on > > distributed systems. > > > > Currently I am running Wien2k on my laptop. My goal is to find the time > > taken at various stages (lapw0, lapw1, lapw2,sumpara) in the workflow of > > wien2k. > > > > The steps that I followed are : > > > > cp atype/*.* . > > head -2 atype.in1 | split -1 > > cat xab | sed "s/.\../5.5/g" >> xaa > > tail -24 atype.in1 >> xaa > > cat xaa > atype.in1 > > rm xa* > > time -p x -d lapw0 > > time -p lapw0 lapw0.def > > > > time -p x -d lapw0 generates lapw0.def. But, time -p lapw0 lapw0.def > > produces a single line of error namely LAPW0 - Error. > > > > The content of lapw0.error is as follows > > > > 'LAPW0' - can't open unit: > > 5 > > 'LAPW0' -filename: > > wien2k.32bits.in0 > > 'LAPW0' - status: old form: formatted > > > > What is the reason for this error? Could somebody please guide me through > > this. > > > ___ > 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 pgpqpfV8Quydl.pgp Description: Digitale Signatur von OpenPGP ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] lapwso and case.vectordn
Dear WIEN2k users, I am working on a "spin-orbit" case without spinpolarization at the moment (using WIEN2k_13.1 (Release 17/6/2013)). I run this in two steps, I first converge a standard "run_lapw", then "initso_lapw" and finally "run_lapw -so". I have a $SCRATCH set for my vectors and after the above mentioned cycle I see non-zero length $SCRATCH/case.vector $SCRATCH/case.vectorso as expected(?). When repeating exactly the same thing without $SCRATCH set, I get an additional case.vectorsodn (with non-zero length) in my working dir which is different from the other two. Is there something wrong with run_lapw (i.e. there is a $scratchstring passed to lapwso in run_lapw but this is empty in both of the above cases) or am I doing thing the wrong way? Thank you in advance for any help, Georg Eickerling signature.asc Description: PGP signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] How to quantify charge density (as a single value of charge density) along certain bond length ?
Hi, I guess you are asking for something like Baders QTAIM which will for example provide the density at the bond critical point (local mininum along the bond-path connecting to atoms) as a criterion? See the AIM module of WIEN2K and the external CRITIC program (listed on the wien page under software goodies) for details. regards Georg Am Wed, 15 Jan 2014 00:37:53 -0800 (PST) schrieb Masood Yousaf : > Dear Fellows > > I know how to calculate contour charge density plots for certain > planes. I want to quantify the charge density (as a single value of > charge density) in between two species i.e., along the bond length. > Kindly suggest a way to quantify the charge density. > > > Thank You > > Best wishes > Masood > Universiti Tecknologi Malaysia > ___ 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] resolution dependent F(HKL)s from lapw3 => now bug report
Dear WIEN2k users, I finally want to report the bug which is responsible for the resolution dependency of the calculated HKLs mentioned in this thread. We have tracked down the problem to the file fourir.frc and in particular to the lines 201 and 203 were the PW and the MT part of the structure factors are finally added: !_REAL STRF(K)=STRF(K)+F !_COMPLEX STRF(K)=STRF(K)+conjg(F) It turns out, that in some cases the order of the HKLs is not the same for the two components, i.e. the array KZZ (used to obtain F in the above lines) contains the HKLs in a different order than STRF(K) assumes. This bug only affects HKLs with the same sin theta/labmda, which probably indicates a rounding error problem when sorting the reflexes according to their st/l. Example: For st/l 1.1 the order of the reflexes in the MT AND the PW part is 5 -3 -5 3 -1 -7 so the result is correct. In case of st/l = 1.2 this is not true: Here, the order of the HKLs for the MT is 3 -1 -7 5 -3 -5 while in the PW part it is still -3 -5 -5 -1 -3 -7 BUT in fourir.frc lapw3 simply adds up the reflexes in the order they appear without checking for consistent HKLs - causing the errors described below. We did not track down the problem to the part were the "re-ordering" is taking place, but we fixed it in a local version by using a new array as intermediate storage for the "correct" order of HKLs. I do not append this new version here as I see this more like a workaround than a fix. regards Georg Eickerling Am 23.08.2012 08:50, schrieb Georg Eickerling: > Thank you very much for the replies! > > Here are some more details: > > Sphere part: > > st/l = 1.1: > 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 > 0.0 -0.01465 > 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 > 0.0 0.00410 > > st/l = 1.2: > 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 > 0.0 0.00410 > 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 > 0.0 -0.01465 > > st/l = 1.3: > -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 > 0.0 -0.01465 > -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 > 0.0 0.00410 > > st/l = 1.8 > -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 > 0.0 -0.01465 > -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 > 0.0 0.00410 > > PW part: > > st/l = 1.1: >-3 -5 -5 0.0665201058405473 1.0766653378172495 >-1 -3 -7 0.0345681054384858 1.0766653378172495 > > st/l = 1.2: >-3 -5 -5 0.0665201058405473 1.0766653378172495 >-1 -3 -7 0.0345681054384858 1.0766653378172495 > > st/l = 1.3: >-3 -5 -5 0.0665201058405473 1.0766653378172495 >-1 -3 -7 0.0345681054384858 1.0766653378172495 > > > stl/l = 1.8: >-3 -5 -5 0.0665201058405473 1.0766653378172495 >-1 -3 -7 0.0345681054384858 1.0766653378172495 > > > But then: > > > "Sum": > > st/l = 1.1: >-3 -5 -5 1.0766653 -1.4379800081 >-1 -3 -7 1.0766653 -1.4425910379 > > st/l = 1.2: >-3 -5 -5 1.0766653 -1.4106390375 >-1 -3 -7 1.0766653 -1.4699320085 > > st/l = 1.3: >-3 -5 -5 1.0766653 -1.4379800081 >-1 -3 -7 1.0766653 -1.4425910379 > > stl/l = 1.8: >-3 -5 -5 1.0766653 -1.4379800081 >-1 -3 -7 1.0766653 -1.4425910379 > > > > Second example at higher res (data in the order st/l =1.2, 1.3, 1.8): > > Sphere: > 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 > 0.0 0.0 > 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 > 0.0 0.0 > 0 -6 -6 1.1894 -0.8887 -0.8902 0.00212 0.0 -0.00068 > 0.0 0.0 > > PW: > 0 -6 -6 -0.0362599474060042 1.1893809383585805 > 0 -6 -6 -0.0362599474060042 1.1893809383585805 > 0 -6 -6 -0.0362599474060042 1.1893809383585805 > > Sum: > 0 -6 -6 1.18938091.7411783356 > 0 -6 -6 1.1893809 -1.8246688899 > 0 -6 -6 1.1893809 -1.8136982305 > > > This is a "default" run by the way, so I am using a GMAX of 12 which > gives st/l = 1.8. What I see in addition in output3 is this: > > KVEC0 -8 -8 IN DENSITY > LIST NOT FOUND IN GENERATED K LIST > KVEC -1 -7 -9 IN DENSITY > LIST NOT FOUND IN GENERATED K LIST > KVEC -2 -8 -8 IN DENSITY > LIST NOT FOUND IN
[Wien] Reg: bader analysis
Hi, at the end of the AIM output you should see a line similar to this: :RHOTOT for IND-ATOM 5 Z= 6.0 CHARGE: 7.30973 -1.30973 here you can see, that the atom integrated in this example has a Bader-Charge of -1.31 electrons. However, if you plan to interpret these numbers you should make sure that the Bader charges of all atoms sum to zero! This is important in order to detect mistakes in the basin-boundaries or an insufficient numerical accuracy. You can easily obtain totally useless values for these charges if you fail to locate all critical points of your basin surface. When using the CRITIC code you can in addition use the value of the integrated second derivative of the electron density (the Laplacian) as a criterion which for each basin must be zero. regards Georg Eickerling Am 23.09.2012 20:36, schrieb Tarik Ouahrani: > > > > Hi Swetarekha > Ram, > > You can use > the critic code implemented by Albero Otero de la roza > > http://azufre.quimica.uniovi.es/software.html > > > please see > these references for more information > > http://iopscience.iop.org/1402-4896/86/2/025706 > > http://www.sciencedirect.com/science/article/pii/S092145261200590X > > Tarik > > Best regards > > > > Date: Sun, 23 Sep 2012 22:59:20 +0530 > From: swetarekharam at gmail.com > To: wien at zeus.theochem.tuwien.ac.at; kanchana at iith.ac.in > Subject: [Wien] Reg: bader analysis > > Dear Wien2k users, > > > I am trying to analyse the charge transfer inside the molecule. For that I > ran the AIM programme. > I got the out put. But My doubt is, how can I get the amount of charge > transfer from the one atom to another. > > > I have seen in many paper, where people used to plot the charge density plots > with the label amount of charge transferred by the individual atom. > > I need some suggestion. > > And also I need some help regarding details about the AIM programme. > > > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] resolution dependent F(HKL)s from lapw3
Thank you very much for the replies! Here are some more details: Sphere part: st/l = 1.1: 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 st/l = 1.2: 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 st/l = 1.3: -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 st/l = 1.8 -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 PW part: st/l = 1.1: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 st/l = 1.2: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 st/l = 1.3: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 stl/l = 1.8: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 But then: "Sum": st/l = 1.1: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 st/l = 1.2: -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 st/l = 1.3: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 stl/l = 1.8: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 Second example at higher res (data in the order st/l =1.2, 1.3, 1.8): Sphere: 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 0.0 0.0 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 0.0 0.0 0 -6 -6 1.1894 -0.8887 -0.8902 0.00212 0.0 -0.00068 0.0 0.0 PW: 0 -6 -6 -0.0362599474060042 1.1893809383585805 0 -6 -6 -0.0362599474060042 1.1893809383585805 0 -6 -6 -0.0362599474060042 1.1893809383585805 Sum: 0 -6 -6 1.18938091.7411783356 0 -6 -6 1.1893809 -1.8246688899 0 -6 -6 1.1893809 -1.8136982305 This is a "default" run by the way, so I am using a GMAX of 12 which gives st/l = 1.8. What I see in addition in output3 is this: KVEC0 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -1 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC0 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -3 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -4 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -1 -5 -11 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -4 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -5 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -3 -5 -11 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC0 -4 -12 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -6 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -4 -12 IN DENSITY LIST NOT FOUND IN GENERATED K LIST Am 23.08.2012 07:37, schrieb Peter Blaha: > Thank's for the report. I'll check that. > > But in the meantime you could do some more analysis and compare the > case.output3 files of two different runs. > Are the differences coming from inside the spheres or from the > interstital > region ? (I expect the latter !) > > Am 22.08.2012 18:32, schrieb Georg Eickerling: >> Dear WIEN users, >> >> I noticed a strange behavior of lapw3 which I do not understand: >> >> Take for example a simple diamond case and calculate structure >> factors from clmsum, lets say up to sin theta/lambda = 1.0: >> >> 000 0.000 12.251726 >> -1 -1 -1 0.2427814 -4.6536716863 >> 00 -2 0.28033980.00 >> 0 -2 -2 0.3964603 -3.9459734623 >> -1 -1 -3 0.4648909 -2.3988162763 >> -2 -2 -2 0.48556270.2266152403 >> 00 -4 0.5606796 -3.12975
[Wien] resolution dependent F(HKL)s from lapw3
Dear WIEN users, I noticed a strange behavior of lapw3 which I do not understand: Take for example a simple diamond case and calculate structure factors from clmsum, lets say up to sin theta/lambda = 1.0: 000 0.000 12.251726 -1 -1 -1 0.2427814 -4.6536716863 00 -2 0.28033980.00 0 -2 -2 0.3964603 -3.9459734623 -1 -1 -3 0.4648909 -2.3988162763 -2 -2 -2 0.48556270.2266152403 00 -4 0.5606796 -3.1297582248 -1 -3 -3 0.61098642.2069300710 0 -2 -4 0.62685880.00 -2 -2 -4 0.68668942.8777607788 -3 -3 -3 0.72834411.9393120414 -1 -1 -5 0.72834411.9663566686 0 -4 -4 0.79292062.6458269883 -1 -3 -5 0.82925621.8056937118 -2 -4 -4 0.8410193 -0.0171687161 00 -6 0.84101930.00 0 -2 -6 0.88651222.4363270068 -3 -3 -5 0.9191554 -1.6841664183 -2 -2 -6 0.9297818 -0.0087306004 -4 -4 -4 0.9711255 -2.2589221048 Repeating this calculation with sin theta/lambda = 1.1 and a diff with the old hkl will just show the additional reflections as expected: diff hkl.10 hkl.11 20a21,26 >-1 -5 -5 1.00101321.6970975057 >-1 -1 -7 1.00101321.5391902602 > 0 -4 -6 1.01077940.00 >-2 -4 -6 1.0489354 -2.0944311378 >-3 -5 -5 1.0766653 -1.4379800081 >-1 -3 -7 1.0766653 -1.4425910379 Now again repeat the calculation with sin theta/lambda = 1.2: diff hkl.11 hkl.12 25,26c25,32 <-3 -5 -5 1.0766653 -1.4379800081 <-1 -3 -7 1.0766653 -1.4425910379 --- >-3 -5 -5 1.0766653 -1.4106390375 >-1 -3 -7 1.0766653 -1.4699320085 > 00 -8 1.12135911.9443586030 >-3 -3 -7 1.14734001.3618747163 >-4 -4 -6 1.15587050.0030399053 > 0 -2 -8 1.15587050.00 > 0 -6 -6 1.18938091.7411783356 >-2 -2 -8 1.1893809 -1.8133181764 What happens here? Why are reflections which were exactly the same before suddenly different? Why I worry about this is, that if you go on increasing the resolution, the differences become more severe than in the example above, i.e. sin theta/lambda = 1.3: diff hkl.12 hkl.13 21,22c21,22 <-1 -5 -5 1.00101321.6970975057 <-1 -1 -7 1.00101321.5391902602 --- >-1 -5 -5 1.0010132 -1.5542465484 >-1 -1 -7 1.00101321.5480881986 On the other hand, the differences "converge" for a given reflection but more and more become "affected", i.e. sin theta/lambda = 1.8 vs. 1.2: diff hkl.12 hkl.18 21,22c21,22 <-1 -5 -5 1.00101321.6970975057 <-1 -1 -7 1.00101321.5391902602 --- >-1 -5 -5 1.0010132 -1.5542465484 >-1 -1 -7 1.00101321.5480881986 25,26c25,26 <-3 -5 -5 1.0766653 -1.4106390375 <-1 -3 -7 1.0766653 -1.4699320085 --- >-3 -5 -5 1.0766653 -1.4379800081 >-1 -3 -7 1.0766653 -1.4425910379 28c28 <-3 -3 -7 1.14734001.3618747163 --- >-3 -3 -7 1.1473400 -1.3370357923 31c31 < 0 -6 -6 1.18938091.7411783356 --- > 0 -6 -6 1.1893809 -1.8136982305 Looking at the result of a refinement of a structural model against the different HKLs, the "high resolution version" seems to be "wrong" compared to the low-res one. Thank you very much in advance for any comments on this. regards Georg Eickerling -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] Seg Fault during Bandstructure Calculation
Dear Prof. Blaha, On 27.04.2012 08:53, Peter Blaha wrote: > So this is some information. > > In spag.f NKP is originally set to 1000. > > Thus you have more than 1000 k-points in case.klist_band for your > spaghettis ? > > If this is true, increase NKP such that the doreallocate should not be > called > (and thus the error should not appear. > Increasing nkp indeed fixed it for me. Thank you and best regards, Georg Eickerling > > Am 27.04.2012 08:15, schrieb Georg Eickerling: >> Update from my side: >> >> I already did some debugging and the crash happens for me in spag.f >> (line 128) when doing >> >> call doreallocate ( ngrp,4,NEVL,NKP) >> >> while reading-in the Kpoints from output1 and spaghetti enters these >> allocation steps because of the condition >> >> n_kpt.gt.nkp >> >> regards >> >> Georg Eickerling >> >> >> On 27.04.2012 07:39, Georg Eickerling wrote: >>> OK, so I also tried recompiling with O0 and it did not change anything: >>> >>> $ make clean >>> rm -f reallocate.o modules.o bndind.o bz_lin.o cartco.o clipin.o >>> comprel.o con_ev.o defins.o drawt.o get_ei.o get_k.o inview.o movet.o >>> pgrpnr.o pointi.o psend.o psinit.o spag.o seppt.o transt.o writln.o >>> writs.o writz.o wrtdate.o reallocate.P modules.P bndind.P bz_lin.P >>> cartco.P clipin.P comprel.P con_ev.P defins.P drawt.P get_ei.P get_k.P >>> inview.P movet.P pgrpnr.P pointi.P psend.P psinit.P spag.P seppt.P >>> transt.P writln.P writs.P writz.P wrtdate.P modules.prj bndind.prj >>> bz_lin.prj cartco.prj clipin.prj comprel.prj con_ev.prj defins.prj >>> drawt.prj get_ei.prj get_k.prj inview.prj movet.prj pgrpnr.prj >>> pointi.prj psend.prj psinit.prj spag.prj seppt.prj transt.prj writln.prj >>> writs.prj writz.prj wrtdate.prj reallocate.prj \ >>> spaghetti.xref *.mod >>> >>> >>> >>> make >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c reallocate.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c modules.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c bndind.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c bz_lin.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c cartco.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c clipin.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c comprel.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c con_ev.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c defins.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c drawt.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c get_ei.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c get_k.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c inview.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c movet.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c pgrpnr.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c pointi.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c psend.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c psinit.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c spag.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c seppt.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c transt.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c writln.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c writs.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c writz.f >>> ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML >>> -traceback -c wrtdate.f >>> ifort -o ./spaghetti reallocate.o modules.
[Wien] Seg Fault during Bandstructure Calculation
Update from my side: I already did some debugging and the crash happens for me in spag.f (line 128) when doing call doreallocate ( ngrp,4,NEVL,NKP) while reading-in the Kpoints from output1 and spaghetti enters these allocation steps because of the condition n_kpt.gt.nkp regards Georg Eickerling On 27.04.2012 07:39, Georg Eickerling wrote: > OK, so I also tried recompiling with O0 and it did not change anything: > > $ make clean > rm -f reallocate.o modules.o bndind.o bz_lin.o cartco.o clipin.o > comprel.o con_ev.o defins.o drawt.o get_ei.o get_k.o inview.o movet.o > pgrpnr.o pointi.o psend.o psinit.o spag.o seppt.o transt.o writln.o > writs.o writz.o wrtdate.o reallocate.P modules.P bndind.P bz_lin.P > cartco.P clipin.P comprel.P con_ev.P defins.P drawt.P get_ei.P get_k.P > inview.P movet.P pgrpnr.P pointi.P psend.P psinit.P spag.P seppt.P > transt.P writln.P writs.P writz.P wrtdate.P modules.prj bndind.prj > bz_lin.prj cartco.prj clipin.prj comprel.prj con_ev.prj defins.prj > drawt.prj get_ei.prj get_k.prj inview.prj movet.prj pgrpnr.prj > pointi.prj psend.prj psinit.prj spag.prj seppt.prj transt.prj writln.prj > writs.prj writz.prj wrtdate.prj reallocate.prj \ > spaghetti.xref *.mod > > > > make > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c reallocate.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c modules.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c bndind.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c bz_lin.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c cartco.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c clipin.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c comprel.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c con_ev.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c defins.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c drawt.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c get_ei.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c get_k.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c inview.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c movet.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c pgrpnr.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c pointi.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c psend.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c psinit.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c spag.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c seppt.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c transt.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c writln.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c writs.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c writz.f > ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML > -traceback -c wrtdate.f > ifort -o ./spaghetti reallocate.o modules.o bndind.o bz_lin.o cartco.o > clipin.o comprel.o con_ev.o defins.o drawt.o get_ei.o get_k.o inview.o > movet.o pgrpnr.o pointi.o psend.o psinit.o spag.o seppt.o transt.o > writln.o writs.o writz.o wrtdate.o -O0 -FR -mp1 -w -prec_div -pc80 -pad > -align -DINTEL_VML -traceback > -L/opt/intel/Compiler/11.0/083/mkl/lib/emt64 -pthread -i-static > > > using this binary still results in: > > x spaghetti > Segmentation fault > 0.068u 0.020s 0:00.08 100.0% 0+0k 0+8io 0pf+0w > error: command /usr/users/eickerling/prog/wien2k11/spaghetti > spaghetti.def failed > > > regards > > Georg Eickerling > > > On 26.04.2012 17:04, Aaron Sutton wrote: >> Hi, >> Posted about this a few days ago but got no response. I'm having an >> issue running spaghetti. When executing x spaghetti from w2web, I >> immediately receive the following: >> >> Commandline: x spaghetti >> Program input is: "" >> >> Segmentation fault >> 0.072u 0.035s 0:00.43 23.2% 0+0k 0+4io 84pf+0w >> error: command /Applications/WIEN2K/spaghetti spaghetti.def failed >> >> No errors are given when r
[Wien] Seg Fault during Bandstructure Calculation
OK, so I also tried recompiling with O0 and it did not change anything: $ make clean rm -f reallocate.o modules.o bndind.o bz_lin.o cartco.o clipin.o comprel.o con_ev.o defins.o drawt.o get_ei.o get_k.o inview.o movet.o pgrpnr.o pointi.o psend.o psinit.o spag.o seppt.o transt.o writln.o writs.o writz.o wrtdate.o reallocate.P modules.P bndind.P bz_lin.P cartco.P clipin.P comprel.P con_ev.P defins.P drawt.P get_ei.P get_k.P inview.P movet.P pgrpnr.P pointi.P psend.P psinit.P spag.P seppt.P transt.P writln.P writs.P writz.P wrtdate.P modules.prj bndind.prj bz_lin.prj cartco.prj clipin.prj comprel.prj con_ev.prj defins.prj drawt.prj get_ei.prj get_k.prj inview.prj movet.prj pgrpnr.prj pointi.prj psend.prj psinit.prj spag.prj seppt.prj transt.prj writln.prj writs.prj writz.prj wrtdate.prj reallocate.prj \ spaghetti.xref *.mod make ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c reallocate.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c modules.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c bndind.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c bz_lin.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c cartco.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c clipin.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c comprel.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c con_ev.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c defins.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c drawt.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c get_ei.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c get_k.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c inview.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c movet.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c pgrpnr.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c pointi.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c psend.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c psinit.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c spag.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c seppt.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c transt.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c writln.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c writs.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c writz.f ifort -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c wrtdate.f ifort -o ./spaghetti reallocate.o modules.o bndind.o bz_lin.o cartco.o clipin.o comprel.o con_ev.o defins.o drawt.o get_ei.o get_k.o inview.o movet.o pgrpnr.o pointi.o psend.o psinit.o spag.o seppt.o transt.o writln.o writs.o writz.o wrtdate.o -O0 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -L/opt/intel/Compiler/11.0/083/mkl/lib/emt64 -pthread -i-static using this binary still results in: x spaghetti Segmentation fault 0.068u 0.020s 0:00.08 100.0%0+0k 0+8io 0pf+0w error: command /usr/users/eickerling/prog/wien2k11/spaghetti spaghetti.def failed regards Georg Eickerling On 26.04.2012 17:04, Aaron Sutton wrote: > Hi, > Posted about this a few days ago but got no response. I'm having an > issue running spaghetti. When executing x spaghetti from w2web, I > immediately receive the following: > > Commandline: x spaghetti > Program input is: "" > > Segmentation fault > 0.072u 0.035s 0:00.43 23.2% 0+0k 0+4io 84pf+0w > error: command /Applications/WIEN2K/spaghetti spaghetti.def failed > > No errors are given when running lawp1 -band from w2web or the command > line. The k-mesh was created using XCrysDen. Any input into this issue > would be greatly appreciated as I've made no progress on it in days. > > Thanks. > > Aaron Sutton > Ph.D. Candidate | University of Toronto > Office: McLennan MP090 | Phone: +1 416 946 3639 > Email: asutton at physics.utoronto.ca > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] Seg Fault during Bandstructure Calculation
Dear WIEN users, I am joining this thread as I have exacly the same problem right now. Everything with the case works fine, SCF, DOS, densities etc. the only failure is (im using the command line): after successfully running lapw1 -band (and lapw2 -qtl -band optionally): # x spaghetti Segmentation fault 0.056u 0.028s 0:00.08 87.5% 0+0k 0+8io 0pf+0w error: command /usr/users/eickerling/prog/wien2k11/spaghetti spaghetti.def failed When I copy the exact same case-files to another machine spaghetti works without problems, so I can exclude a input-error. I can reproduce the problem with both versions, wien2k10 and wien2k11 and in both cases spaghetti compiled without errors. regards Georg Eickerling On 26.04.2012 17:04, Aaron Sutton wrote: > Hi, > Posted about this a few days ago but got no response. I'm having an > issue running spaghetti. When executing x spaghetti from w2web, I > immediately receive the following: > > Commandline: x spaghetti > Program input is: "" > > Segmentation fault > 0.072u 0.035s 0:00.43 23.2% 0+0k 0+4io 84pf+0w > error: command /Applications/WIEN2K/spaghetti spaghetti.def failed > > No errors are given when running lawp1 -band from w2web or the command > line. The k-mesh was created using XCrysDen. Any input into this issue > would be greatly appreciated as I've made no progress on it in days. > > Thanks. > > Aaron Sutton > Ph.D. Candidate | University of Toronto > Office: McLennan MP090 | Phone: +1 416 946 3639 > Email: asutton at physics.utoronto.ca > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] question about ISPLIT and orbital degeneracy
Dear WIEN users, I have a question concerning the ISPLIT option: Assuming a cubic (non-magnetic/non spin-polarized) NiO as example, the default ISPLIT after init_lapw is "2" which results in the expected eg/t2g splitting of the Ni d-orbitals in the projected DOS. What I now did was change ISPLIT to 8 run lapw2 -qtl (or qtl itself with QSPLIT 2) in order to see the same eg/t2g degenracy for the five individual d-orbitals. However, this produces a partial d-DOS in which none of the orbitals are degenerate. I only obtain the correct degeneracy with ISPLIT 8/QSPLIT 2 when first calculating a "P1" k-list by removing all symmetry operations apart from the identity from the struct generating a new klist run lapw1 run lapw2 -qtl (or qtl itself) So my question is: Why do I need the "P1" k-list in this case, should not the eigenvalues on the original k-points show the degeneracies as well? Thank you in advance for your help, Georg Eickerling -- ======== Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3362 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] Laplacian of the electron density in WIEN08.3
Dear WIEN users, I recently upgraded from WIEN08.1 to version 08.3 and I am trying to calculate the Laplacian of the electron density. However, with the "old" strategy, putting option 36 and R2V in case.in0 I obviously do not obtain the Laplacian of the electron density in the r2v file. I checked the sources of LAPW0 and the file vxclm2.f has been changed at the position were before the option 36 was mentioned to provide the Laplacian of rho. Is there still a way to obtain nabla^2 rho on a grid? Thank you in advance for your help Georg Eickerling
[Wien] electron density plot
You might also try Xcrysden to run the density calculations (File-> Open WIEN2K-> Calculate and Render Density). This is also the way to go if you want to calculate 3D grids of the electron density. regards, Georg muniroh schrieb: > Dear wien users, > Although sound quite silly, but can any one tell me exactly as how to > electron density calculated? Which input and output files are related? > Thanks in advance.. > > regards, > zira > > > > > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3354 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] Bader's aim
I can answer the fist of your questions: Yes, you can run AIM for several atoms at once. Just use a list of commands in case.inaim like this: CRIT 1 TWO 3 3 3 CRIT 2 TWO 3 3 3 CRIT 3 TWO 3 3 3 CRIT 5 TWO 3 3 3 CRIT 1 THREE 3 3 3 CRIT 5 FOUR 3 3 3 END regards Georg Eickerling John Appleton schrieb: > Dear users, > > I would like to know if case.inaim input for Bader's > AIM program in WIEN2k can be run for several atoms > at once. The input below as provided in the user manual > is for one atom but I would like to apply it to several > atoms in my structure. > Secondly, how does one get the net charge on an atom > from case.outputaim. > > case.inaim > == > SURF > 1 atom (including multiplicity) to integrate > 20 0.0 1.5707963267949 theta, 20 points, from zero to pi/2 > 20 0.7853980 2.35619 phi, from pi/4 to 3 pi/4 (depends on > symmetry!!) > 0.07 0.8 4 step along gradient line, rmin (when reached > it assumes the gradient line ends at the atom), every 4th step it checks > wether gr.path is behing/in front an already found surface > 1.65 0.1initial R for search, step (a.u) > 3 3 3 nshell > IRHO "INTEGRATE" rho > WEIT WEIT (surface weights are available in > case.surf), NOWEIT if surface put int by hand > 30 30 radial points outside min(RMIN,RMT) > END > ===. > > > > > > > > > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] cnorm for Laplacian calculation
Dear Prof. Blaha, thank you for the reply. > I don't know how exactly you got the laplacian, but my first guess > concerning the factor 2 would be that you did not consider the spin. I followed the "guide" you gave me a while back here on the mailing list: >You can use lapw0. In case.in0 specify as option 36 (instead if 13) >and put R2V instead of NR2V. > >(See vxclm2.f in SRC_lapw0) I did my (non-spinpolarized) SCF run as usual and then modified in0 to use option 36 and r2v instead of the defaults. > > In lapw0 everything is done spin-polarized, even in a non-spinpolarized > calculation and one has to add spin-up and dn laplacians to get the > total. I obtain one r2v file and in my working dir I do not see any files indicating an "up/down" output. So I followed your "old" advice >The file case.r2v contains the laplacian in the same functional form as >the density or the potential is usually stored. Thus you can use this file >instead of case.clmval and plot the Laplacian with x lapw5 >(you need to cp case.r2v case.clmvalbefore running lapw5). and used the r2v file "as it is" to plot nabla**2. > I guess the rest is ok. The normalization of clmsum and clmval files are > different (only inside the spheres!), this explains the factor sqrt(4pi), > but the r2v file has the "clmval" normalization. Thank you for clarifying this. I will do some further tests and try to find out what is causing the deviations I observe - I do not see a mistake in my "procedure", yet. regards Georg Eickerling > > > Dr. Georg Eickerling schrieb: >> Dear WIEN users, >> >> I have a question concerning the use of LAPW5 to calculate the Laplacian >> of the Density on a grid. >> >> Using lapw0 [WIEN2k_08.1 (Release 14/12/2007)] I can obtain an r2v file >> containing the information >> about the Laplacian and copying the r2v to clmval I can use lapw5 to >> obtain grid files. >> >> I specify atomic units in the lapw5 input to keep WIEN from applying >> some conversion factors from >> e bohr-3 to e A-3 which would be useless in this case and in addition I >> specify the keyword VAL. >> >> This works all well and the plots in XCrysden look resonable but >> comparing the absolute values from WIEN >> to those obtained by experiment WIEN gives results which are too small >> by something close to a factor of 2 >> (which seems not to be "real" as the topological parameters obtained >> by WIEN's aim at the bond critical >> points are VERY close to the experimental values). >> >> In lapw5 I can specify "TOT" of "VAL" for the "normalization" which >> results in a division by a factor Sqrt(4Pi) in the >> case of using "TOT". My first (general) question is: What is the reason >> for this additional factor for the total density? >> >> Any then the second question: What would be the "proper" way to obtain >> the Laplacian in atomic units with LAPW5, >> should I use VAL or TOT or is there some other normalization/unit >> conversion I would have to do? >> >> Thanks in advance for any help! >> >> Georg Eickerling >> >> >> >> > -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3354 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
[Wien] cnorm for Laplacian calculation
Dear WIEN users, I have a question concerning the use of LAPW5 to calculate the Laplacian of the Density on a grid. Using lapw0 [WIEN2k_08.1 (Release 14/12/2007)] I can obtain an r2v file containing the information about the Laplacian and copying the r2v to clmval I can use lapw5 to obtain grid files. I specify atomic units in the lapw5 input to keep WIEN from applying some conversion factors from e bohr-3 to e A-3 which would be useless in this case and in addition I specify the keyword VAL. This works all well and the plots in XCrysden look resonable but comparing the absolute values from WIEN to those obtained by experiment WIEN gives results which are too small by something close to a factor of 2 (which seems not to be "real" as the topological parameters obtained by WIEN's aim at the bond critical points are VERY close to the experimental values). In lapw5 I can specify "TOT" of "VAL" for the "normalization" which results in a division by a factor Sqrt(4Pi) in the case of using "TOT". My first (general) question is: What is the reason for this additional factor for the total density? Any then the second question: What would be the "proper" way to obtain the Laplacian in atomic units with LAPW5, should I use VAL or TOT or is there some other normalization/unit conversion I would have to do? Thanks in advance for any help! Georg Eickerling -- Dr. Georg Eickerling Universitaet Augsburg Institut fuer Physik Lehrstuhl fuer Chemische Physik und Materialwissenschaften Universitaetsstr. 1 86159 Augsburg E-Mail: georg.eickerling at physik.uni-augsburg.de Phone: +49-821-598-3354 FAX:+49-821-598-3227 WWW:http://www.physik.uni-augsburg.de/cpm/ =
