Re: [Wien] how to cut a surface
Dear Fedor,There is a very nice utility in WIEN2k, i.e., structeditor as provided by Robert Laskowski, which can be used not only for making supercell, but also for surface, and many other helpful relevant things. For more information, you would look for structeditor in the usersguide, http://www.wien2k.at/reg_user/textbooks/usersguide.pdf. Warmest regards,Saeid. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Associate Professor of Physics, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-031-3793 2435 Office :+98-031-3793 4776 Fax No. :+98-031-3793 2800 E-mail :sjal...@sci.ui.ac.ir :sjal...@phys.ui.ac.ir :saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ On Thursday, June 25, 2015 12:58 PM, Pascal Boulet pascal.bou...@univ-amu.fr wrote: Hi, You may want to try VESTA: http://jp-minerals.org/vesta/en/ RegardsPascal Le 25 juin 2015 à 09:11, Fedor Bystrenko fedor.bystre...@mail.ru a écrit : Hi, Are there any utils in WIEN package for supercell creation? I'm interested not just to enlarge the unit cell, but also to rotate it and cut a surface along some direction. For example, I take a unit cell of wurzite SiC and want to create a surface with [10-10] orientation. Another question is how to rotate a crystal cell to a given angle along one axis. Any advices/ papers/algorithms are appreciated. Regards, Fedor Bystrenko ___ 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 -- Pascal Boulet - MCF HDR, Resp. L1 MPCI - DEPARTEMENT CHIMIEAix-Marseille Université - ST JEROME - Avenue Escadrille Normandie Niemen - 13013 MarseilleTél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50Site : http://allos.up.univ-mrs.fr/pascal - Email : pascal.boulet@univ-amu.frAfin de respecter l'environnement, merci de n'imprimer cet email que si nécessaire. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] a minor typos in defining nband
In page 119 of the usersguide version 14.2 for describing case.in1, nband is defined as nband=ne*2+5, which would be modified as nband=ne/2+5 in the next version. For si111.struct in example_struct_files with S.E.=-6.0 Ry, ne will be 8 in si111.in2, and nband will be 10 in case.in1, and the last :BAN009 will be in si111.scf for Emax=1.5 Ry. :BAN009=9=8/2+5 but nband=10=8/2+5+1. :BAN009 varies with Emax, but nband in case.in1 is determined in lstart. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Associate Professor of Physics, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No. :+98-0311-793 2800 E-mail :sjal...@sci.ui.ac.ir :sjal...@phys.ui.ac.ir :saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/___ 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] open core
Hi Peter, Messages like: it fails do not tell us anything and you will not get any hint. Maybe in my mind, I had imagined that since in the cited link the case, Yb, and all of the steps were clerkly discussed, my further explanation was extra and not necessary. As far as I remember, the open core calculations for the Yb sample, as discussed in the link, worked fine (with no need to do special things) with the old version of the code, i.e., WIEN97. However, now I believe that you are absolutely right, and I had to explain the problem. It fails due to the QTL-B problem. But, this is a problem that we ourselves cause it to occur. One of the steps, as a trick, for performing the open core calculations is to change the energy parameter of the f-electrons in case.in1 file to something like -1.0 Ry to avoid to be found the 4f-states by the lapw1, see the link: 3 -1.00 0.000 CONT 1 So, in the open core we cannot get back (?) and try to cure the the ghost band problem. This is why I asked is it possible at all to do linearization by adding in1new in the open core calculations -- in open core calculations we should not change the above line. So the problem is how to fix the ghost band problem in open-core calculations, where we are not allowed to change the trick -- the source of the problem originates from the method used. Warmest regards, Saeid. From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Sent: Saturday, October 12, 2013 11:38 AM Subject: Re: [Wien] open core Messages like: it fails do not tell us anything and you will not get any hint. Am 12.10.2013 00:50, schrieb Saeid Jalali: It is true that open core is an old method, and we can now use other more advanced methods like LDA+U, EECE, and DMFT+U. But, just as a test, I tried to repeat the example given in the following link within the latest version of the code: http://www.wien2k.at/reg_user/faq/open_core.html But, it fails after some iterations. It appears that the new advanced changes made in the code do not allow to perform such an old calculation. Would someone check whether the above Yb example can be ran by the WIEN2k_13.1 or some modifications in the above link are needed? Can we add in1new or in1ef flags to the open core calculation? Does linearization make sense with open core treatments? Best regards, Saeid. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] open core
Thank you Xavier for your suggestion. I agree with you, but I would like to do a test by the old pen core method. From: Rocquefelte xavier.rocquefe...@cnrs-imn.fr To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Sent: Saturday, October 12, 2013 11:32 AM Subject: Re: [Wien] open core I continue my reply (sorry for that). Look at the userguide and the note of Pawel Novak about LDA+U calculations. It is really easy to use such an approach and it gives better results than open core Regards Xavier Le 10/12/2013 12:50 AM, Saeid Jalali a écrit : It is true that open core is an old method, and we can now use other more advanced methods like LDA+U, EECE, and DMFT+U. But, just as a test, I tried to repeat the example given in the following link within the latest version of the code: http://www.wien2k.at/reg_user/faq/open_core.html But, it fails after some iterations. It appears that the new advanced changes made in the code do not allow to perform such an old calculation. Would someone check whether the above Yb example can be ran by the WIEN2k_13.1 or some modifications in the above link are needed? Can we add in1new or in1ef flags to the open core calculation? Does linearization make sense with open core treatments? Best regards, Saeid. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien 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] open core
Still not very informative. Sorry for that. qtl-error: which atom (here of course Yb), which l ?? At first for l=3. If it is l=3, then you have to modify the l=3 parameter. Try to set it to -2 Ry or alternatively, to +2Ry. By considering and applying your valuable comment, the l=3 QTL-B problem is fixed, thanks to you. Then after more iterations the QTL-B is occurred for l=1 and l=2. But, I could fix them. I also noticed that in1ef can be applied when we are running open-core calculations. The energy parameter in case.in1 is not changed for l=3 but for other l's, as expected. So everything goes well, and I would like here to appreciate you once more. Warmest regards, Saeid. From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Sent: Saturday, October 12, 2013 9:41 PM Subject: Re: [Wien] open core Still not very informative. qtl-error: which atom (here of course Yb), which l ?? If it is l=3, then you have to modify the l=3 parameter. Try to set it to -2 Ry or alternatively, to +2Ry. Am 12.10.2013 12:31, schrieb Saeid Jalali: Hi Peter, Messages like: it fails do not tell us anything and you will not get any hint. Maybe in my mind, I had imagined that since in the cited link the case, Yb, and all of the steps were clerkly discussed, my further explanation was extra and not necessary. As far as I remember, the open core calculations for the Yb sample, as discussed in the link, worked fine (with no need to do special things) with the old version of the code, i.e., WIEN97. However, now I believe that you are absolutely right, and I had to explain the problem. It fails due to the QTL-B problem. But, this is a problem that we ourselves cause it to occur. One of the steps, as a trick, for performing the open core calculations is to change the energy parameter of the f-electrons in case.in1 file to something like -1.0 Ry to avoid to be found the 4f-states by the lapw1, see the link: 3 -1.00 0.000 CONT 1 So, in the open core we cannot get back (?) and try to cure the the ghost band problem. This is why I asked is it possible at all to do linearization by adding in1new in the open core calculations -- in open core calculations we should not change the above line. So the problem is how to fix the ghost band problem in open-core calculations, where we are not allowed to change the trick -- the source of the problem originates from the method used. Warmest regards, Saeid. * * *From:* Peter Blaha pbl...@theochem.tuwien.ac.at *To:* A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at *Sent:* Saturday, October 12, 2013 11:38 AM *Subject:* Re: [Wien] open core Messages like: it fails do not tell us anything and you will not get any hint. Am 12.10.2013 00:50, schrieb Saeid Jalali: It is true that open core is an old method, and we can now use other more advanced methods like LDA+U, EECE, and DMFT+U. But, just as a test, I tried to repeat the example given in the following link within the latest version of the code: http://www.wien2k.at/reg_user/faq/open_core.html But, it fails after some iterations. It appears that the new advanced changes made in the code do not allow to perform such an old calculation. Would someone check whether the above Yb example can be ran by the WIEN2k_13.1 or some modifications in the above link are needed? Can we add in1new or in1ef flags to the open core calculation? Does linearization make sense with open core treatments? Best regards, Saeid. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1
[Wien] open core
It is true that open core is an old method, and we can now use other more advanced methods like LDA+U, EECE, and DMFT+U. But, just as a test, I tried to repeat the example given in the following link within the latest version of the code: http://www.wien2k.at/reg_user/faq/open_core.html But, it fails after some iterations. It appears that the new advanced changes made in the code do not allow to perform such an old calculation. Would someone check whether the above Yb example can be ran by the WIEN2k_13.1 or some modifications in the above link are needed? Can we add in1new or in1ef flags to the open core calculation? Does linearization make sense with open core treatments? Best regards, Saeid. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Error in mBJGGA
Dear Sajjad, I made a mistake in case.in0_grr by selecting indxc value 55 instead of 50, and I am repeating this mistake for two days :( In order to avoid such a mistake, you can use init_mbj_lapw script twice. This script automatically (in its second run) edits case.in0 and sets indxc to 28 and copes case.in0 to case.ino_grr and sets indxc to 50 in case.in0_grr. For more information see 4.5.9 section of the users guide. Sincerely yours, S. Jalali From: Muhammad Sajjad sajja...@gmail.com To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Sent: Tuesday, September 3, 2013 1:15 PM Subject: Re: [Wien] Error in mBJGGA Dear F. Tran Thank you for correction. I made a mistake in case.in0_grr by selecting indxc value 55 instead of 50, and I am repeating this mistake for two days :( True Regards M. Sajjad On Tue, Sep 3, 2013 at 3:57 PM, t...@theochem.tuwien.ac.at wrote: Hi, you have probably not selected the correct value for indxc in case.in0 or case.in0_grr. It should be 28 in case.in0 and 50 in case.in0_grr. I guess that you did it correctly for 0.25 doping. F. Tran On Tue, 3 Sep 2013, Muhammad Sajjad wrote: Dear Wien2k users I am am running mBJGGA calculations for ternary alloy. the super cell is of 8 atoms and doping is 0.75. For 0.25 doping, the mBJGGA calculations (spin is involved) have completed with no error, but for 0.75 doping the following error is appearing. [msajjad@msajjad SCF75]$ runsp_lapw -cc 0.1 -in1new 2 -i 100 -NI forrtl: severe (24): end-of-file during read, unit 60, file /home/msajjad/3rdpaper/MgVTe/SCF75/SCF75.inhf Image PC Routine Line Source lapw0 005405AD Unknown Unknown Unknown lapw0 0053F0B5 Unknown Unknown Unknown lapw0 004DF760 Unknown Unknown Unknown lapw0 0049E7AA Unknown Unknown Unknown lapw0 0049DFA0 Unknown Unknown Unknown lapw0 004BDE9C Unknown Unknown Unknown lapw0 00441273 MAIN__ 255 lapw0.F lapw0 00403BAC Unknown Unknown Unknown libc.so.6 0034BF01ECDD Unknown Unknown Unknown lapw0 00403AA9 Unknown Unknown Unknown stop error Please help me to overcome this problem. With thanks M. Sajjad ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien 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] (no subject)
It was answered, see the following link: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08931.html Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No. :+98-0311-793 4800 E-mail :sjal...@phys.ui.ac.ir :sjal...@sci.ui.ac.ir :sjal...@mailaps.org :saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Yasir Ali yasiralikhan...@yahoo.com To: wien wien@zeus.theochem.tuwien.ac.at Sent: Friday, July 12, 2013 8:36 AM Subject: [Wien] (no subject) Hi. I need to know how to use LDA+U method for exchange and correlation and when it is suitable to use? Regards: Yasir Ali ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] WIEN2k_13
Hi Peter, Congratulation! I would like here to appreciate your nice efforts in releasing the new WIEN2k version 13.1 including the important chemical shift NMR calculations based on PHYSICAL REVIEW B 85, 035132 (2012) . I see that siteconfig_lapw is now more friendly helps the users to install the code. Although the new usersguide, Release 06/25/2013, is included in the $WIENROOT/SRC/ directory, the following link (Release 30.08.2012) is not still updated: http://www.wien2k.at/reg_user/textbooks/usersguide.pdf Thank you again, Best regards, Saeid. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No. :+98-0311-793 4800 E-mail :sjal...@phys.ui.ac.ir :sjal...@sci.ui.ac.ir :sjal...@mailaps.org :saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Sent: Tuesday, June 25, 2013 8:08 PM Subject: [Wien] WIEN2k_13 Dear Wien2k users. It's a pleasure to announce the new WIEN2k version 13.1 It contains several new features and in particular also the new NMR (Chemical shift) module. For more information see http://www.wien2k.at/reg_user/updates PS: Of course, the update is free of charge for all registered users, even when you registered back in 2001 !! Good luck -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] TB-mBJ for a metal?!
Dear WIEN2k group,We are studding an insulator within TB-mBJ, and our calculated band gap with the c_opt is in excellent agreement with experiment. Our PBE-GGA result shows that this insulator becomes a metal by doping an impurity in agreement with experiment. Our TB-mBJ calculation for the latter metal cannot be well converged after a lot of iterations. We doped the insulator by another impurity so that it remains insulator. For the latter insulator the TB-mBJ calculation is quickly and well converged.At first glance, it brings in mind that the TB-mBJ may not be applied on a metal. But, we are not sure.Any comments will help us. Thank you. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No. :+98-0311-793 4800 E-mail :sjal...@phys.ui.ac.ir :sjal...@sci.ui.ac.ir :sjal...@mailaps.org :saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ 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] x kgen -hf
So in this case, can the run_kgenhf_lapw script a little bit simplifies as follows? -original run_kgenhf_lapw---...x kgen -hfmv $file.klist $file.klist_ibzmv $file.kgen $file.kgen_ibz x kgen -fbzmv $file.klist $file.klist_fbzmv $file.kgen $file.kgen_fbz if ( $redklist == 'redklist' ) then? echo Choose a reduced k-mesh which is a subset of the original one.? sleep 1? x kgen -fbz? mv $file.klist $file.klist_rfbzendif cp $file.klist_ibz $file.klistcp $file.kgen_ibz $file.kgen-end -simplified run_kgenhf_lapw--?x kgen -fbzmv $file.klist $file.klist_fbzmv $file.kgen $file.kgen_fbz x kgen -hfcp $file.klist $file.klist_ibzcp $file.kgen $file.kgen_ibz if ( $redklist == 'redklist' ) then? echo Choose a reduced k-mesh which is a subset of the original one.? sleep 1? x kgen -fbz? mv $file.klist $file.klist_rfbzendif-end--- Two last lines of the script can be removed if we exchange the locations of the x kgen -hf and x kgen -fbz and their associated mv commands. Right? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --- On Sat, 3/16/13, f.tran at pci.uzh.ch f.tran at pci.uzh.ch wrote: From: f.tran at pci.uzh.ch f.t...@pci.uzh.ch Subject: [Wien] x kgen -hf To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: Saturday, March 16, 2013, 7:02 AM -hf only means that in addition case.outputkgenhf is generated. The other files are not changed. F. Tran -wien-bounces at zeus.theochem.tuwien.ac.at wrote: -To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at From: Saeid Jalali Sent by: wien-bounces at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: 03/16/2013 02:13PM Subject: [Wien] x kgen -hf =?= x kgen Hi,Are there any differences between x kgen -hf and?x kgen? For a (one atomic) fcc case, the generated case.klist, case.kgen, and case.outputkgen files by x kgen are found to be the same as those generated by x kgen -hf. When do the differences appeared? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -Inline Attachment Follows- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130316/5c5f0cdb/attachment.htm
[Wien] runsp_lapw -hf -p
Thanks. The problem is fixed by your perfect comment concerning the shift of the klist. --- On Thu, 3/14/13, f.tran at pci.uzh.ch f.tran at pci.uzh.ch wrote: From: f.tran at pci.uzh.ch f.t...@pci.uzh.ch Subject: Re: [Wien] runsp_lapw -hf -p To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Cc: Saeid Jalali s_jalali_a at yahoo.com List-Post: wien@zeus.theochem.tuwien.ac.at Date: Thursday, March 14, 2013, 8:13 AM When you execute run_kgenhf_lapw, at the 2nd line on your screen it is written Use identical inputs for both runs (number of k-points / shift). In your case you can not shift the k-mesh for case.klist_ibz (the 1st time your are asked to provide the k-mesh), and therefore you have to say no (0) when you are asked to shift or not for case.klist_fbz (the 2nd time your are asked to provide the k-mesh). case.klist_ibz and case.klist_fbz should correspond to the same k-mesh (both shifted or not). F. Tran -Saeid Jalali s_jalali_a at yahoo.com wrote: -To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at From: Saeid Jalali s_jalal...@yahoo.com List-Post: wien@zeus.theochem.tuwien.ac.at Date: 03/14/2013 03:01PM Cc: f.tran at pci.uzh.ch Subject: Re: [Wien] runsp_lapw -hf -p Dear Fabien, Thank you for your reply.? The requested files are attached to this email. In addition, attached contains case.inhf, case.in0_grr. We initialized the structure file by?init_lapw -b -ecut -9.0 -vxc 13 -numk 100.? We tested and found that the problem is not due to the MPI parallelization. Indeed, the error occurs when we run the case without -p flag. It appears that the needed files for the hf program are not generated properly.? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --- On Thu, 3/14/13, f.tran at pci.uzh.ch f.tran at pci.uzh.ch wrote: From: f.tran at pci.uzh.ch f.tran at pci.uzh.ch Subject: [Wien] runsp_lapw -hf -p To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: Thursday, March 14, 2013, 5:29 AM Hi, I would need your files case.struct, case.klist_ibz, case.klist_fbz and case.outputkgenhf to see what is the problem. F. Tran -wien-bounces at zeus.theochem.tuwien.ac.at wrote: -To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at From: Saeid Jalali Sent by: wien-bounces at zeus.theochem.tuwien.ac.at List-Post: wien@zeus.theochem.tuwien.ac.at Date: 03/13/2013 02:22PM Subject: [Wien] runsp_lapw -hf -p Dear All, We would perform screened hybrid functional calculations using k-point and MPI paralyzations. We have followed the ?steps discussed in the?4.5.8 section of the?usersguide.? The case.klist_ibz, case.kgen_ibz, case.klist_fbz, case.kgen_fbz, and case.outputkgenhf?files?are generated by run_kgenhf_lapw script (x kgen -hf and x kgen -fbz). But, we got the following error in the first iteration:?error in create_stars 2 runsp_lapw -hf -p -in1ef -cc 0.1?Wed Mar 13 16:15:23 IRST 2013 (x) lapw0 -grr -pWed Mar 13 16:15:36 IRST 2013 (x) lapw0 -pWed Mar 13 16:15:49 IRST 2013 (x) lapw1 -up -pWed Mar 13 16:16:05 IRST 2013 (x) lapw1 -dn -pWed Mar 13 16:16:23 IRST 2013 (x) lapw2 -up -pWed Mar 13 16:16:35 IRST 2013 (x) sumpara -up -dWed Mar 13 16:16:37 IRST 2013 (x) lapw2 -dn -pWed Mar 13 16:16:53 IRST 2013 (x) sumpara -dn -dWed Mar 13 16:16:54 IRST 2013 (x) lcore -upWed Mar 13 16:16:55 IRST 2013 (x) lcore -dnWed Mar 13 16:16:55 IRST 2013 (x) hf -up -p We repeated the calculations by adding the -nonself flag to our runsp_lapw, but the same error occurs.We detected that the source of this error originates from the zero value for the nok parameter used in?create_stars.f program:create_stars.f: ? ? ? ?if (nok .eq. 0) stop 'error in create_stars 2' Can be this problem due to the MPI parallelization?? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali
[Wien] runsp_lapw -hf -p
Dear All, We would perform screened hybrid functional calculations using k-point and MPI paralyzations. We have followed the ?steps discussed in the?4.5.8 section of the?usersguide.? The case.klist_ibz, case.kgen_ibz, case.klist_fbz, case.kgen_fbz, and case.outputkgenhf?files?are generated by run_kgenhf_lapw script (x kgen -hf and x kgen -fbz). But, we got the following error in the first iteration:?error in create_stars 2 runsp_lapw -hf -p -in1ef -cc 0.1?Wed Mar 13 16:15:23 IRST 2013 (x) lapw0 -grr -pWed Mar 13 16:15:36 IRST 2013 (x) lapw0 -pWed Mar 13 16:15:49 IRST 2013 (x) lapw1 -up -pWed Mar 13 16:16:05 IRST 2013 (x) lapw1 -dn -pWed Mar 13 16:16:23 IRST 2013 (x) lapw2 -up -pWed Mar 13 16:16:35 IRST 2013 (x) sumpara -up -dWed Mar 13 16:16:37 IRST 2013 (x) lapw2 -dn -pWed Mar 13 16:16:53 IRST 2013 (x) sumpara -dn -dWed Mar 13 16:16:54 IRST 2013 (x) lcore -upWed Mar 13 16:16:55 IRST 2013 (x) lcore -dnWed Mar 13 16:16:55 IRST 2013 (x) hf -up -p We repeated the calculations by adding the -nonself flag to our runsp_lapw, but the same error occurs.We detected that the source of this error originates from the zero value for the nok parameter used in?create_stars.f program:create_stars.f: ? ? ? ?if (nok .eq. 0) stop 'error in create_stars 2' Can be this problem due to the MPI parallelization?? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130313/7fce58e1/attachment.htm
[Wien] magnetic with Wien2k
In order to add spin polarization (SP), one needs to use runsp_lapw instead of run_lapw. In order to add orbital polarization (OP), one can run LDA+U by adding -orb flag to the runsp_lapw for the magnetic systems or run_c_lapw for the nonmagnetic systems. To this end, one needs to include an appropriate input file for the LAPWDM program (case.indm) and another appropriate file for the ORB program (case.inorb). I suggest to read the users guide for more detail. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Mohamed ouaissa m.ouaissa at yahoo.fr To: Wien at zeus.theochem.tuwien.ac.at Wien at zeus.theochem.tuwien.ac.at Sent: Friday, October 12, 2012 9:09 PM Subject: [Wien] magnetic with Wien2k Dear users of WIEN2k, I have started using wien2k and it works fine in non magnetic case but i m interesting in magnetic case and i dont know what i should do, can someone help me please. I want to do the calculation of spinpolarized with LSDA+U, i would appreciate if someone can help me telling me what i should do in some steps, like in the first step? what i should choose here: CREATE A NEW .inst FILE with PROPER ATOMS Eventually specify switches for instgen_lapw (or press ENTER): -up (default) -dn -nm (non-magnetic) -ask How can i know if i m using LSDA or LSDA+U in this step or there is another step where i will know it: lstart (20:40:42) SELECT XCPOT: recommended: 13: PBE-GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew etal. 2008) Thanks in advance for your response. Mohamed Ouaissa ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121013/e17da21d/attachment.htm
[Wien] two problems in the WIEN2k web site
Dear Peter, There are two problems in the WIEN2k web site: 1) There is a permission,?a 403 Forbidden error, to access the following link in the WIEN2k server--chmod is needed to remove the permission.? http://www.wien2k.at/reg_user/textbooks/Mixer_README_4.1.pdf? 2) New users encounter the following bug when they would register in the WIEN2k mailinglist: Bug in Mailman version 2.1.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Your attention to these problems are highly appreciated. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121010/779c456e/attachment.htm
[Wien] two problems in the WIEN2k web site
Hi again, Thank you for fixing 1. The link now works fine. For fixing the problem number 2, the chmod is needed too.?The information given in the following link may help: http://www.linuxspy.info/tag/bug-in-mailman-version-2-1-11-cp3/? ? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, October 10, 2012 2:49 PM Subject: Re: [Wien] two problems in the WIEN2k web site Thank's. I've fixed 1). I don't know how to fix 2), but as far as I know the subscription still works, even when you get this message. Am 10.10.2012 11:59, schrieb Saeid Jalali: Dear Peter, There are two problems in the WIEN2k web site: 1) There is a permission, a 403 Forbidden error, to access the following link in the WIEN2k server--chmod is needed to remove the permission. http://www.wien2k.at/reg_user/textbooks/Mixer_README_4.1.pdf http://www.wien2k.at/reg_user/textbooks/Mixer_README_4.1.pdf 2) New users encounter the following bug when they would register in the WIEN2k mailinglist: ? ? Bug in Mailman version 2.1.11 ? ? ? We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Your attention to these problems are highly appreciated. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys.? :+98-0311-793 2435 Office? ? ? ? ? ? ? :+98-0311-793 4776 Fax No.? ? ? ? ? ? :+98-0311-793 4800 E-mail? ? ? ? ? ? ? :sjalali at phys.ui.ac.ir mailto:sjalali at phys.ui.ac.ir ? ? :sjalali at sci.ui.ac.ir mailto:sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org mailto:sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com mailto:saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com mailto:s_jalali_a at yahoo.com Homepage? ? ? ? :http://sci.ui.ac.ir/~sjalali http://sci.ui.ac.ir/%7Esjalali www? ? ? ? ? ? ? ? ? :http://www.ui.ac.ir http://www.ui.ac.ir/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ 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.at? ? WWW: 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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121010/5f0a8bda/attachment.htm
[Wien] permop.f
Dear All, In page 23 of the? Introduction to dmftproj, Tutorial Dmftpfoj.pdf, is stated that: Some changes must also be made in the package SRC_lapw2 of Wien2k, which must be then recompiled. The modified subroutines in the package are: ? l2main.F ? latgen.f ? rotmat_dmft.f (new) ? permop.f (new) But, it is not clear what changes should be made. In addition, the latter permop.f is not in the SRC_lapw2 of the latest version of wien2k code, version 12.1. It is? not also in the TRIQS code. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120812/050c318e/attachment.htm
[Wien] SRC_lapw0/compile.msg in WIEN2k_12.1
Hi Peter, Thank you for your comments. Yes, I installed the latest version of the fftw, fftw-3.3.2, and compiled successfully the WINE2k_12.1 using the -DFFTW3 too by giving the right path: RP ?RP_LIB(SCALAPACK+PBLAS): -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 -L/opt/local/fftw3/lib -lfftw3_mpi -lfftw3 $(R_LIBS) ?? ? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, July 26, 2012 12:26 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Or by putting the correct path and library-names into the R_LIBS field: ? ? ? -L/opt/local/fftw/lib/? ? ? ? ? -lfftw_mpi? -lfftw ---? -L/path-where-fftw3-is-installed -lfftw3_mpi -lfftw3 PS: For best performance on Intel-systems in sequential mode, see the comment in the UG? Chapter 11.1.1 about the mkl interface to fftw2xf? (or fftw3xf) Am 25.07.2012 17:42, schrieb Saeid Jalali: Hi Laurence, Thank you for your prompt reply. The problem is fixed by changing the -DFFTW3 to -DFFTW2! How did you find that? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys.? :+98-0311-793 2435 Office? ? ? ? ? ? ? :+98-0311-793 4776 Fax No.? ? ? ? ? ? :+98-0311-793 4800 E-mail? ? ? ? ? ? ? :sjalali at phys.ui.ac.ir mailto:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at sci.ui.ac.ir mailto:sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org mailto:sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com mailto:saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com mailto:s_jalali_a at yahoo.com Homepage? ? ? ? :http://sci.ui.ac.ir/~sjalali http://sci.ui.ac.ir/%7Esjalali www? ? ? ? ? ? ? ? ? :http://www.ui.ac.ir http://www.ui.ac.ir/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 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.at? ? WWW: 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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120726/53cd9fde/attachment.htm
[Wien] SRC_lapw0/compile.msg in WIEN2k_12.1
In addition to composerxe-2011.2.137, I tried to compile the latest version of the code using l_cprof_p_11.1.073_intel64. The code is successfully comiled?using?l_cprof_p_11.1.073_intel64, mpich-1.2.7p1, fftw-2.1.5 and -DFFTW2.?But, there are several errors when I use??l_cprof_p_11.1.073_intel64, mpich-1.2.7p1, fftw-3.3.3 and -DFFTW3. This is in the case that there is not such a problem when I use composerxe-2011.2.137, mpich-1.2.7p1, fftw-3.3.3 and -DFFTW3. ? Hi Peter, Thank you for your comments. Yes, I installed the latest version of the fftw, fftw-3.3.2, and compiled successfully the WINE2k_12.1 using the -DFFTW3 too by giving the right path: RP ?RP_LIB(SCALAPACK+PBLAS): -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 -L/opt/local/fftw3/lib -lfftw3_mpi -lfftw3 $(R_LIBS) ?? ? From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, July 26, 2012 12:26 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Or by putting the correct path and library-names into the R_LIBS field: ? ? ? -L/opt/local/fftw/lib/? ? ? ? ? -lfftw_mpi? -lfftw ---? -L/path-where-fftw3-is-installed -lfftw3_mpi -lfftw3 PS: For best performance on Intel-systems in sequential mode, see the comment in the UG? Chapter 11.1.1 about the mkl interface to fftw2xf? (or fftw3xf) Am 25.07.2012 17:42, schrieb Saeid Jalali: Hi Laurence, Thank you for your prompt reply. The problem is fixed by changing the -DFFTW3 to -DFFTW2! How did you find that? ? From: Laurence Marks l-ma...@northwestern.edu To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 8:14 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 It is in the userguide/release notes On Wed, Jul 25, 2012 at 10:42 AM, Saeid Jalali s_jalali_a at yahoo.com wrote: Hi Laurence, Thank you for your prompt reply. The problem is fixed by changing the -DFFTW3 to -DFFTW2! How did you find that? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys.? :+98-0311-793 2435 Office? ? ? ? ? ? ? :+98-0311-793 4776 Fax No.? ? ? ? ? ? :+98-0311-793 4800 E-mail? ? ? ? ? ? ? :sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage? ? ? ? :http://sci.ui.ac.ir/~sjalali www? ? ? ? ? ? ? ? ? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Laurence Marks L-marks at northwestern.edu To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 7:52 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Did you use -DFFTW2 in the parallel compile options? The first time around I forgot, but when I added this there were no problems. On Wed, Jul 25, 2012 at 10:19 AM, Saeid Jalali s_jalali_a at yahoo.com wrote: Hi Peter, I compiled the new version of the code, WIEN2k_12.1, using mpich-1.2.7p1, fftw-2.1.5, intel composerxe-2011.2.137. I got the following error, as can be seen at the end of the SRC_lapw0/compile.msg file which is attached to this email, ONLY in the lapw0: fft_modules.o: In function `fftw_parallel_mp_prepare_parallel_ffts_': fft_modules.F:(.text+0x43): undefined reference to `fftw_mpi_init' fft_modules.F:(.text+0xfe): undefined reference to `fftw_mpi_local_size_3d_f03' fft_modules.F:(.text+0x10f): undefined reference to `fftw_alloc_complex' fft_modules.o: In function `fftw_parallel_mp_c3fft_': fft_modules.F:(.text+0xcf0): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x198b): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x3639): undefined reference to `fftw_mpi_plan_dft_3d_f03' fft_modules.F:(.text+0x42e9): undefined reference to `fftw_mpi_plan_dft_3d_f03' make[1]: *** [lapw0_mpi] Error 1 make[1]: Leaving directory `/usr/local/codes/wien2k/v12.1/SRC_lapw0' make: *** [para] Error 2 The SRC_x/compile.msg files are free of any errors apart from x=lapw0. There are no such errors in the WIEN2k_11.1. The lapw0 of the WIEN2k_11.1 is compiled and the whole of the code works smoothly. Is something changed in the lapw0 of the new version so that we must consider additional tasks for compiling the mpi version of the code? -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120726/b0dd4ef1/attachment.htm
[Wien] SRC_lapw0/compile.msg in WIEN2k_12.1
Please, ignore my last report! I should report that the problem, reported below, was not due to the?l_cprof_p_11.1.073_intel64. It was due to my used mpich version. Indeed, Although I had installed?mpich-1.2.7p1,?my used mpich was another mpich and not?mpich-1.2.7p1.?I reinstalled the fftw3 enabling?mpich-1.2.7p1, and reinstalled the code successfully with??l_cprof_p_11.1.073_intel64, mpif90 of mpich-1.2.7p1, fftw-3.3.3 and -DFFTW3 on an AMD system as well.? From: Saeid Jalali s_jalal...@yahoo.com To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, July 26, 2012 5:53 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 In addition to composerxe-2011.2.137, I tried to compile the latest version of the code using l_cprof_p_11.1.073_intel64. The code is successfully comiled?using?l_cprof_p_11.1.073_intel64, mpich-1.2.7p1, fftw-2.1.5 and -DFFTW2.?But, there are several errors when I use??l_cprof_p_11.1.073_intel64, mpich-1.2.7p1, fftw-3.3.3 and -DFFTW3. This is in the case that there is not such a problem when I use composerxe-2011.2.137, mpich-1.2.7p1, fftw-3.3.3 and -DFFTW3. ? Hi Peter, Thank you for your comments. Yes, I installed the latest version of the fftw, fftw-3.3.2, and compiled successfully the WINE2k_12.1 using the -DFFTW3 too by giving the right path: RP ?RP_LIB(SCALAPACK+PBLAS): -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 -L/opt/local/fftw3/lib -lfftw3_mpi -lfftw3 $(R_LIBS) ?? ? ? From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, July 26, 2012 12:26 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Or by putting the correct path and library-names into the R_LIBS field: ? ? ? -L/opt/local/fftw/lib/? ? ? ? ? -lfftw_mpi? -lfftw ---? -L/path-where-fftw3-is-installed -lfftw3_mpi -lfftw3 PS: For best performance on Intel-systems in sequential mode, see the comment in the UG? Chapter 11.1.1 about the mkl interface to fftw2xf? (or fftw3xf) Am 25.07.2012 17:42, schrieb Saeid Jalali: Hi Laurence, Thank you for your prompt reply. The problem is fixed by changing the -DFFTW3 to -DFFTW2! How did you find that? ? From: Laurence Marks l-ma...@northwestern.edu To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 8:14 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 It is in the userguide/release notes On Wed, Jul 25, 2012 at 10:42 AM, Saeid Jalali s_jalali_a at yahoo.com wrote: Hi Laurence, Thank you for your prompt reply. The problem is fixed by changing the -DFFTW3 to -DFFTW2! How did you find that? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys.? :+98-0311-793 2435 Office? ? ? ? ? ? ? :+98-0311-793 4776 Fax No.? ? ? ? ? ? :+98-0311-793 4800 E-mail? ? ? ? ? ? ? :sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage? ? ? ? :http://sci.ui.ac.ir/~sjalali www? ? ? ? ? ? ? ? ? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Laurence Marks L-marks at northwestern.edu To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 7:52 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Did you use -DFFTW2 in the parallel compile options? The first time around I forgot, but when I added this there were no problems. On Wed, Jul 25, 2012 at 10:19 AM, Saeid Jalali s_jalali_a at yahoo.com wrote: Hi Peter, I compiled the new version of the code, WIEN2k_12.1, using mpich-1.2.7p1, fftw-2.1.5, intel composerxe-2011.2.137. I got the following error, as can be seen at the end of the SRC_lapw0/compile.msg file which is attached to this email, ONLY in the lapw0: fft_modules.o: In function `fftw_parallel_mp_prepare_parallel_ffts_': fft_modules.F:(.text+0x43): undefined reference to `fftw_mpi_init' fft_modules.F:(.text+0xfe): undefined reference to `fftw_mpi_local_size_3d_f03' fft_modules.F:(.text+0x10f): undefined reference to `fftw_alloc_complex' fft_modules.o: In function `fftw_parallel_mp_c3fft_': fft_modules.F:(.text+0xcf0): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x198b): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x3639): undefined reference to `fftw_mpi_plan_dft_3d_f03' fft_modules.F:(.text+0x42e9): undefined reference to `fftw_mpi_plan_dft_3d_f03' make[1]: *** [lapw0_mpi] Error 1 make[1]: Leaving directory `/usr/local/codes/wien2k/v12.1/SRC_lapw0
[Wien] SRC_lapw0/compile.msg in WIEN2k_12.1
Hi Peter, I compiled the new version of the code, WIEN2k_12.1, using mpich-1.2.7p1,?fftw-2.1.5, intel composerxe-2011.2.137.? I got the following error, as can be seen at the end of the SRC_lapw0/compile.msg file which is attached to this email, ONLY in the lapw0: fft_modules.o: In function `fftw_parallel_mp_prepare_parallel_ffts_': fft_modules.F:(.text+0x43): undefined reference to `fftw_mpi_init' fft_modules.F:(.text+0xfe): undefined reference to `fftw_mpi_local_size_3d_f03' fft_modules.F:(.text+0x10f): undefined reference to `fftw_alloc_complex' fft_modules.o: In function `fftw_parallel_mp_c3fft_': fft_modules.F:(.text+0xcf0): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x198b): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x3639): undefined reference to `fftw_mpi_plan_dft_3d_f03' fft_modules.F:(.text+0x42e9): undefined reference to `fftw_mpi_plan_dft_3d_f03' make[1]: *** [lapw0_mpi] Error 1 make[1]: Leaving directory `/usr/local/codes/wien2k/v12.1/SRC_lapw0' make: *** [para] Error 2 The SRC_x/compile.msg files are free of any errors apart from x=lapw0. There are no such errors in the WIEN2k_11.1. The lapw0 of the WIEN2k_11.1 is compiled and the whole of the code works smoothly. ? Is something changed in the lapw0 of the new version so that we must consider additional tasks for compiling the mpi version of the code? ?? ? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 6:14 PM Subject: Re: [Wien] Wien2k 12 It has an? expand_lapw.gz which is unzipped by? gunzip *.gz Am 25.07.2012 11:16, schrieb Jameson Maibam: Dear Prof Blaha, the new upgraded WIEN2k 12 does not have the executable file (expand_lapw). Is it replaced by another name. Yours sincerely Jameson Maibam Assam University ___ 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.at? ? WWW: 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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120725/6cb928d6/attachment-0001.htm -- next part -- A non-text attachment was scrubbed... Name: compile.msg Type: application/octet-stream Size: 17424 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120725/6cb928d6/attachment-0001.dll
[Wien] SRC_lapw0/compile.msg in WIEN2k_12.1
Hi?Laurence, Thank you for your prompt reply. The problem is fixed by changing the?-DFFTW3 to?-DFFTW2! How did you find that? ? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Laurence Marks L-marks at northwestern.edu To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 7:52 PM Subject: Re: [Wien] SRC_lapw0/compile.msg in WIEN2k_12.1 Did you use -DFFTW2 in the parallel compile options? The first time around I forgot, but when I added this there were no problems. On Wed, Jul 25, 2012 at 10:19 AM, Saeid Jalali s_jalali_a at yahoo.com wrote: Hi Peter, I compiled the new version of the code, WIEN2k_12.1, using mpich-1.2.7p1, fftw-2.1.5, intel composerxe-2011.2.137. I got the following error, as can be seen at the end of the SRC_lapw0/compile.msg file which is attached to this email, ONLY in the lapw0: fft_modules.o: In function `fftw_parallel_mp_prepare_parallel_ffts_': fft_modules.F:(.text+0x43): undefined reference to `fftw_mpi_init' fft_modules.F:(.text+0xfe): undefined reference to `fftw_mpi_local_size_3d_f03' fft_modules.F:(.text+0x10f): undefined reference to `fftw_alloc_complex' fft_modules.o: In function `fftw_parallel_mp_c3fft_': fft_modules.F:(.text+0xcf0): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x198b): undefined reference to `fftw_mpi_execute_dft' fft_modules.F:(.text+0x3639): undefined reference to `fftw_mpi_plan_dft_3d_f03' fft_modules.F:(.text+0x42e9): undefined reference to `fftw_mpi_plan_dft_3d_f03' make[1]: *** [lapw0_mpi] Error 1 make[1]: Leaving directory `/usr/local/codes/wien2k/v12.1/SRC_lapw0' make: *** [para] Error 2 The SRC_x/compile.msg files are free of any errors apart from x=lapw0. There are no such errors in the WIEN2k_11.1. The lapw0 of the WIEN2k_11.1 is compiled and the whole of the code works smoothly. Is something changed in the lapw0 of the new version so that we must consider additional tasks for compiling the mpi version of the code? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys.? :+98-0311-793 2435 Office? ? ? ? ? ? ? :+98-0311-793 4776 Fax No.? ? ? ? ? ? :+98-0311-793 4800 E-mail? ? ? ? ? ? ? :sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage? ? ? ? :http://sci.ui.ac.ir/~sjalali www? ? ? ? ? ? ? ? ? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Wednesday, July 25, 2012 6:14 PM Subject: Re: [Wien] Wien2k 12 It has an? expand_lapw.gz which is unzipped by? gunzip *.gz Am 25.07.2012 11:16, schrieb Jameson Maibam: Dear Prof Blaha, the new upgraded WIEN2k 12 does not have the executable file (expand_lapw). Is it replaced by another name. Yours sincerely Jameson Maibam Assam University ___ 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.at? ? WWW: 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 -- 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
[Wien] mpif90
Dear All, I compiled the latest version of the code on a cluster made up of several Dual Core AMD Opteron nodes by ifort and mpif90. There is no any error or warning in the SRC_*/compile.msg files. The code runs well on the nodes, if we only parallelize the k-points by for example the following .machines file: ?lapw0:node3 node20 1:node3 1:node20 granularity:1 extrafine:1 But, the program stops with the following error:? ifort: command line warning #10159: invalid argument for option '-m' ifort: command line error: option '-n' is ambiguous once we use the fine grained parallelization by for example the following .machines file: ?lapw0:node3:2 node20:2 1:node3:2 1:node20:2 granularity:1 extrafine:1 I have used l_cprof_p_11.1.073_intel64, fftw-2.1.5, mpich2 for compiling the code, and the following settings. - Current settings: ?O???Compiler options:? ? ? ??-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback ?L???Linker Flags:? ? ? ? ? ??$(FOPT) -L/home/softs/intel/ifort11/mkl/lib/em64t -pthread ?P???Preprocessor flags?? ? ??'-DParallel' ?R???R_LIB (LAPACK+BLAS):?? ??-lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lguide --- ?? ??RP??RP_LIB(SCALAPACK+PBLAS): -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 -L/home/softs/mpich2/lib -lmpich -L/home/softs/fftw-2.1.5/mpi/.libs/ -lfftw_mpi -L/home/softs/fftw-2.1.5/fftw/.libs/ -lfftw $(R_LIBS) ?? ??FP??FPOPT(par.comp.options): -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -I/home/softs/mpch2/include ?? ??MP??MPIRUN commando? ? ? ??: /home/softs/mpich2/bin/mpif90 -machinefile _HOSTS_ -n _NP_ _EXEC_ - The parallel_options is:? - setenv USE_REMOTE 1 setenv MPI_REMOTE 1 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN /home/softs/mpich2/bin/mpif90 -machinefile _HOSTS_ -n _NP_ _EXEC_ --- I changed the mpif90 to mpirun only in the parallel options (just as a test) but I did not recompile the code by mpirun. The result is as follows: LAPW0 END ?LAPW0 END Fatal error in PMPI_Comm_size: Invalid communicator, error stack: PMPI_Comm_size(111): MPI_Comm_size(comm=0x5b, size=0x8aa96c) failed PMPI_Comm_size(69).: Invalid communicator real0m0.050s user0m0.010s sys0m0.038s test.scf1_1: No such file or directory. FERMI - Error cp: cannot stat `.in.tmp': No such file or directory rm: cannot remove `.in.tmp': No such file or directory rm: cannot remove `.in.tmp1': No such file or directory Similar error was occurred when I used mpiexec in the parallel options without recompiling the code.? I found that the Invalid communicator originates from incompatible mpi.h of mpirun or mpiexec with that of mpif90. So I changed back it to mpif90. Since I guessed that the problem originates from the version of mpi, I tried different versions of mpi, i.e., mpich2-1.0.6, mpich2-1.3.1, mpich2-1.4, openmpi-1.4.2. Any comment on why the code is compiled with no error or warning, but it stops with error is highly appreciated.? Is there any restrictions for compiling the code by mpif90 on AMD systems, as discussed above? ? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120531/06000eb4/attachment.htm
[Wien] Vacuum is not optimized, why?
Dear Peter, I meant case.in1c--I am sorry for the mistyped error and thank you for your correction. ??? Yes, you are completely right concerning the RKM reduction due to the NMATMAX. The :RKM is reduced. Its reduction depends on our selected vacuum thickness. The :RKM decreases as the vacuum thickness increases. The NMATMAX is already13000 in param.inc. We will increase it and recompile the lapw1 and make sure that it is unchanged.? Thank you again for you valuable comment. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. ? :+98-0311-793 2435 Office ? ? ? ? ? ? ? :+98-0311-793 4776 Fax No. ? ? ? ? ? ?:+98-0311-793 4800 E-mail ? ? ? ? ? ? ?:sjalali at phys.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ?? ?? :sjalali at sci.ui.ac.ir ? ? ? ? ? ? ? ? ? ? ? ? ? :sjalali at mailaps.org ? ? ? ? ? ? ? ? ? ? ? ? ? :saeid.jalali.asadabadi at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? :s_jalali_a at yahoo.com Homepage ? ? ? ?:http://sci.ui.ac.ir/~sjalali www ? ? ? ? ? ? ? ?? :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Monday, May 21, 2012 3:52 PM Subject: Re: [Wien] Vacuum is not optimized, why? RKmax is defined in case.in1(c), not case.inc. I don't know whar you want to look up in case.inc after an scf-cycle And yes, when unit cells become large, the number of PW could grow beyond what you have defined during installation as NMATMAX? (check SRC_lapw1/param.inc) and then the program would automatically reduce RKMAX such the the matrix size is smaller than NMATMAX. At the same time it will issue a :WAR? and thus you should always check which kind of :WAR appears in the scf file when you see it in :ENE. grep :RKM case.scf? tells you, which actual RKMAX was used. Am 21.05.2012 10:51, schrieb Saeid Jalali: Dear Peter, Thank you for your reply and comment. The Rmt*Kmax is 4 in case.inc at the end of the scf's for every vacuum thickness. Is it possible the program reduces the Rmt*Kmax internally so that we cannot be aware of it just by looking at the case.inc after the end of scf's? We suspected that the WARNINGS originated from the number of k-point--we have used only 1 k-point. We find that the WRNINGS disappear, if we increase the number of k-points. But, we are forced (for some different reasons) to use only 1 k-pint. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No. :+98-0311-793 4800 E-mail :sjalali at phys.ui.ac.ir mailto:sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir mailto:sjalali at sci.ui.ac.ir :sjalali at mailaps.org mailto:sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com mailto:saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com mailto:s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali http://sci.ui.ac.ir/%7Esjalali www :http://www.ui.ac.ir http://www.ui.ac.ir/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --- *From:* Peter Blaha pblaha at theochem.tuwien.ac.at *To:* A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at *Sent:* Monday, May 21, 2012 12:16 PM *Subject:* Re: [Wien] Vacuum is not optimized, why? Look at the reasons for the WARNINGS ! Maybe the program reduced automatically RKmax as you increase the vacuum because of NMATMAX in your installation. Am 21.05.2012 09:30, schrieb Saeid Jalali: ? Dear WIEN2k community, ? We are working on an insulator bio case, ployalanine amino-acid chain, using the latest version of the WIEN2k code, i.e., WIEN2k 11.1, within PBE-GGA. Our structure contains 48 ? atoms. The atoms are C, O, N, and H. The lattice type is P with lattice parameters of a=b=13, c=17 angstrom. We have added vacuum along the c-axis, and increase the vacuum from 5 ? to 25 angstrom. Therefore, c varies from 17+5=22 to 17+25=42 angstrom. The R_MT radii are between 0.67 to 1.2 bohr. We set G_max=20, and RMT*Kmax=4 based on item number 6 of the ? following link, as indicated in the RMT section of the FAQ: ? http://www.wien2k.at/reg_user/faq/rmt.html ? We have used the in1new 3 flag instead of in1ef to avoid ghost band error to run_lapw. ? We select the k-point to be 2x2x1 due to our large lattice parameters which is equivalent to 1 k-point. ? We plotted energy versus vacuum thickness. We observed
[Wien] Problem in using wien2k in parallel mode
It is not straightforward to determine the source of the error by your given incomplete information. What is OMP_NUM_THREADS set to? Did you set an unlimited stacksize? Maybe the problem originates from incompatibility of your linux system and compilers. What are your fortran compiler and MKL library? Did you add -traceback -C to your Compiler options? Iis your system 32 or 64 bit? If your system is 32 (64) bit, did you use 32 (64) bit library? Did you read Compiling Did you read the information given in the FAQ? I suggest to see read carefully the note provided by Gerhard Fecher, see WIEN2k on Linux and ifort (including compiler installation and tips for older versions) (including an external link provided by G.Fecher) in the FAQ: http://www.wien2k.at/reg_user/faq/ifort.html http://www.ghfecher.de/Fecher_CompileIntel.pdf These show that you would first work, and contact with your adminstartor. If your problem is not solved, then you would post your complete information in detail. In this case, I am prety sure that you will most likely receive valuable comments from experts via the active mailinglist of the code. Quoting Bakhtiar ul Haq bakhtiarjadoon at gmail.com: Hi Dear all wien users, Here I am using wien2k_11.1 on Dell quad-core work station with four intel Xeon processors and 12GB RAM in ubuntu 11.10 environment. The system works well for light calculations but for heavy calculations it gives error llike Stack trace terminated abnormally, (174): SIGSEGV, segmentation fault occurred. My system utilizes memory less the 1GB out of 12GB, and it looks like working on a single processor system. I think I am making errors during installation. Kindly suggest me the changes that should be made for parallel installations as compared to installation on a single processor.. Thanks *With Best Regards Bakhtiar Ul Haq ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 4800 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ University of Isfahan (http://www.ui.ac.ir)
[Wien] inclmcopy setup
There are 3 (and not 4) nonequivalent Pu atoms in your structure and inst files. The magnetic ordering in your case.inst file is up-up-dn: ^^ ||| v This may not give zero total magnetic moment, as they cannot cancel each other, if their symmetries are the same. The number of magnetic atoms (with similar symmetries) should be even for doing AFM calculations. If you have 6 Pu atoms, you can define the up-dn-up-dn-up-dn ordering: ^ || v Maybe you need to make double the structure along Z-axis. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of hao wang Sent: Tuesday, February 22, 2011 5:12 AM To: wien at zeus.theochem.tuwien.ac.at Subject: [Wien] inclmcopy setup Dear Prof. Blaha and users, Thank you very much. The PuO2 AF structure file built along (001). 4 Pu have the same symmetry and Pu1=Pu2=up, Pu3=dn. the inst file is attached. the net spin is zero. So please tell me where is wrong. the inst file for 3 kinds of Pu atoms Pu Rn 4 5, 3,3.0 N 5, 3,0.0 N 5,-4,2.0 N 5,-4,0.0 N 6, 2,1.0 N 6, 2,0.0 N 7,-1,1.0 N 7,-1,1.0 N Pu Rn 4 5, 3,3.0 N 5, 3,0.0 N 5,-4,2.0 N 5,-4,0.0 N 6, 2,1.0 N 6, 2,0.0 N 7,-1,1.0 N 7,-1,1.0 N Pu Rn 4 5, 3,0.0 N 5, 3,3.0 N 5,-4,0.0 N 5,-4,2.0 N 6, 2,0.0 N 6, 2,1.0 N 7,-1,1.0 N 7,-1,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N For sure, I used the suggested structure of 4 kinds of Pu atoms like: puo2 P LATTICE,NONEQUIV.ATOMS: 5 MODE OF CALC=RELA unit=bohr 10.318287 10.318287 10.318287 90.00 90.00 90.00 ATOM -1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 8 Pu1NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -2: X=0.5000 Y=0.5000 Z=0. MULT= 1 ISPLIT= 8 Pu2NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -3: X=0.5000 Y=0. Z=0.5000 MULT= 1 ISPLIT= 8 Pu3NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -4: X=0.2500 Y=0.2500 Z=0.2500 MULT= 8 ISPLIT= 8 -4: X=0.7500 Y=0.7500 Z=0.2500 -4: X=0.7500 Y=0.2500 Z=0.7500 -4: X=0.2500 Y=0.7500 Z=0.7500 -4: X=0.2500 Y=0.2500 Z=0.7500 -4: X=0.7500 Y=0.7500 Z=0.7500 -4: X=0.7500 Y=0.2500 Z=0.2500 -4: X=0.2500 Y=0.7500 Z=0.2500 O NPT= 781 R0=0.0001 RMT= 1.92 Z: 8.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -5: X=0. Y=0.5000 Z=0.5000 MULT= 1 ISPLIT= 8 Pu4NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 8 NUMBER OF SYMMETRY OPERATIONS the same process was passed and a Pmmm subgroup is obtained and is neither t nor k relationship with Fm-3m. thank you very much ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] inclmcopy setup
I noticed that the multiplicity of the Pu3 is 2. So, maybe it is not necessary to make double the structure. You can also decompose the Pu3 with MULT=2 to 2 Pu atoms (Pu3 and Pu4), each ones with MULT=1. You can impose two different labels for Pu3 and Pu4 atoms. In this case, you will have 4 Pu nonequivalent atoms in your inst file and do not need to make it double. This will save your CPU time. But, as Peter said, one needs to physically and chemically understand your compound and the symmetry of each atom and its magnetic orderings and so on. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Saeid Jalali Sent: Tuesday, February 22, 2011 7:05 AM To: 'A Mailing list for WIEN2k users' Subject: Re: [Wien] inclmcopy setup There are 3 (and not 4) nonequivalent Pu atoms in your structure and inst files. The magnetic ordering in your case.inst file is up-up-dn: ^^ ||| v This may not give zero total magnetic moment, as they cannot cancel each other, if their symmetries are the same. The number of magnetic atoms (with similar symmetries) should be even for doing AFM calculations. If you have 6 Pu atoms, you can define the up-dn-up-dn-up-dn ordering: ^ || v Maybe you need to make double the structure along Z-axis. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4776 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of hao wang Sent: Tuesday, February 22, 2011 5:12 AM To: wien at zeus.theochem.tuwien.ac.at Subject: [Wien] inclmcopy setup Dear Prof. Blaha and users, Thank you very much. The PuO2 AF structure file built along (001). 4 Pu have the same symmetry and Pu1=Pu2=up, Pu3=dn. the inst file is attached. the net spin is zero. So please tell me where is wrong. the inst file for 3 kinds of Pu atoms Pu Rn 4 5, 3,3.0 N 5, 3,0.0 N 5,-4,2.0 N 5,-4,0.0 N 6, 2,1.0 N 6, 2,0.0 N 7,-1,1.0 N 7,-1,1.0 N Pu Rn 4 5, 3,3.0 N 5, 3,0.0 N 5,-4,2.0 N 5,-4,0.0 N 6, 2,1.0 N 6, 2,0.0 N 7,-1,1.0 N 7,-1,1.0 N Pu Rn 4 5, 3,0.0 N 5, 3,3.0 N 5,-4,0.0 N 5,-4,2.0 N 6, 2,0.0 N 6, 2,1.0 N 7,-1,1.0 N 7,-1,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N For sure, I used the suggested structure of 4 kinds of Pu atoms like: puo2 P LATTICE,NONEQUIV.ATOMS: 5 MODE OF CALC=RELA unit=bohr 10.318287 10.318287 10.318287 90.00 90.00 90.00 ATOM -1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 8 Pu1NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -2: X=0.5000 Y=0.5000 Z=0. MULT= 1 ISPLIT= 8 Pu2NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -3: X=0.5000 Y=0. Z=0.5000 MULT= 1 ISPLIT= 8 Pu3NPT= 781 R0=0.0100 RMT= 2.17 Z: 94.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM -4: X=0.2500 Y=0.2500 Z=0.2500 MULT= 8 ISPLIT= 8
[Wien] mbj on Diamond
Dear Prof. Klier, You would look for brj.f as a keyword in the mailinglist, where the problem (segmentation fault due to the ir) and its solution were discussed. You would either add ir to all calls in vxclm2.f, or just completely remove the ir from brj.f. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Kamil Klier Sent: Thursday, November 11, 2010 6:37 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.8] Re: [Wien] mbj on Diamond Please correct the typo brj.j to brj.f. The query is not affected by this typographic slip. Quoting Kamil Klier kk04 at Lehigh.EDU: Dear Prof. Blaha, Your attached brj.j triggers the following error message after a crash in our CFN-BNL environment: *** LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A79E brj_ 37 brj.f lapw0 0047338D vxclm2_ 534 vxclm2.f lapw0 0047B565 xcpot1_ 365 xcpot1.f lapw0 004393FA MAIN__ 1696 lapw0.F lapw0 00403A1C Unknown Unknown Unknown libc.so.6 00370E01D994 Unknown Unknown Unknown lapw0 00403929 Unknown Unknown Unknown However, the file brj.j_current, which I am now attaching, does not crash in the same runs, although the covergence is very slow. This prompts the questions: Q1: What's wrong with the attached brj.f_current ? Q2: For my curiosity, what does the parameter ir do ? [I have attempted to trace it in vxclm2.f,also attached, where it is referenced, but the calls to BRJ do not include ,ir as you suggest] The runs involved are 128 atom supercells of ZnO with various dopants. The 'regular scf' converges well, the slow convergence occurs in the mBJ runs with option 28 in *in0 and 50 in *in0_grr, even though the PRATT option in *inm is used. I believe I have the latest version of WIEN2k, 10.2. Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, No, use the attached one. Note: it has one more parameter (ir), thus the calling in vxclm2.f should also be modified and ,ir should be added to all calls. Best regards Am 06.11.2010 14:59, schrieb Kamil Klier: Dear Prof. Blaha, Is the brj.f file referred to in this e-mail (attached as brj.f_new) one that should replace any previous brj.f files (for example, attached as brj.f_old)? Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF
[Wien] MBJ Problem
Dear all, Recently, I reported the following problem concerning the MBJ potential on our manipulated carbon-based compound: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013921.html The problem is now fixed. Here, I would/should first report that the problem was not due to the corrected BRJ subroutine. The BRJ subroutine indeed does its job properly for low charge density in the interstitial region. Although the source of the problem was not directly related to the WIEN2k code, it may be useful to be reported here. The story is as follows: We installed the v10.1 of the WIEN2k code including the new corrected brj.f using l_cprof_p_11.1.072.tgz and its MKL therein, 10.2.5.035 , on two PC's-- PC1 under FC10 with 4 cores and 8 GB and PC2 under FC12 with 2 cores and 2 GB RAM memories. We would run two carbon based cases,case1 and case2 , with low charge density in their interstitial regions. The number of nonequivalent atoms of the case1 is much larger than that of case2. The number of symmetry operations of case1 is much less than that of case2. The PC2 could not handle the heavy case1, but the light case2. The heavy case1 could be handled under more powerful PC1. We performed both of the regular GGA and MBJ calculations for case2 using PC2 successfully-thanks to Peter and Martin. We performed the regular GGA for case1 using PC1 successfully. However, lapw2 problem occurred for the case1 during MBJ calculations. Here, we reported the problem (see the above link), as we thought that it may be due to the MBJ subroutine. We then tried to repeat the successful MBJ calculations of the case2 using PC1. Surprisingly, the MBJ calculations for the successful case2 stopped with similar error under PC1. Therefore, at this step we concluded that the problem may be due to the FC10 of the PC1 compared to the FC12 of the PC2. We then installed FC12 on another new hard disk under PC1 as well, and repeated installation of WIEN2k exactly similar to our last installation. We tested some simple cases under the new hard disk on PC1 with FC12 successfully. We then ran the MBJ for the case1 under new setup of the PC1. We encountered error in lapw1 (simply error in parallel). We also observed the speed of calculations are increased by factor 3-three times slower. We then changed the hard disk. We put the hard disk of PC2 with its FC12 and WIEN2k installed on it on PC1. We turned on the PC1 by the hard disk of PC2. Now PC1 is up under FC12. We ran a simple test. We found segmentation fault error. We then under the new CPU recompiled once more the WIEN2k code on PC1. Then we could run successfully simple cases without further attempts. At this stage we ran our heavy case1 under FC12 on PC1 using the hard disk of PC2. Surprisingly, it works fine and the case is running smoothly with no jump in :DIS or :FER. Some strange problems that we cannot explain it. Why FC10 cannot run the MBJ for our case, but can run the regular GGA for our case and the MBJ for other simple cases? Why a hard disk with FC12 cannot run MBJ for our case, but can run the MBJ for other simple cases? Why changing the hard disk with FC12 can fix the problem? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101029/6f3de284/attachment.htm
[Wien] mbj
Dear Peter, The mbj calculations were well converged for our carbon-based compound with week van der Waals interactions among each clusters in the unit cell. We doped impurity endohedrally into the carbon-based compound. Therefore the symmetry of the system decreased, and the number of non-equivalent atoms increased. However, the interstitial region has not changed substantially. It almost remains the same as before manipulating impurities. For the new structure file the mbj calculation stops with the same error as before even employing the new BRJ subroutine. Could reducing the TOL from 1D-6 to 1D-7 fix the problem? Or should we change the IF condition on iint?
[Wien] mbj of Diamond
Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond Sorry, again. I'm using a new WIEN2k version (not released yet) and the new brj.f is not compatible with the WIENM2k_10.1 version. Simply remove all references to ir (it is used only as guide for printing warnings). Regards Am 25.10.2010 07:09, schrieb Saeid Jalali: Dear Prof. Kroker, I could print the tau, tauw, and iint: print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040ABA9 brj_ 48 brj.f ... Then, I tried to print ir as well: print*,'ir=',ir print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A482 brj_ 36 brj.f The line 36 starts with an if clause: if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif Then, I tried to print the ir before line 36: print*,'ir=',ir if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif The result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A4D7 brj_ 35 brj.f So the error as you nicely expected comes from the ir. In the last brj.f subroutine the ir was not used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). But, in the new brj.f subroutine the ir is used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ,ir) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi
[Wien] mbj of Diamond
After 2.5 hours the lapw0 -grr has finished its work, and now lapw0 is running. Yes, we set the option to 50 in case.in0_grr: TOT 50(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor And to 28 in case.in0 TOT 28(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor If option 50 does not call brj, so your changes should not affect the speed. I will reboot our system to make sure about its free ram and swap memories and try again. I will report back the result at the end of this evening. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 1:12 PM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond lapw0 -grr uses case.in0_grr and this should have option 50 Option 50 does not call subroutine brj Am 25.10.2010 11:30, schrieb Saeid Jalali: Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond Sorry, again. I'm using a new WIEN2k version (not released yet) and the new brj.f is not compatible with the WIENM2k_10.1 version. Simply remove all references to ir (it is used only as guide for printing warnings). Regards Am 25.10.2010 07:09, schrieb Saeid Jalali: Dear Prof. Kroker, I could print the tau, tauw, and iint: print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040ABA9 brj_ 48 brj.f ... Then, I tried to print ir as well: print*,'ir=',ir print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0
[Wien] *** SPAM *** [5.7] Re: mbj of Diamond
Dear Peter and Martin, Now, this is the end of evening here, and the time is apt to report to the mailinglist. The speed problem was due to our system. I am very pleased, to inform you that the mbj is now running at third cycles (up to now) on our case with no problem. We are eagerly waiting for the final result. Here, we are deeply thankful to Peter Blaha and Martin Kroker for their valuable contributions to this work. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Saeid Jalali Sent: Monday, October 25, 2010 1:42 PM To: 'A Mailing list for WIEN2k users' Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond After 2.5 hours the lapw0 -grr has finished its work, and now lapw0 is running. Yes, we set the option to 50 in case.in0_grr: TOT 50(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor And to 28 in case.in0 TOT 28(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor If option 50 does not call brj, so your changes should not affect the speed. I will reboot our system to make sure about its free ram and swap memories and try again. I will report back the result at the end of this evening. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 1:12 PM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond lapw0 -grr uses case.in0_grr and this should have option 50 Option 50 does not call subroutine brj Am 25.10.2010 11:30, schrieb Saeid Jalali: Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien
[Wien] mbj of Diamond
Dear Prof. Kroeker, Right before the line 47, where the problem is there, I let be printed values of the rho,tauw,grho,g2rho, tau_falsch quantities, as follows: print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_falsch if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_falsch iint=iint+1 endif The results by running lapw0 are: int:rho,tauw,grho,g2rho 64.238976254813115534.6272805818 1997.92747916902 -24058013.7208862 tauwrong= -4250585.42208186 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 0040ABB9 brj_ 47 brj.f ... As you would see they are nonzero numbers. You may know that the modified Becke-Johnson potential (mbj) potential, PRL 102, 226401 (2009), is a LDA+U-like or Hybrid-like method for treating with sp-compounds. LDA+U and hybride methods are proper for f- and d-compound. Within mbj method we can improve the band gap too. You would see section 4.5.8 of the v10.1 usersguide. Thank you for your friendly and valuable co-operation. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Sunday, October 24, 2010 3:33 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] mbj of Diamond But, again the segmentation fault error occurred at line 47 It was only a wild guess. So either one of the other values that are printed on line 46(47) contains an unprintable value, or - more likely - an array overflowed somewhere else and the memory management breaks down on the next attempt to allocate memory (internally in the print). Further analysis will probably require use of a debugger. (You could try commenting out the print call inside the if block, or separating it into individual print calls for the five variables, just to see if you get any further). -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] mbj on Diamond
Dear Peter, I compared it with the last original brj.f. You really made substantial changes. Thank you very much for your nice effort on brj.f. I recompiled the lapw0 replacing your new brj.f file. But, unfortunately, our case stopped at the first cycle with the following error in lapw0: ?LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image? PC??? Routine??? Line??? Source lapw0? 0040AA28? brj_?? 46? brj.f lapw0? 00479D44? vxclm2_?? 534? vxclm2.f lapw0? 00482859? xcpot1_?? 365? xcpot1.f lapw0? 0043A7D7? MAIN__?? 1696? lapw0.F lapw0? 00403D3C? Unknown?? Unknown? Unknown libc.so.6? 00350A41EB1D? Unknown?? Unknown? Unknown lapw0? 00403C39? Unknown?? Unknown? Unknown We run the mbj for diamond, and found that the problem is not only for our case. It stops with the above error for any other simple cases. I again copied the old brj.f and recompile the lapw0, and fond that it works properly for the diamond and the other simple cases, but for our case. Any comments will be highly appreciated. Thank you again, With my best regards for you, Saeid. --- On Fri, 10/15/10, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: From: Peter Blaha pbl...@theochem.tuwien.ac.at Subject: Re: [Wien] mbj on Diamond To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Date: Friday, October 15, 2010, 4:38 AM Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here),? second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9781366 C3.scf::NTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 2.4250427 C2.scf::CTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9781254 C3.scf::CTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9470631 C2.scf::DIS? :? CHARGE DISTANCE? ? ???( 0.355 for atom???33 spin 1)? ? ? 0.136 C3.scf::DIS? :? CHARGE DISTANCE? ? ???( 1.8978668 for atom???25 spin 1)? ? ? 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE? ? 366.0???365.98257? ???1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE? ? 366.0???365.98171? ???1.5 C2.scf::FER? : F E R M I - ENERGY(TETRAH.M.)=???0.21390 C3.scf::FER? : F E R M I - ENERGY(TETRAH.M.)=? -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. -- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671? ? ? ? ? ???FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.at? ? WWW: http://info.tuwien.ac.at/theochem/ -- -Inline Attachment Follows- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL:
[Wien] mbj on Diamond
Hello Martin, I added the line tau_falsch = 0D0 right before the IF (RHO .GT. 1D-18) THEN in the brj.f subroutine as you would see below: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ,ir) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). USE xcparam IMPLICIT REAL*8(A-H,O-Z) SAVE X,iint,isphere DATA X/0D0/,iint/0/,isphere/0/ PI = 4D0*DATAN(1D0) tau_falsch = 0D0 IF (RHO .GT. 1D-18) THEN ... But, again the segmentation fault error occurred at line 47: LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 0040AA2D brj_ 47 brj.f lapw0 00479D34 vxclm2_ 534 vxclm2.f lapw0 00482849 xcpot1_ 365 xcpot1.f lapw0 0043A7C7 MAIN__ 1696 lapw0.F lapw0 00403D3C Unknown Unknown Unknown libc.so.6 00350A41EB1D Unknown Unknown Unknown lapw0 00403C39 Unknown Unknown Unknown The line 47 is exactly the last line, i.e. 46, as I inserted one additional line: if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then Thank you for your very friendly help, like your last valuable contribution on the last 32 and 64 bit problem. Kind regards, Saeid. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Saturday, October 23, 2010 9:39 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] mbj on Diamond I am probably not qualified to comment on what brj.f does, but I do notice that the segmentation fault in line 46 occurs on a line that tries to print tau_falsch when no value has ever been assigned to this variable. You could try inserting the line tau_falsch = 0D0 before the IF RHO.GT.1.D-18 block. -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] mbj on Diamond
We calculated the band gap of diamond (as an example) within the mbj potential functional in two different procedures: In the first procedure, we exactly followed the steps discussed in the usersguide and found significant improvement on the band gap: In the second procedure, we before saving the regular GGA calculation executed the dstart program, i.e., x dstart, and then followed exactly the reaming steps as discussed in the usersguide. The band gap within the second procedure is exactly similar to the first procedure. This shows that (?) the regular calculation is just to produce necessary files and its converged results may not be very important (?) for the remaining mbj calculations. In this case, one may (?} only run the regular GGA calculation for one cycle, which can save efficiently the time for heavy cases. We ran the dstart to reproduce the starting charge density and as a result destroy the converged case.clmsum. In this case, we hope to avoid the jump in :DIS due to the new mbj potential indxc=28 compared to the :DIS in two last cycles of the regular calculations as discussed in my last unregarded contribution (maybe due to not enough information) to the mailing list. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101009/f3247c41/attachment.htm
[Wien] mbj
Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw -NI -i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw -NI -i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. In order to check whether such a jump occurs for other systems, we perform as an example another mbj calculations for the fcc-Fe crystal. The Fe results, which clearly show that there is not such a jump problem in Fe are given below: Fe1.scf :NTO001: TOTAL CHARGE IN SPHERE 1 = 23.4594564 Fe2.scf :NTO001: TOTAL CHARGE IN SPHERE 1 = 23.4235635 Fe1.scf :CTO001: TOTAL CHARGE IN SPHERE 1 = 23.4594584 Fe2.scf :CTO001: TOTAL CHARGE IN SPHERE 1 = 23.4585610 Fe1.scf :DIS : CHARGE DISTANCE ( 0.025 for atom1 spin 1) 0.025 Fe2.scf :DIS : CHARGE DISTANCE ( 0.0397309 for atom1 spin 1) 0.0397309 Fe1.scf :NEC01: NUCLEAR AND ELECTRONIC CHARGE 26.025.99451 1.00021 Fe2.scf :NEC01: NUCLEAR AND ELECTRONIC CHARGE 26.025.99459 1.00021 In order to check whether the problem comes from carbon atoms we performed the calculation for the diamond and found that the problem cannot attributed to the carbon atom, as the mbj diamond (just for example) is well converged. We then change the mixing method to PRAT and change and reduce the mixing parameter in case.inm to 0.01. But the problem severely exists. Since our calculations are very heavy due to our limited computational facility, we cannot perform many tests. So, your comments are very valuable for us and will be deeply appreciated. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101008/a6454144/attachment-0001.htm
[Wien] mbj
Two corrections in the following contribution: Fe1.scf should be changed to Fe2.scf Fe2.scf should be changed to Fe3.scf Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: wien-boun...@zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Saeid Jalali Sent: Friday, October 08, 2010 12:12 PM To: 'A Mailing list for WIEN2k users' Subject: *** SPAM *** [5.7] [Wien] mbj Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw -NI -i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw -NI -i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. In order to check whether such a jump occurs for other systems, we perform as an example another mbj calculations for the fcc-Fe crystal. The Fe results, which clearly show that there is not such a jump problem in Fe are given below: Fe1.scf :NTO001: TOTAL CHARGE IN SPHERE 1 = 23.4594564 Fe2.scf :NTO001: TOTAL CHARGE IN SPHERE 1 = 23.4235635 Fe1.scf :CTO001: TOTAL CHARGE IN SPHERE 1 = 23.4594584 Fe2.scf :CTO001: TOTAL CHARGE IN SPHERE 1 = 23.4585610 Fe1.scf :DIS : CHARGE DISTANCE ( 0.025 for atom1 spin 1) 0.025 Fe2.scf :DIS : CHARGE DISTANCE ( 0.0397309 for atom1 spin 1) 0.0397309 Fe1.scf :NEC01: NUCLEAR AND ELECTRONIC CHARGE 26.025.99451 1.00021 Fe2.scf :NEC01: NUCLEAR AND ELECTRONIC CHARGE 26.025.99459 1.00021 In order to check whether the problem comes from carbon atoms we performed the calculation for the diamond and found that the problem cannot attributed to the carbon atom, as the mbj diamond (just for example) is well converged. We then change the mixing method to PRAT and change and reduce the mixing parameter in case.inm to 0.01. But the problem severely exists. Since our calculations are very heavy due to our limited computational facility, we cannot perform many tests. So, your comments are very valuable for us and will be deeply appreciated. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir
[Wien] libstdc++.so.5
Dear WIEN2k members, I am trying to compile the latest version of the code using FC10 (Intel ifort 11.1 compiler + mkl) on an isolated 64 bit intel 4 cores system and an isolated 32 bit intel 2 cores system. For the 32 bit system I do not have any problem even under FC11, FC12, and FC13, and the code works fine. But for the former 64 bit system there is the following error in compile.msg files: /opt/intel/Compiler/11.1/072/bin/intel64/fortcom: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory This is in the case that I have already installed the libstdc++.so.5 library, as it is also necessary for installing the intel ifort 11.1 compiler. Although in FC10 the libstdc++.so.6 is installed, the libstdc++.so.5 is also needed for installing intel ifort 11.1 compiler. Therefore, I installed the later library and all of its components using yum as yum install libstdc++.so.5. After this the l_cprof_p_11.1.072 is completely and successfully installed. I added the following two lines in .bashrc: source /opt/intel/Compiler/11.1/072/mkl/tools/environment/mklvars64.sh source /opt/intel/Compiler/11.1/072/bin/intel64/ifortvars_intel64.sh Then siteconfig_lapw recognized ifort and mkl. The libstdc++.so.5 is installed in /usr/lib in the 32 bit system, where the libstdc++.so.6 was installed. The libstdc++.so.5 is installed in /usr/lib in the 64 bit system, while the libstdc++.so.6 was installed in another directory of /usr/lib64. In the directory of /usr/lib on the 32 bit system there are: #find -name libsdtc* ./gcc/x86_64-redhat-linux/4.4.4/libstdc++.so ./gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so ./gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.a ./gcc/x86_64-redhat-linux/4.4.4/libstdc++.a ./libstdc++.so.5.0.7 ./libstdc++.so.5 In the directory of /usr/lib on the 64 bit system there are: #find -name libsdtc* ./gcc/x86_64-redhat-linux/4.3.2/libstdc++.a ./gcc/x86_64-redhat-linux/4.3.2/32/libstdc++.a ./gcc/x86_64-redhat-linux/4.3.2/32/libstdc++.so ./gcc/x86_64-redhat-linux/4.3.2/libstdc++.so ./libstdc++.so.5.0.7 ./libstdc++.so.5 In the directory of /usr/lib64 on the 64 bit system there are: #find -name libsdtc* ./libstdc++.so.6.0.10 ./libstdc++.so.6 For the 64 bit system, I added the /usr/lib path to the $PATH, but still the problem exists. Any reply is highly appreciated. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage :http://sci.ui.ac.ir/~sjalali www:http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Laurence Marks Sent: Sunday, September 26, 2010 5:41 PM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] Slab convergence -- continuation An additional comment/question -- did you use the default spin setting in instgen_lapw? I wonder if you did, and that in the converged density the Au is mainly non-polarized except slightly at the surface. However, you started it with all the Au polarized and it will take many iterations for the spin to come down to close to the correct value, and only then will it converge. If I am right, you can look at this in case.scfm (or case.scf) and, next time, edit your case.inst by hand or use the option that allows you to specify for each atom. Starting closer to the right spin coupled with using a centro-symmetric cell will probably solve your problems. On Sat, Sep 25, 2010 at 5:33 PM, Laurence Marks L-marks at northwestern.edu wrote: There is nothing wrong, it is converging slowly and my guess is that it will need 60-80 iterations as you currently have it modelled. If you have only run it for 20 iterations, do another 20 and use the -NI option so it keeps going. DO NOT RESTART from dstart. N.B., the forces are not meaningful unless you have FOR instead of TOT and the densities are much better converged than this. On Sat, Sep 25, 2010 at 5:14 PM, Lukasz Plucinski pluto at physics.ucdavis.edu wrote: ?Dear Laurence, Prof. Blaha, 19 iterations with settings suggested by Prof. Blaha have passed (still with complex version of the program), but I guess there are no signs of convergence. I will keep working on this, and I am sure it will work at the end, especially that I made big progress already :) Next step would be to run smaller slab, like Fe1Au10, and try the non-complex version. In any case I decided to paste the output of the grep file you have proposed - maybe you will immediately see some obvious problem (Fe is atom 21 and it connects to Au atom 1). At the end
[Wien] *** SPAM *** [5.7] libstdc++.so.5
Dear Prof. Kroeker, Thank you for your reply and kind help. Try running ldconfig to update the loader cache. I did run ldconfig, but the problem still exists. If that does not help, run ldd on the fortcom program to see which libraries it is looking for. I did it as follows: [root at cm6 v10.1]# ldd /opt/intel/Compiler/11.1/072/bin/intel64/fortcom linux-vdso.so.1 = (0x7fff68bfe000) libm.so.6 = /lib64/libm.so.6 (0x0034c980) libstdc++.so.5 = not found libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x0034d040) libc.so.6 = /lib64/libc.so.6 (0x0034c940) libdl.so.2 = /lib64/libdl.so.2 (0x0034c9c0) /lib64/ld-linux-x86-64.so.2 (0x0034c900) But the problem is not fixed. Lastly, adding a library directory to $PATH will not help, you want $LD_LIBRARY_PATH for that. I exported the /usr/lib and /usr/lib64 to the $LD_LIBRARY_PATH, but the problem severely is there. Is it possible to be installed 32 bit version of the libstdc++.so.5 by the yum command on a 64 bit system due to an unintelligent repository file? Thank you again. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage :http://sci.ui.ac.ir/~sjalali www:http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Tuesday, September 28, 2010 12:32 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] libstdc++.so.5 Try running ldconfig to update the loader cache. If that does not help, run ldd on the fortcom program to see which libraries it is looking for. Lastly, adding a library directory to $PATH will not help, you want $LD_LIBRARY_PATH for that. Hope this helps, Martin -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] libstdc++.so.5
But it has been already installed: [root at cm6 v10.1]# yum install libstdc++.so.5 Loaded plugins: refresh-packagekit fedora | 2.8 kB 00:00 updates | 3.4 kB 00:00 Setting up Install Process Parsing package install arguments Package compat-libstdc++-33-3.2.3-64.i386 already installed and latest version Nothing to do Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage: http://sci.ui.ac.ir/~sjalali http://sci.ui.ac.ir/~sjalali www: http://www.ui.ac.ir http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: wien-boun...@zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Chandra Bhanu Basak Sent: Tuesday, September 28, 2010 3:08 PM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [1.7] Re: [Wien] libstdc++.so.5 Dear Jalali, Download compat libstdc++ 33 library for FC and install... this will provide 32bit extensions library (libstdc++.so.5) required for 64bit C++ compilers. C. B. Basak -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100928/2112d747/attachment.htm
[Wien] libstdc++.so.5
Dear Prof. Kroeker, Thank you very much. Your guess is perfect. The link exactly contains and discusses my problem. Now the problem is nicely fixed. Thank you again. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage :http://sci.ui.ac.ir/~sjalali www:http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Tuesday, September 28, 2010 9:32 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] libstdc++.so.5 It appears to me now that you somehow installed only the 32bit version of compat-libstdc++ , while the intel compiler is looking for the 64bit version of the library. Try reinstalling compat-libstdc++ without specifying the .i386 extension, or yum install compat-libstdc++-33-3.2.3-64.x86_64 to force the 64bit version explicitly. (cf. http://software.intel.com/en-us/forums/showthread.php?t=70518 , this seems to describe your problem exactly) -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] in1new or in1ef
You see the comment on in1ef given in http://www.wien2k.at/reg_user/updates/ . According to my experience too, in agreement with the above update comment, the new in1ef switch is more efficient than the older in1new one to avoid presence of ghostband. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage:http://sci.ui.ac.ir/~sjalali www:http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: wien-boun...@zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Ghosh SUDDHASATTWA Sent: Thursday, May 27, 2010 9:17 AM To: 'A Mailing list for WIEN2k users' Subject: *** SPAM *** [2.7] [Wien] in1new or in1ef Dear Wien2k users, Can anybody tell me which one is more efficient in finding out the best linearization energy; in1new or in1ef I have checked the UG and it says about in1new the switch in1new N preserves for N iterations the default ... After the N iterations, ...and a new case.in1 is generated Sorry for asking a freshman question Given any initialization, if we do in1new 4 -in1new 6 -in1new 8 Which one should we use to get the best set of linearization energies. Or -in1ef switch is better? Thank You Suddhasattwa Ghosh -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100528/aa213f95/attachment.htm
[Wien] google search
Dear Peter, I had sent an e-mail to the mailinglist and informed that the google search of the code was not possible. I checked and found that this is not the case for many other people in other countries. Therefore, I used UseJump browser which is better than u95.exe and allows to do search within filtered sites. It works, but not very well, as it is very slow. Many useful information can be found in the list, and people here cannot go through them quickly. Maybe this information is useful for those people who are restricted due to the badly done filtering authority. PS: After performing the keywords search in the mailinglist, all the founded links can be opened in the regular browsers like moizila, firefox, explorer, htmlview and so on. Although many users are not aware about this problem, this report may be helpful for a subset users. I hope you can suggest better solution. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage: http://sci.ui.ac.ir/~sjalali http://sci.ui.ac.ir/~sjalali www: http://www.ui.ac.ir http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100112/a0d494e4/attachment.htm
[Wien] google search
I noticed that the google search of the mailinglist does not work. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir Homepage :http://sci.ui.ac.ir/~sjalali www:http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
