[Wien] xcrysden large multipler k-points
actually, i used only 300 k-points and this specific problem arose when i tried to select k-path for band structure calculations. my system has monoclinic symmetry so there are a couple of special points in k-path i wanted to adopt with coordinates like (0.64xxx, 0.32xxx, 0.5). i selected the total number of divisions (k-points) of this path again 300. the code insists on having an integer coordinate with a multiplier. for 300 k-points, the multiplier was quite large and the integer coordinates printed in case.klist_band file were **. Prof. Tone asked for my structure file and he too got into same error. Let me copy - paste his reply: On Mon, 2012-07-16 at 17:37 +0900, ? wrote: here are the .struct file and complete .klist_band file. i tried to solve this problem by making separate kpath klist files for every two points. the idea was to join them manually use different multipliers for different path. Yes, you are right. I could reproduce your problems. I believe that the problem is due to Wien2K. Your case is a nasty case for Wien2K. Why? Because it insist on representing the real number (rational number) as the fraction p/q of two integers with a fixed format. As your case is not a high symmetry case, the p q numbers are simple too large and the stars () are displayed. As a work-around: you could use the coordinates of special k-points as given by xcrysden, and then you need to construct out of that semi-manually a klist file suitable for Wien2K (this would involve some manual editing + some small scripting to interpolate points between pairs of special k-points). Regards. Tone -- Anton Kokalj J. Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia (tel: +386-1-477-3523 // fax:+386-1-477-3822) so, therefore i thought may be it is due to same problem you guys are discussing, just pushed my mail . . . . ;D any way, thnx. for ur reply. M. Arshad Farhan On Mon, Jul 30, 2012 at 3:32 PM, Gavin Abo gsabo at crimson.ua.edu wrote: What large values did you use in xcrysden for the multiplier and k-points? Someone else might be able to comment on whether you can use smaller values and still get accurate results. I see your posts on the xcrysden mailing list: http://www.democritos.it/pipermail/xcrysden/2012-July/001215.html http://www.democritos.it/pipermail/xcrysden/2012-July/001223.html From the posts, it looks like the number of k-points you used is possibly greater than 99672. You currently cannot use multipiler*k-points 5-digits (i.e., 99,999) If the larger outputted values are really needed, it could probably be done by changing all the 4I5 to say 4I8 in F/kPath.f that is in the xcrysden source package (xcrysden-1.5.53.tar.gz). However, you have to compile the xcrysden code. There are some useful instructions on the web for compiling the xcrysden source in Debian or Ubuntu ( https://sites.google.com/site/jamesanalytis/xcrysden-in-ubuntu-10-04), but have not seen for other Linux distributions if one wants to attempt it. Since your not quite a linux guy, you will probably want to send your struct file (while providing also the multiplier and k-points value used) to Tone as requested on the xcrysden mailing list so that a linux binary package with changes can be provided if needed. On 7/29/2012 7:54 PM, ? wrote: Dear Prof. Lawrance Gavin-Abo, i've not tested the latest version of Wien2k but, let me mention one more place where real*4 are used that is in the creation of case.klist_band. for any complicated coordinate in the k-path (mainly in monoclinic systems) by using Xcrysden, the multiplier goes shooting high and coordinate value exceeds real*4 consequently printing ** in places of k-point coordinates in case.klist_band file. the XcrySden developers claim it to be on part of Wien2k where it insists on real value but restricts it to 4 digits. if possible, please also look into it and of-course suggest me a solution as i'm quite not a linux guy. regards, ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- * ?* Dept of Chemistry, Pohang Univ of Sci Tech Pohang, Republic of Korea -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120801/cba6c98d/attachment.htm
[Wien] Repair Job
Hi dear all Wien users, I am new to this group and want to know, how to repair a Job when the computer is restarted while running calculations. Thanks in advance. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120801/63e96678/attachment.htm
[Wien] Repair Job
Usually, you just resubmit your job. Ideally, you can add-NI to the run_lapw runsp_lapw line. Only in the exceptional cases, where the computer crashed in mixer either during writing of case.clmsum or writing case.broyd*, one would need to cp case.clmsum_old case.clmsum (and do no not use -NI) Am 01.08.2012 10:07, schrieb Bakhtiar Ul Haq: Hi dear all Wien users, I am new to this group and want to know, how to repair a Job when the computer is restarted while running calculations. Thanks in advance. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] Benchmarks -- comments please
I am benchmarking some new nodes (Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz) using the standard mpi Wien2k benchmark, and would be interested in comments/comparisons -- the online mpi benchmark seems to be a bit outdated. Hyperthreading is turned on (currently not under my control), and the IB is not working right so these numbers are only for a single node with two quadcores with openmpi 1.4 (no idea how it was compiled) and composer_xe_2011_sp1.11.339 Runs on 1 node == 16 cores (hyperthreading used) Maximum WALL clock time:93.7425620555878 Maximum CPU time: 88.3 == 4 cores Maximum WALL clock time:221.049882888794 Maximum CPU time: 210.0400 == 8 cores Maximum WALL clock time:132.835557937622 Maximum CPU time: 125.5600 For comparison, on my older Intel(R) Xeon(R) CPU E5410 @ 2.33GHz == 8 cores Maximum WALL clock time:304.22861000 Maximum CPU time: 296.8000 N.B., the speed increase with hyperthreading is mainly in HAMILT/HNS and may be misleading or might be real. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi
[Wien] v12: SRC_lapwso: init.f fix
Dear Wien2k developers, v12 of Wien2k has a severe bug fix for LDA+U calculations with complex vorb potential in SRC_lapwso: init.f. How severe was that bug and in which cases did it show up? What is meant by complex vorb potential? Best regards, Kateryna Foyevtsova P.S. For a monoclinic system with orbital degeneracy, LDA+U+SO calculations with version 12 give very different DOS, orbital occupations, orbital moments (this one partially due to a fix in SRC_lapwdm) and electron density isosurfaces, compared to the results obtained with version 11.
[Wien] Benchmarks -- comments please
Addendum: apparently hyperthreading is not on, I was misled by something on a linux forum that I used to test. On Wed, Aug 1, 2012 at 9:10 AM, Laurence Marks L-marks at northwestern.edu wrote: I am benchmarking some new nodes (Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz) using the standard mpi Wien2k benchmark, and would be interested in comments/comparisons -- the online mpi benchmark seems to be a bit outdated. Hyperthreading is turned on (currently not under my control), and the IB is not working right so these numbers are only for a single node with two quadcores with openmpi 1.4 (no idea how it was compiled) and composer_xe_2011_sp1.11.339 Runs on 1 node == 16 cores (hyperthreading used) Maximum WALL clock time:93.7425620555878 Maximum CPU time: 88.3 == 4 cores Maximum WALL clock time:221.049882888794 Maximum CPU time: 210.0400 == 8 cores Maximum WALL clock time:132.835557937622 Maximum CPU time: 125.5600 For comparison, on my older Intel(R) Xeon(R) CPU E5410 @ 2.33GHz == 8 cores Maximum WALL clock time:304.22861000 Maximum CPU time: 296.8000 N.B., the speed increase with hyperthreading is mainly in HAMILT/HNS and may be misleading or might be real. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi
[Wien] Slow lapw1
While testing a vendor's cluster, I came across what might be a serious issue for future WIen2k jobs. With the latest architecture it appears that 64 cores can in fact be slower than 32, using the standard mpi test. The slowdown occurs in both PDSYGST and PDSYEVX. I do not think that this is an issue of the vendor's mpi, but one never knows. I have posted to the Intel list; it will be interesting to see what if any responses there are http://software.intel.com/en-us/forums/showthread.php?t=106950 I would also encourage others who have new hardware to do similar tests, and if they have similar issues to also post to the thread. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi
[Wien] Spin texture in reciprocal space
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011). They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands, however, I am unsure how to go about calculating the expectation values for the spin in reciprocal space. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120801/54359b85/attachment.htm
