Re: [Wien] A few (more) elementary -so questions (with onsite -eece)
Me a culpa, I should have checked the mailing list first for the answers. That said, this issue has come up enough times in the past that I think the UG should be tweaked so it is clearer. Let me try my interpretation, so I can be shot down if needed. Within Wien2k magnetic effects can be approximately included in a number of ways. Some such as the spin-orbit coupling assume a direction for the spin vector (for all electrons actively considered), others such as Bext in orb specify a direction for an applied magnetic field (in Tesla) and use the same direction for the spin vector. (The two spin states are then either parallel or anti parallel to the specified direction.) When a direction is specified in case.inso or case.inorb this fixes the spin vector and (if used) the external magnetic field direction. Via the output files from lapwdm (case.scfdmXX) one can monitor how the angular momentum changes [1]. By using different directions for the spin vector (and field) one can probe how the energy changes and/orbital occupancies with assumed directions for the spin/external magnetic field. To escape the assumption that the spin vectors all have one direction the Wienncm code has to be used. [1] My addendum. Changes in the occupancies can be a soft electronic mode, i.e. very small changes in the energy for quite large changes in the density. The older mixing algorithms (MSEC1 or MSEC3) are not so good for soft modes and can stagnate. MSR1 is better and the next release (7.0) is much better. With onsite -eece /or -orb it may help to push the mixer by either forcing a larger step (echo .2 .msec or echo .1 .pratt) or stopping, doing a force on the orbital potential (x orb -up; x orb -dn) then restarting with -NI. It is probably wise to check how the orbital momentum is converging (grep :ORB0 *.scf, perhaps other) and make sure that the mixing is not starving (grep GREED: *.scf and check the values are not small, e.g. 0.035). ___ Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 4, 2015 6:22 PM, Laurence Marks l-ma...@northwestern.edu wrote: Typo: although I remember don't symmetry operations being split into these two classes everywhere in the code On Mon, May 4, 2015 at 6:04 PM, Laurence Marks l-ma...@northwestern.edu wrote: I am a newbie at -so, so a few simple questions. a) What is the meaning of the orbital moment in case.scfdm* ? Is that the average direction projected to the global axis system? b) What is the physical significance of the orbital moment being parallel (or not quite parallel) to the direction used in case.inso? c) I understand that the results for different directions of B in case.inso reflect the magnetic anisotropy, but what are the units of field (if any)? d) What else is worth looking at? The partial orbital moment (:POM) seems relevant, but what exactly is it? e) I am blindly trusting that initso knows what it is doing, and have left the B symmetry operations in case.struct (although I remember symmetry operations being split into these two classes everywhere in the code). This seems to conflict with Pavel's notes, although those may be too old. Thanks. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ 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] Need your help please
In a spin-polarized case, you have to calculate both spins (up and dn), before you can run x lapw2 -up -fermi Probably this cannot be done directly in xcrysden, but you need to execute x lapw1 -dn in a terminal window. On 05/05/2015 01:40 PM, Sikander Azam wrote: Resp. All Calculating the Fermi surface, I am facing the following problem, please help me. Error in lapw2 'FERMI -# of k-points in up and down not equal: 'FERMI -k1, 224 225 check INPUTS OF LAPW1 With best regards sikander ___ 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 -- 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php -- ___ 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] Need your help please
Resp. P.BlahaThanks sir for your kind reply.with best regardssikander On Tuesday, May 5, 2015 5:33 AM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: In a spin-polarized case, you have to calculate both spins (up and dn), before you can run x lapw2 -up -fermi Probably this cannot be done directly in xcrysden, but you need to execute x lapw1 -dn in a terminal window. On 05/05/2015 01:40 PM, Sikander Azam wrote: Resp. All Calculating the Fermi surface, I am facing the following problem, please help me. Error in lapw2 'FERMI -# of k-points in up and down not equal: 'FERMI -k1, 224 225 check INPUTS OF LAPW1 With best regards sikander ___ 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 -- 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 WIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php -- ___ 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] Error in mpi+k point parallelization across multiple nodes
Thanks for all the information and suggestions. I have tried to change -lmkl_blacs_intelmpi_lp64 to -lmkl_blacs_lp64 and recompile. However, I got the following error message in the screen output LAPW0 END [cli_14]: [cli_15]: [cli_6]: aborting job: Fatal error in PMPI_Comm_size: Invalid communicator, error stack: PMPI_Comm_size(110): MPI_Comm_size(comm=0x5b, size=0x7f190c) failed PMPI_Comm_size(69).: Invalid communicator aborting job: Fatal error in PMPI_Comm_size: Invalid communicator, error stack: PMPI_Comm_size(110): MPI_Comm_size(comm=0x5b, size=0x7f190c) failed PMPI_Comm_size(69).: Invalid communicator ... [z0-5:mpispawn_0][readline] Unexpected End-Of-File on file descriptor 20. MPI process died? [z0-5:mpispawn_0][mtpmi_processops] Error while reading PMI socket. MPI process died? [z0-5:mpispawn_0][child_handler] MPI process (rank: 14, pid: 11260) exited with status 1 [z0-5:mpispawn_0][child_handler] MPI process (rank: 3, pid: 11249) exited with status 1 [z0-5:mpispawn_0][child_handler] MPI process (rank: 6, pid: 11252) exited with status 1 . Previously I compiled the program with -lmkl_blacs_intelmpi_lp64 and the mpi parallelization on a single node seems to be working. I notice that during the run, the *.error files have finite sizes, but I re-examine them after the job finished and there were no errors written inside (and the files have 0kb now). Does this indicates that the mpi is not running probably at all even on a single node? But I have checked the output result and it's in agreement with the non-mpi results..(for some simple cases) I also tried changing the mpirun to mpiexec as suggested by Prof. Marks by setting: setenv WIEN_MPIRUN /usr/local/mvapich2-icc/bin/mpiexec -np _NP_ -f _HOSTS_ _EXEC_ in the parallel_option. In this case, the program does not run and also does not terminate (qstat on cluster just gives 00:00:00 for the time with a running status).. Regards, Fermin ___ 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] a minor typos in defining nband
Actually the algorithm is (lstart and init_lapw): nband=(ne*2+5)/ispin; with ispin=2 in non-spin-polarized cases and 1 in spin-polarized. Am 25.04.2015 um 21:52 schrieb Saeid Jalali: 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 mailto:sjal...@sci.ui.ac.ir :sjal...@phys.ui.ac.ir mailto:sjal...@phys.ui.ac.ir :saeid.jalali.asadab...@gmail.com mailto:saeid.jalali.asadab...@gmail.com :s_jalal...@yahoo.com mailto:s_jalal...@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@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
Re: [Wien] A few (more) elementary -so questions (with onsite -eece)
I definitely am not an expert for -so, therefore I will not shoot down anything, only a comment: From my point of view from magnetism I would ask for some caution with identifying the direction given in .inorb and .inso with 'the spin direction'. As Gerhard pointed out earlier in this thread, it's all about symmetry: The specified direction only sets up the symmetry of the case to be compatibel with whatever has a rotational invariance with that (quantization) axis - be that a spin, or orbital moment, magnetization, a magnetic field, ... The symmetry of the basis has to allow for a magnetization otherwise it won't appear when you calculate expectation values. Personally I find Pavel's 'lecture on spin-orbit.ps' here in the Wien documentation files (I hope it's still there) very illuminating. --- Dr. Martin Pieper Karl-Franzens University Institute of Physics Universitätsplatz 5 A-8010 Graz Austria Tel.: +43-(0)316-380-8564 Am 05.05.2015 14:51, schrieb Laurence Marks: Me a culpa, I should have checked the mailing list first for the answers. That said, this issue has come up enough times in the past that I think the UG should be tweaked so it is clearer. Let me try my interpretation, so I can be shot down if needed. Within Wien2k magnetic effects can be approximately included in a number of ways. Some such as the spin-orbit coupling assume a direction for the spin vector (for all electrons actively considered), others such as Bext in orb specify a direction for an applied magnetic field (in Tesla) and use the same direction for the spin vector. (The two spin states are then either parallel or anti parallel to the specified direction.) When a direction is specified in case.inso or case.inorb this fixes the spin vector and (if used) the external magnetic field direction. Via the output files from lapwdm (case.scfdmXX) one can monitor how the angular momentum changes [1]. By using different directions for the spin vector (and field) one can probe how the energy changes and/orbital occupancies with assumed directions for the spin/external magnetic field. To escape the assumption that the spin vectors all have one direction the Wienncm code has to be used. [1] My addendum. Changes in the occupancies can be a soft electronic mode, i.e. very small changes in the energy for quite large changes in the density. The older mixing algorithms (MSEC1 or MSEC3) are not so good for soft modes and can stagnate. MSR1 is better and the next release (7.0) is much better. With onsite -eece /or -orb it may help to push the mixer by either forcing a larger step (echo .2 .msec or echo .1 .pratt) or stopping, doing a force on the orbital potential (x orb -up; x orb -dn) then restarting with -NI. It is probably wise to check how the orbital momentum is converging (grep :ORB0 *.scf, perhaps other) and make sure that the mixing is not starving (grep GREED: *.scf and check the values are not small, e.g. 0.035). ___ Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu [1] MURI4D.numis.northwestern.edu [2] Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 4, 2015 6:22 PM, Laurence Marks l-ma...@northwestern.edu wrote: Typo: although I remember don't symmetry operations being split into these two classes everywhere in the code On Mon, May 4, 2015 at 6:04 PM, Laurence Marks l-ma...@northwestern.edu wrote: I am a newbie at -so, so a few simple questions. a) What is the meaning of the orbital moment in case.scfdm* ? Is that the average direction projected to the global axis system? b) What is the physical significance of the orbital moment being parallel (or not quite parallel) to the direction used in case.inso? c) I understand that the results for different directions of B in case.inso reflect the magnetic anisotropy, but what are the units of field (if any)? d) What else is worth looking at? The partial orbital moment (:POM) seems relevant, but what exactly is it? e) I am blindly trusting that initso knows what it is doing, and have left the B symmetry operations in case.struct (although I remember symmetry operations being split into these two classes everywhere in the code). This seems to conflict with Pavel's notes, although those may be too old. Thanks. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu [1] Corrosion in 4D: MURI4D.numis.northwestern.edu [2] Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu [1] Corrosion in 4D: MURI4D.numis.northwestern.edu [2] Co-Editor, Acta Cryst A Research is to see what everybody
Re: [Wien] A few (more) elementary -so questions (with onsite -eece)
I would be interested in clarification from others, but from what I can see in the code it appears that this is the spin direction that is used, not just the direction of breaking the symmetry. I may be wrong. On Tue, May 5, 2015 at 11:47 AM, pieper pie...@ifp.tuwien.ac.at wrote: I definitely am not an expert for -so, therefore I will not shoot down anything, only a comment: From my point of view from magnetism I would ask for some caution with identifying the direction given in .inorb and .inso with 'the spin direction'. As Gerhard pointed out earlier in this thread, it's all about symmetry: The specified direction only sets up the symmetry of the case to be compatibel with whatever has a rotational invariance with that (quantization) axis - be that a spin, or orbital moment, magnetization, a magnetic field, ... The symmetry of the basis has to allow for a magnetization otherwise it won't appear when you calculate expectation values. Personally I find Pavel's 'lecture on spin-orbit.ps' here in the Wien documentation files (I hope it's still there) very illuminating. --- Dr. Martin Pieper Karl-Franzens University Institute of Physics Universitätsplatz 5 A-8010 Graz Austria Tel.: +43-(0)316-380-8564 Am 05.05.2015 14:51, schrieb Laurence Marks: Me a culpa, I should have checked the mailing list first for the answers. That said, this issue has come up enough times in the past that I think the UG should be tweaked so it is clearer. Let me try my interpretation, so I can be shot down if needed. Within Wien2k magnetic effects can be approximately included in a number of ways. Some such as the spin-orbit coupling assume a direction for the spin vector (for all electrons actively considered), others such as Bext in orb specify a direction for an applied magnetic field (in Tesla) and use the same direction for the spin vector. (The two spin states are then either parallel or anti parallel to the specified direction.) When a direction is specified in case.inso or case.inorb this fixes the spin vector and (if used) the external magnetic field direction. Via the output files from lapwdm (case.scfdmXX) one can monitor how the angular momentum changes [1]. By using different directions for the spin vector (and field) one can probe how the energy changes and/orbital occupancies with assumed directions for the spin/external magnetic field. To escape the assumption that the spin vectors all have one direction the Wienncm code has to be used. [1] My addendum. Changes in the occupancies can be a soft electronic mode, i.e. very small changes in the energy for quite large changes in the density. The older mixing algorithms (MSEC1 or MSEC3) are not so good for soft modes and can stagnate. MSR1 is better and the next release (7.0) is much better. With onsite -eece /or -orb it may help to push the mixer by either forcing a larger step (echo .2 .msec or echo .1 .pratt) or stopping, doing a force on the orbital potential (x orb -up; x orb -dn) then restarting with -NI. It is probably wise to check how the orbital momentum is converging (grep :ORB0 *.scf, perhaps other) and make sure that the mixing is not starving (grep GREED: *.scf and check the values are not small, e.g. 0.035). ___ Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu [1] MURI4D.numis.northwestern.edu [2] Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi On May 4, 2015 6:22 PM, Laurence Marks l-ma...@northwestern.edu wrote: Typo: although I remember don't symmetry operations being split into these two classes everywhere in the code On Mon, May 4, 2015 at 6:04 PM, Laurence Marks l-ma...@northwestern.edu wrote: I am a newbie at -so, so a few simple questions. a) What is the meaning of the orbital moment in case.scfdm* ? Is that the average direction projected to the global axis system? b) What is the physical significance of the orbital moment being parallel (or not quite parallel) to the direction used in case.inso? c) I understand that the results for different directions of B in case.inso reflect the magnetic anisotropy, but what are the units of field (if any)? d) What else is worth looking at? The partial orbital moment (:POM) seems relevant, but what exactly is it? e) I am blindly trusting that initso knows what it is doing, and have left the B symmetry operations in case.struct (although I remember symmetry operations being split into these two classes everywhere in the code). This seems to conflict with Pavel's notes, although those may be too old. Thanks. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University
Re: [Wien] Fraction of electron doping-Charged cells
Yes, you can of course put fractions of electrons. On 05/05/2015 12:30 PM, Mohammed Abujafar wrote: Dear WIEN2k developers and users, Hi! I know that the procedure in WIEN2k-FAQ: Charged cells is to introduce a background charge so that the system is neutral again.As NE in case.in2 is increased by delta , this delta should be used in case.inm. My concern is about delta .Can I take delta to be a fraction number?I am concerning about doping a fraction of electron in the supercell by adding 0.1,0.2,0.3 etc or removing -0.1,-0.2,-0.3etc instead of adding or removing an integer number of electrons.I need to make sure that the procedure is also valid for doping a fraction of electrons in the supercell or not.Thanks a lot in advance. With best regards Mohammed ___ 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 -- 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php -- ___ 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] Need your help please
Resp. AllCalculating the Fermi surface, I am facing the following problem, please help me. Error in lapw2'FERMI -# of k-points in up and down not equal:'FERMI -k1, 224 225 check INPUTS OF LAPW1 With best regardssikander ___ 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] trouble with generating rxesw file
First, I suggest that you upgrade to WIEN2k 14.2, because some updates have been made to SRC_tetra [ http://www.wien2k.at/reg_user/updates/ , http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg11178.html (patch to only WIEN2k 14.1?)]. Second, this might be due to a bug in SRC_tetra/ados.f. I think the problem might be because dosold1(i,l) is used the first time without being initialized (line 85 of ados.f in WIEN2k 14.2). However, dosold1(i,l) is not a problem after that (as it is set in line 86). There seems to be a history behind the problem as described in the old post at: http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg03526.html It seems that dosold1=0.0 was used outside the if(rxes ) and if(rxesw ) statements in the past. This, however, caused a problem for the non-rxesw and non-rxes paths, such that dosold1=0.0 was moved inside the if(rxes ) statement. However, it seems that the following line should have also been put after the allocate statement (on line 37 of ados.f in WIEN2k 14.2) in the if(rxesw ) statement: dosold1=0.0 On 5/4/2015 6:04 AM, Tolhurst, Thomas wrote: Hello, This is an elaboration on an unresolved problem with I am having with rxes calculations. I have asked about this a little bit in a previous post, but the problem has persisted. Any help that can be provided will be greatly appreciated. I am running wien2k version 13.1. I am trying to obtain k-selective rxes spectra through the series of commands: x txspec (this is being done in place of x initxspec) x tetra -rxesw 0.76 0.83 x tetra -rxes x txspec x lorentz My case.inxs looks like this: Title: Atom 1 L3 absorption spectrum 6 (atom) 1 (n core) 0 (l core) 0,0.5,0.5 (split, Int1, Int2) -40,0.02,20 (EMIN,DE,EMAX) EMIS (type of spectrum) 1.00(S) 0.001(gamma0) 1.50(W only for EMIS) AUTO (AUTO or MANually select Energy ranges for broadening) -16.71939 -34.05984 -34.11985 My case.int looks like this: Autocreate Title: Atom 1 L3 absorption spectrum -2.4910127 0.0014700 1.9188713 0.000 2 63 l+1 01 tot I am using the mBJ potential and after the scf calculation, I end up with Ef = 0.4489051779 and Eg = 4.127 eV. I am using an un-shifted k-mesh. Following that I run lapw2 -qtl -p. I am trying to get rxes spectra by considering k-points only around the edge of the conduction band. For example using E1 = 0.76 and E2 = 0.83. I run into problems with the execution of tetra -rxesw E1 E2. Since this step fails, the rest of the attempt to calculate the spectra fails. After running tetra -rxesw E1 E2 the first entry in the weighting file case.rxes will read NAN or be on the order of magnitude of 10^20, whereas all other entries seem to be on the order of 10^1 or less. For example, I tend to find something like this: $ cat case.rxes Energy 0.763 0.829 atom,column 6 3 0 0 1 1 NaN NaN 1 2 0.994939263910E-02 0.844427585602E+01 1 3 0.835545267910E-02 0.724503898621E+01 1 4 0.870894733816E-02 0.771706342697E+01 1 5 0.780950719491E-02 0.698161888123E+01 1 6 0.949013140053E-02 0.821397781372E+01 ... If I then run tetra -rxes my case.dos1eV file tends to have several (or even all) entries reading NAN in the second and third columns, or -2.71202** NaN in several rows. I have tried varying the parameters in case.int and there seems to be no effect. I have also tried varying E1 and E2 quite widely. It seem that for very large separations of E1 and E2, for example when running: x tetra -rxesw 0.5 1.5 I get a sensible case.rxes file, the beginning of which is: Energy 0.500 1.500 atom,column 6 3 0 0 1 1 0.100038540363E+01 0.302590393066E+03 1 2 0.964178562164E+00 0.299021881104E+03 1 3 0.941299080849E+00 0.295303039551E+03 1 4 0.928038597107E+00 0.286147766113E+03 1 5 0.940963864326E+00 0.297471984863E+03 1 6 0.950316071510E+00 0.298051269531E+03 1 7 0.450937390327E+00 0.141126739502E+03 1 8 0.470923691988E+00 0.147648559570E+03 1 9 0.474452346563E+00 0.148927307129E+03 and the rest of the calculation for the DOS and spectra proceeds without trouble. Having an energy window this large is not practical for me however. In order to compare with my experimental results I need to bring the upper energy limit to about 0.83 Ry. Doing this gives the following case.rxes: Energy 0.500 0.830 atom,column 6 3 0 0 1 1 0.170639701031E+22 0.942095565796E+01 1 2 0.194154866040E-01 0.972570705414E+01 1 3 0.162541195750E-01 0.901446437836E+01 1 4 0.164440535009E-01 0.778677415848E+01 1 5 0.144636239856E-01
[Wien] Need help please
Resp. AllIn calculation I am facing the following problem, please help me. Error in lapw2'FERMI -# of k-points in up and down not equal:'FERMI -k1, 224 225 check INPUTS OF LAPW1 With best regardssikander ___ 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)
Hi, I am a bit late to this thread, but I wanted to point to this earlier post where I had the same problem: http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10349.html I /think/ I found that the error happened with gfortran but not ifort (which might help explain how the bug slipped through). This thread http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07949.html also discusses evidently the same issue. But about -fno-whole-file, note that on my machine (gfortran 4.8), the docs say “The '-fno-whole-file' option is deprecated and may lead to wrong code”; in gfortran 4.9 the option was effectively removed https://gcc.gnu.org/wiki/GFortran/News#gfortran_4.9. Anyhow I do not see how -fno-whole-file relates to the end-of-file issue. Finally there is this gcc bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477 which seems to me to imply that gfortran is simply adhering to a stricter interpretation of the standard than ifort (as it often does). But note that I have not checked if the issue in mixer.F is really the same as in the bug report. HTH, Elias On 04/16/2015 07:42 AM, Jiayi Wu wrote: Dear wien2k users: I am a new Wien2k user . I am running version 13.1 on debian7.7.0 compiling with gfortran. The purpose of my calculations is to get the DOS of Fe2CrAl including the spin-orbit coupling.I am following the user guide for this calculation. runsp_lapw save_lapw case_nrel initso_lapw runsp_lapw -so There are the case.inso WFFIL 4 1 0 llmax,ipr,kpot -10. 10.0 emin,emax (output energy window) 1. 1. 1. direction of magnetization (lattice vectors) 2 number of atoms for which RLO is added 1 -4.97 0.0005 atom number,e-lo,de (case.in1), repeat NX times 3 -4.97 0.0005 atom number,e-lo,de (case.in1), repeat NX times 2 2,4number of atoms for which SO is switch off; atoms But, it happens after I was running runsp_lapw -so . Checking the STDOUT I have the following: hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END STOP CORE END STOP CORE END At line 968 of file mixer.F (unit = 22, file = 'FeCrAlSi.scf') Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE stop error Have tried many methods, but those did not work. I do not know where was wrong and how should I do. Please help me, thanks! Jiayi ___ 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] Fraction of electron doping-Charged cells
Dear WIEN2k developers and users,Hi!I know that the procedure in WIEN2k-FAQ: Charged cells is to introduce a background charge so that the system is neutral again.As NE in case.in2 is increased by delta , this delta should be used in case.inm. My concern is about delta .Can I take delta to be a fraction number?I am concerning about doping a fraction of electron in the supercell by adding 0.1,0.2,0.3 etc or removing -0.1,-0.2,-0.3etc instead of adding or removing an integer number of electrons.I need to make sure that the procedure is also valid for doping a fraction of electrons in the supercell or not.Thanks a lot in advance.With best regardsMohammed ___ 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] PhD position in Vienna
TU Vienna: PhD position in the Computational Quantum Chemistry Group We are happy to announce the opening of a PhD position in the area of density functional theory (DFT) and high pressure phase transitions with a planned duration of 3 years. Successful candidates will work out the specific theory for the stress tensor, implement it into our well-established WIEN2k DFT code (http://www.wien2k.at/), and investigate possible applications to a new approach for the description of high pressure phase transitions based on coupling nonlinear elasticity theory to Landau theory. Successful candidates will have a degree in at least one of these fields: physics, chemistry or materials science. As the work will be purely theoretical, a good knowledge of quantum mechanics, solid state physics, statistical mechanics and common mathematical methods of theoretical physics (differential equations, group theory, ...) is assumed. Programming skills are highly welcome. Interested candidates should send their application and scientific curriculum vitae to PD Dr. Andreas Tröster (andreas.troes...@tuwien.ac.at). Please include in the subject line: YourLastName: Application for PhD Position. The position is available starting from Aug. 1, 2015, and the exact starting date is negotiable. Apart from salary including medical insurance, excellent travel and computing support will be provided. Applications will be accepted until the position is filled. Application materials will be considered without regard to the gender, race, or nationality of the applicant. For further information please contact PD Dr. Andreas Tröster andreas.troes...@tuwien.ac.at http://homepage.univie.ac.at/andreas.troester/ or Prof. Dr. Peter Blaha pbl...@theochem.tuwien.ac.at http://www.imc.tuwien.ac.at/staff/tc_group_e.php ___ 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
