[Wien] WIEN2k 12 fft_modules
Unknown Unknown lapw2 00437F93 fermi_tetra_ 516 fermi_tmp_.F lapw2 00437423 fermi_ 111 fermi_tmp_.F lapw2 004721BA MAIN__ 278 lapw2_tmp_.F lapw2 00403C9C Unknown Unknown Unknown libc.so.6 2B3BE2AF5C8D Unknown Unknown Unknown lapw2 00403B99 Unknown Unknown Unknown -- 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 mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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 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/20120730/fb8879e3/attachment.htm
[Wien] Such a vast difference in two values of K’ for the same case.
I have basically two questions to ask. I will like to mention that I have gone through the related previous questions and their answers on registered users site. I will be highly obliged if you could kindly spare some time to go through the following two queries. 1.) I was doing c/a optimization at five different volumes in bct structure for a particular case and was trying to get equilibrium volume and tentative value of bulk modulus and its pressure derivative. I gave optimization for one set of 5 volumes, say +5.0, 0.0, -5.0, -10.0, -15.0 and another set, say +5.5, 0.5, -5.5, -10.5, -15.5 and then get EOS, then I find that there is a huge difference in the value of pressure derivative of bulk modulus K? for the two cases. I have plotted both the cases together in the plot.ps file attached herewith. Here in the plot ?E? is the same constant value of energy for both the curves. Only thing is, for the sake of clarity of seeing the two curves together, in the solid curve 0.001 Ryd of energy is added so that it is shifted up by that much energy so that one can see the difference between the shape of two curves clearly. Both the curves as such don?t seem to be much different, then why such a large difference in K?. Even otherwise also, why should it matter whether the run is given for 1st set of volumes or the 2nd set of volumes. Could you please comment on this Prof. Blaha? 2.)While doing a spin-orbit calculation, we need to increase Emax upto 10 Ry in case.in1 file even though we are interested in eigenvalues near Fermi energy. But as said in users guide, in the second-variation these high eigenstates form the basis functions for the SO calculation. Without these high eigenvalues there will be a poor basis even for states near Fermi energy.. But these high eigenvalues are giving large QTL-B value of 980 or 1500 value, at high energies say around 4.0 in case.output2 file if emax is set as 5.0 (instead of the default value 1.5) in case.inso file also apart from a Emax=5 (default in SO calculations) in case.in1 file, when we try to calculate partial charges by giving the command 'x lapw2 -so -qtl'. After this, the command 'x tetra' is given to get density of states. So as said earlier, this is so when case.inso file also has emax = 5.0 i.e the maximum energy for which output eigenvectors and eigenenergies will be printed (p.96 of users guide). But if we put emax =1.5, which is the default value in case.inso file, then anyway at high energies no computation of eigenvectors and eigen energies is done and no such statement appears in the case.output2 file. It is true that fermi energy is far below the energy level at which high QTL-B is quoted in case.output2 file. My question here is: How and where Emax = 5.0 of case.in1 file is used so that getting large qtl-b in output2 while calculating partial charges, is meaningless or unharmful, if we happen to keep emax equal to 5.0 in case.inso also. I just want to confirm that a large qtl-b value at energies 0.5 to 1Ryd higher than Fermi energy in case.output2 file is harmless and that I can use Emax upto 10 in case.in1 file without any hesitation. I will highly appreciate your clarification on this. Thank you very much in advance for your attention and time. V. Mishra -- next part -- A non-text attachment was scrubbed... Name: plot.ps Type: application/postscript Size: 23196 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/de0945ca/attachment.ps
[Wien] xcrysden large multipler k-points
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, -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/c4abd12a/attachment.htm
[Wien] infrared/Raman spectra...
thanks Prof. Peter Blah On Sun, Jul 29, 2012 at 1:16 PM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: IR and Raman means first: phonon calculations (Gamma only). This can be done either by creating the corresponding displacements by hand and also setup/diagonalize the dynamical matrix yourself or (much better) together with external programs like phonon (expensive) or phonopy (free). See unsupported software at www.wien2k.at This will only give you the IR/raman frequencies. For raman intensities I know some papers by C.Ambrosch-Draxl et al. (PRB ?), where she describes it (using optics for variuos frozen phonons). Search for Ambrosch and raman. Am 28.07.2012 11:25, schrieb Pradeep Kumar: Dear Wien2k Users, Is it possible to calculate infrared absorption and Raman spectra (i.e. Intensity vs. Raman shift) using Wien2k 11.1 version?. Is there any other utility programme regarding this? If anybody knows this one, please help me. thanks in advance... Pradeep Kumar Research Scholar University of Delhi India ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Pradeep Kumar India
[Wien] Error while parallel run
. mpirun is available in /opt/openmpi/1.3/bin Thank you in advance. Regards, -- Dr. Alpa Dashora __**___ Wien mailing list Wien at zeus.theochem.tuwien.ac._**_at mailto:Wien at zeus.theochem.** tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at mailto: Wien at zeus.theochem.__t**uwien.ac.at http://tuwien.ac.at mailto: Wien at zeus.theochem.**tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wienhttp://ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Alpa Dashora __**___ Wien mailing list Wien at zeus.theochem.tuwien.ac._**_at mailto:Wien at zeus.theochem.** tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wienhttp://ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://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 tel:%2B43-1-58801-165300 FAX: +43-1-58801-165982 tel:%2B43-1-58801-165982 Email: blaha at theochem.tuwien.ac.at mailto:blaha at theochem.tuwien.** ac.at blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/__* *theochem/ http://info.tuwien.ac.at/__theochem/ http://info.tuwien.ac.at/**theochem/ http://info.tuwien.ac.at/theochem/ --**__** --__-- __**___ Wien mailing list Wien at zeus.theochem.tuwien.ac._**_at mailto:Wien at zeus.theochem.** tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wienhttp://ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Alpa Dashora __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- --**--- Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at --**--- __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Alpa Dashora -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/93e920e4/attachment-0001.htm
[Wien] Error while parallel run
First: If you are unexperienced in computing, why would you use mpi at all. Try the k-point parallel version first. .machines: 1:arya 1:arya 1:arya no lapw0 line !! Am 30.07.2012 08:58, schrieb alpa dashora: Dear Wien2k Users, Mr. Abo and Prof. Blaha, I have edited my .machines file with the correct cpu name. My new .machines file is as follows: granularity:1 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 extrafine:1 lapw0: arya:2 arya:2 After run_lapw -p: it gives the following error message: exe: MPI_Init: MPI_Root is not set exe: MPI_Init: Cannot set mpirun startup protocol Than, I have set the MPI_ROOT as: export MPI_ROOT=/opt/openmpi-1.4.5 After export MPI_ROOT the following error was received: exe: MPI_INIT: Can't read plugin directory /opt/openmpi-1.4.5/lib/linux_amd64/plugins exe: MPI_Init: No plugins will be available I didnt have any idea about openmpi, please tell me how to solve this error. Please also comment on the .machines file. With kind regards, On Fri, Jul 27, 2012 at 11:02 AM, Peter Blaha pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at wrote: How should I know the correct name of your computer ??? When you login to the machine, what are you using ??? Most likely, this will be the correct name. If it is a shared memory machine you should use the same name for all processes. Am 26.07.2012 19:45, schrieb alpa dashora: Dear Prof. Blaha, Prof. Marks and All Wien2k users, Thank you very much for reply. I have given the more detail of my system as you required: 1. What kind of system do you have ?? We have HP ProLiant DL380 G7 (8 servers) with 2 processors each. So we have 16 processors and the total memory is shared by all the processors. 2. sh ??? What did you specify in siteconfig when configuring the parallel environment ??? shared memory or non-shared memory ?? During the site configuration, I have used shared memory architecture. 3. *are your nodes really called cpu1, ...* * * I have used the 'top' command on terminal, it gives the performance of all the processors. It gives the name of each processor as cpu1, cpu2, cpu3, so I have taken it as such. Please suggest me the correct .machines file or any other solution to solve this problem. With kind regards, On Thu, Jul 26, 2012 at 2:25 PM, Peter Blaha pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.__tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at wrote: You seem to have several errors in your basic installation: setenv USE_REMOTE 0 setenv MPI_REMOTE 0 [arya:01254] filem:rsh: copy(): Error: File type unknown rsh ??? What did you specify in siteconfig when configuring the parallel environment ??? shared memory or non-shared memory ?? ssh or rsh ??(most likely rsh will not work on most systems) What kind of system do you have ?? a) Is it ONE computer with many cores (typically some SGI or IBM-power machines, or a SINGLE Computer with 2-4 Xeon-quadcore processors), or b) a cluster (connected via Infiniband) of several (Xeon multicore) nodes Only a) is a shared memory machine and you can set USE_REMOTE to 0 Another problem might be your .machines file: are your nodes really called cpu1, ... This implies more or less that you have a cluster of single-core machines ??? My guess is that you have a 16 core shared memory machine ??? In this case, the .machines file must always contain the same correct machine name (or maybe localhost), but not cpu1,2 Am 26.07.2012 10 tel:26.07.2012%2010:17, schrieb alpa dashora: Dear Wien2k Users and Prof. Marks, Thankyou very much for your reply. I am giving more information. Wien2k Version: Wien2k_11.1 on a 8 processor server each has two nodes. mkl library: 10.0.1.014 openmpi: 1.3 fftw: 2.1.5 My OPTION file is as follows: current:FOPT:-FR -O3 -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -l/opt/openmpi/include current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -traceback current:LDFLAGS:-L/root/WIEN2k_11/SRC_lib -L/opt/intel/cmkl/10.0.1.014/lib/em64t http://10.0.1.014/__lib/em64t http://10.0.1.014/lib/em64t http://10.0.1.014/lib/em64t -lmkl_em64t
[Wien] Fwd: Error while parallel run
Dear Prof. Blaha, As per your suggestion, I am able to run the k-point parallel calculation. But in case of large systems, about 100 atoms, can I use this technique (with how many k-points?)? rgds, -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/3f9e44f5/attachment.htm
[Wien] Fwd: Error while parallel run
No. For large cells you have to learn how to configure and use mpi correctly. Am 30.07.2012 09:21, schrieb alpa dashora: Dear Prof. Blaha, As per your suggestion, I am able to run the k-point parallel calculation. But in case of large systems, about 100 atoms, can I use this technique (with how many k-points?)? rgds, ___ 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] How to print QTLs for f subshell
When you change ISPLIT by hand in case.struct, be sure to keep the numbers in the correct column ! Alternative: Use the qtl program to generate case.qtl for the f-orbitals. Am 28.07.2012 02:50, schrieb Jonathan Solomon: To WIEN2k users and developers: I would like to print QTLs for all seven orbitals contained in the f subshell. I set ISPLIT=15 in the case.struct file but when I run init_lapw it reverts to ISPLIT=8 and thus only prints up to the d orbitals. It does not work if I manually change it back to 15 before running the calculation. Thank you, Jonathan Solomon ___ 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] Fwd: Error while parallel run
Thankyou very much. On Mon, Jul 30, 2012 at 12:58 PM, Peter Blaha pblaha at theochem.tuwien.ac.atwrote: No. For large cells you have to learn how to configure and use mpi correctly. Am 30.07.2012 09:21, schrieb alpa dashora: Dear Prof. Blaha, As per your suggestion, I am able to run the k-point parallel calculation. But in case of large systems, about 100 atoms, can I use this technique (with how many k-points?)? rgds, __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://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/ http://info.tuwien.ac.at/theochem/ --**--** -- __**_ Wien mailing list Wien at zeus.theochem.tuwien.ac.**at Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Alpa Dashora -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/1e665b5f/attachment.htm
[Wien] Such a vast difference in two values of K’ for the same case.
I would not bother too much about B', but B is changing by 20 %, which is too much. You have to analyse your data to find out where your error is. Maybe in one set of calculations you have not got the optimized c/a ratio (and corresponding energy) for each volume ??? PS: 5 points are probably ok for equillibrium V and c/a, but B will always have quite some error. Spin-orbit: Emax in case.in1 should be increased. Emax in case.inso can stay at eg. 1.5 Ry You don't need to worry about qtl-B at very high (unoccupied) energies (unless for some spectroscopy you need these high states). Am 30.07.2012 06:15, schrieb Vinayak Mishra: I have basically two questions to ask. I will like to mention that I have gone through the related previous questions and their answers on registered users site. I will be highly obliged if you could kindly spare some time to go through the following two queries. 1.) I was doing c/a optimization at five different volumes in bct structure for a particular case and was trying to get equilibrium volume and tentative value of bulk modulus and its pressure derivative. I gave optimization for one set of 5 volumes, say +5.0, 0.0, -5.0, -10.0, -15.0 and another set, say +5.5, 0.5, -5.5, -10.5, -15.5 and then get EOS, then I find that there is a huge difference in the value of pressure derivative of bulk modulus K? for the two cases. I have plotted both the cases together in the plot.ps file attached herewith. Here in the plot ?E? is the same constant value of energy for both the curves. Only thing is, for the sake of clarity of seeing the two curves together, in the solid curve 0.001 Ryd of energy is added so that it is shifted up by that much energy so that one can see the difference between the shape of two curves clearly. Both the curves as such don?t seem to be much different, then why such a large difference in K?. Even otherwise also, why should it matter whether the run is given for 1st set of volumes or the 2nd set of volumes. Could you please comment on this Prof. Blaha? 2.)While doing a spin-orbit calculation, we need to increase Emax upto 10 Ry in case.in1 file even though we are interested in eigenvalues near Fermi energy. But as said in users guide, in the second-variation these high eigenstates form the basis functions for the SO calculation. Without these high eigenvalues there will be a poor basis even for states near Fermi energy.. But these high eigenvalues are giving large QTL-B value of 980 or 1500 value, at high energies say around 4.0 in case.output2 file if emax is set as 5.0 (instead of the default value 1.5) in case.inso file also apart from a Emax=5 (default in SO calculations) in case.in1 file, when we try to calculate partial charges by giving the command 'x lapw2 -so -qtl'. After this, the command 'x tetra' is given to get density of states. So as said earlier, this is so when case.inso file also has emax = 5.0 i.e the maximum energy for which output eigenvectors and eigenenergies will be printed (p.96 of users guide). But if we put emax =1.5, which is the default value in case.inso file, then anyway at high energies no computation of eigenvectors and eigen energies is done and no such statement appears in the case.output2 file. It is true that fermi energy is far below the energy level at which high QTL-B is quoted in case.output2 file. My question here is: How and where Emax = 5.0 of case.in1 file is used so that getting large qtl-b in output2 while calculating partial charges, is meaningless or unharmful, if we happen to keep emax equal to 5.0 in case.inso also. I just want to confirm that a large qtl-b value at energies 0.5 to 1Ryd higher than Fermi energy in case.output2 file is harmless and that I can use Emax upto 10 in case.in1 file without any hesitation. I will highly appreciate your clarification on this. Thank you very much in advance for your attention and time. V. Mishra ___ 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] Fwd: Error while parallel run
Dear Mr./Dr. Gavin, After editing the .machines file, the openmpi1.3 gives the same error as mentioned in the last mail, therefore I have installed new version 1.4.5, but it doesn't work. On Mon, Jul 30, 2012 at 1:51 PM, Gavin Abo gsabo at crimson.ua.edu wrote: Previously, you were supposedly using /opt/openmpi/1.3 that seemed to work fine. So wondering why you are now using: /opt/openmpi-1.4.5 One HP ProLiant DL380 G7 server box (http://h18004.www1.hp.com/** products/quickspecs/13595_div/**13595_div.htmlhttp://h18004.www1.hp.com/products/quickspecs/13595_div/13595_div.html) has one or two processors each with 2, 4, or 6 cores. You previously indicated that you have the two processor model, but you have not mentioned the number of cores. Each server has its own memory. You mentioned having 8 server boxes. Do all 8 server boxes have the same number of processors and cores? Without this information, no one knows what your .machines might need to be. On 7/30/2012 1:02 AM, Peter Blaha wrote: First: If you are unexperienced in computing, why would you use mpi at all. Try the k-point parallel version first. .machines: 1:arya 1:arya 1:arya no lapw0 line !! Am 30.07.2012 08:58, schrieb alpa dashora: Dear Wien2k Users, Mr. Abo and Prof. Blaha, I have edited my .machines file with the correct cpu name. My new .machines file is as follows: granularity:1 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 1:arya:2 extrafine:1 lapw0: arya:2 arya:2 After run_lapw -p: it gives the following error message: exe: MPI_Init: MPI_Root is not set exe: MPI_Init: Cannot set mpirun startup protocol Than, I have set the MPI_ROOT as: export MPI_ROOT=/opt/openmpi-1.4.5 After export MPI_ROOT the following error was received: exe: MPI_INIT: Can't read plugin directory /opt/openmpi-1.4.5/lib/linux_ **amd64/plugins exe: MPI_Init: No plugins will be available I didnt have any idea about openmpi, please tell me how to solve this error. Please also comment on the .machines file. With kind regards, -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120730/2781396a/attachment.htm
[Wien] WIEN2k 12 fft_modules symmetry
Yes, I can confirm that the missing real*8 in pimach is a bug, even when it does not show up in optimized compilations. One should insert IMPLICIT REAL*8 (A-H,O-Z) in function pimach (bottom of SRC_lapw0/fftpack_helpers.f file). As L.Marks already pointed out, the kurki.f problem is not really a bug (and should never cause problems, as something is allowed in Fortran. However, it is certainly not clean and I'll change it. Am 30.07.2012 00:49, schrieb Gavin Abo: Thanks, Prof. Marks. Your explanation is better than mine. Yes, almost certainly the default -r4 is used for -O2, but by luck it is not truncating the variable. By the way, do you think it is also by luck that the ifort compiler produces an x symmetry executable that does not crash with a memory access violation outside the lm array for certain structures? If you check SRC_symmet*ry*/class.f on line 8, the array is allocated as lm(2,49). However, the array is only allocated as lm(2,48) in kurki.f on line 3. Since class.f and kurki.f in SRC_symmet*so* both have lm(2,49), it suggests lm(2,48) should be replaced by lm(2,49). This would affect at least Wienk2k 11 and 12. How I caught the potential issue on my system: 1. Add capitalized -C in SRC_symmetry*/*Makefile 2. make 3. cp symmetry .. 4. Use in2o3.struct in the Wien2k folder example_struct_files 5. x symmetry 6. The first line in the error message: forrtl: severe (408): fort: (2): Subscript #2 of the array LM has value 49 which is greater than the upper bound of 48 When -C is not used, the executable runs without error and seems to produce the correct output for in2o3. The error cannot be caught with TiC. On 7/29/2012 2:54 PM, Laurence Marks wrote: Almost certainly it is trickier than this. I expect that -O1 is truncating relevant variables to real*4 which is leading to problems. With -O2 the compiler may well be not bothering to truncate and, at the end of the space allocated for the variable, by luck the correct values are present. This is luck; the same type of bug can in other cases lead to segmentation violations when code gets overwritten. N.B., I think there are only two places where real*4 variables are used, in parts of aim and for storage of the Hamiltonian in lapw1. Everything else should be real*8. On Sun, Jul 29, 2012 at 3:05 PM, Gavin Abogsabo at crimson.ua.edu wrote: I didn't use -r8. However, you are right. The scf cycle works correctly if I use -O1 -r8. So the higher optimizations -O2 and -O3 must be invoking the use of -r8, whereas -O0 and -O1 should be using the default -r4. On 7/29/2012 1:40 PM, Laurence Marks wrote: I have not tested, but it looks like you are probably right. There may be other cases where variables are not explicitly defined to be 8 bytes which are normally hidden by the use of -r8. Did you use -r8? On Sun, Jul 29, 2012 at 1:57 PM, Gavin Abogsabo at crimson.ua.edu wrote: Dear Prof. Blaha, Thanks, the scf cycle runs correctly using -O2 or -O3 with the new files for the fftpack routines. However, the scf cycle of the TiC example does not converge with -O1 (in the lapw0 makefile) with wrong values in TiC.output0 such as the plane wave contribution. I don't know whether the problem is reproducible on another system. It seems to be due to IMPLICIT REAL*8 (A-H,O-Z) not being in the PIMACH function at the end of the fortran file fftpack_helpers.f. This line is in the function in the old file zfft3d.F. Kind Regards, Gavin On Thu, Jul 26, 2012 at 1:42 AM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: Thank's for the report. The problem concerns lapw0, when compiled in sequential mode WITHOUT -DFFTW2 or -DFFTW3 in the Makefile (i.e. using the old fftpack routines instead of the new and faster fftw library). The fix suggested in the mail below does not work. Instead, you have to replace the 3 attached subroutines and recompile. (eramps.f, fft_modules.F fftpack_helpers.f) A corrected version is on the web. PB Am 25.07.2012 23:21, schrieb Gavin Abo: Dear Prof. Blaha, When I run the TiC example with WIEN2k 12 without k-point or mpi parallelization, the program stops in lapw2 with the error shown below. Here lapw2 cannot read the TiC.energy file, because it is missing data in it as lapw0 gives bad output such as a Density Integral with the value NaN in TiC.output0. The problem seems to be related to the new fft module. If lines 536-538 and 612-614 in SRC_lapw0/fft_modules.F: N2 = N+N DO 117 I=1,N2 C(I) = CH(I) are both changed to: DO 117 I=1,N C(I) = CH(I) Then, the error goes way. On my system, N was the number 64. The array C had a size of 64, such that the loop is indexing outside the array (N2 = 128). In Wien2k 11, TiC.output0 had: PLANE WAVE CONTRIBUTION -0.235589 :DEN : DENSITY INTEGRAL = -754.35311720 (Ry) In Wien2k 12 with both changes made in fft_modules.F, TiC.output0 had:
[Wien] New update to SKEAF extremal area program
Dear WIEN2k users, This is an update to let you know that a new version (v1.3.0 r149) of the SKEAF extremal area code for extracting quantum oscillation information from calculated Fermi surfaces has been released. The new version contains several important improvements and bug fixes (see the README-forSKEAF file for details), so users are highly recommended to upgrade to this version. As before, the SKEAF source code and program instructions can be downloaded from the WIEN2k Unsupported software goodies page ( http://www.wien2k.at/reg_user/unsupported/ ). The algorithm underlying the code is described in P.M.C. Rourke and S.R. Julian, Computer Physics Communications 183, 324 (2012) (also available on the arXiv at http://arxiv.org/abs/0803.1895 ). Best regards, Patrick Rourke
