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.1446362
Re: [Wien] A few (more) elementary -so questions (with onsite -eece)
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 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
[Wien] A few (more) elementary -so questions (with onsite -eece)
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 ___ 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
To reiterate what everyone else said, you should change your blacs, the "intelmpi" version only works if you are using impi (I am 98% certain). Normally this leads to a wierd but understandable error when lapw0/lapw1 initiate the mpi routines, not sure why this did not show up in your case. On Mon, May 4, 2015 at 12:56 PM, Gavin Abo wrote: > On page 131 in the User's Guide for Intel mkl 11.1 for Linux [ > https://software.intel.com/en-us/mkl_11.1_ug_lin_pdf ], it has: > > libmkl_blacs_intelmpi_lp64.so => LP64 version of BLACS routines for > Intel MPI and MPICH2 > > So -lmkl_blacs_intelmpi_lp64 might also work with MPICH2. > > From the compile settings, it looks like compiler version 11.1 build 46 > is being used, which uses version 10.2 Update 2 of mkl [ > > https://software.intel.com/en-us/articles/which-version-of-ipp--mkl--tbb-is-installed-with-intel-compiler-professional-edition > ]. > > I could not find the mkl system requirements page for 10.2, but for > 10.3, it has that 10.3 was validated with MPICH2 version 1.3.2p1 [ > https://software.intel.com/en-us/articles/intel-mkl-103-system-requirements > ]. > > The MVAPICH2-2.0a that was mentioned as being used is based on > MPICH-3.0.4 [ > > http://mvapich.cse.ohio-state.edu/static/media/mvapich/MV2_CHANGELOG-2.1.txt > ]. > > It looks like Intel did not validate MPICH3 until about mkl version 11.2 > with MPICH3 version 3.1 [ > https://software.intel.com/en-us/articles/intel-mkl-112-system-requirements > ]. > > Fermin, it looks like you provided information from the WIEN2k dayfile > and error files. However, are there any error messages in the standard > output? For example, standard output should be what you get in a > terminal after you execute "runsp_lapw -p". However, since clusters > typically require that calculations be submitted using a job submission > system, the standard output is usually written instead to a user > specified file. On some systems, for example, the calculation isn't > executed with "runsp_lapw -p" but with "qsub -j oe -o output.log > myscript.pbs" [ http://arc.it.wsu.edu/UserGuide/Using_Qsub.aspx ], where > the script file called myscript.pbs would contain a line to execute > "runsp_lapw -p" and the standard output would be written to the file > called output.log. > > On 5/4/2015 12:08 AM, Peter Blaha wrote: > > No !!! (Can use it only if you are using intelmpi). > > > > I'm not sure (and it may even depend on the compiler version) which > > mpi-versions are supported by intel. But maybe try the simplest version > > -lmkl_blacs_lp64 > > > > Am 04.05.2015 um 08:03 schrieb lung Fermin: > >> Is it ok to use -lmkl_blacs_intelmpi_lp64? > > > > ___ > 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 > -- 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] Error in mpi+k point parallelization across multiple nodes
On page 131 in the User's Guide for Intel mkl 11.1 for Linux [ https://software.intel.com/en-us/mkl_11.1_ug_lin_pdf ], it has: libmkl_blacs_intelmpi_lp64.so => LP64 version of BLACS routines for Intel MPI and MPICH2 So -lmkl_blacs_intelmpi_lp64 might also work with MPICH2. From the compile settings, it looks like compiler version 11.1 build 46 is being used, which uses version 10.2 Update 2 of mkl [ https://software.intel.com/en-us/articles/which-version-of-ipp--mkl--tbb-is-installed-with-intel-compiler-professional-edition ]. I could not find the mkl system requirements page for 10.2, but for 10.3, it has that 10.3 was validated with MPICH2 version 1.3.2p1 [ https://software.intel.com/en-us/articles/intel-mkl-103-system-requirements ]. The MVAPICH2-2.0a that was mentioned as being used is based on MPICH-3.0.4 [ http://mvapich.cse.ohio-state.edu/static/media/mvapich/MV2_CHANGELOG-2.1.txt ]. It looks like Intel did not validate MPICH3 until about mkl version 11.2 with MPICH3 version 3.1 [ https://software.intel.com/en-us/articles/intel-mkl-112-system-requirements ]. Fermin, it looks like you provided information from the WIEN2k dayfile and error files. However, are there any error messages in the standard output? For example, standard output should be what you get in a terminal after you execute "runsp_lapw -p". However, since clusters typically require that calculations be submitted using a job submission system, the standard output is usually written instead to a user specified file. On some systems, for example, the calculation isn't executed with "runsp_lapw -p" but with "qsub -j oe -o output.log myscript.pbs" [ http://arc.it.wsu.edu/UserGuide/Using_Qsub.aspx ], where the script file called myscript.pbs would contain a line to execute "runsp_lapw -p" and the standard output would be written to the file called output.log. On 5/4/2015 12:08 AM, Peter Blaha wrote: No !!! (Can use it only if you are using intelmpi). I'm not sure (and it may even depend on the compiler version) which mpi-versions are supported by intel. But maybe try the simplest version -lmkl_blacs_lp64 Am 04.05.2015 um 08:03 schrieb lung Fermin: Is it ok to use -lmkl_blacs_intelmpi_lp64? ___ 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] Bandstructure Plot Splits
Hi Peter, Thank you very much for the suggestions! Yes, it's a low symmetry case (a monoclinic system). The k-mesh was actually produced by a different code (not by xcrysden) but I'll try your suggestion to make it denser. Best, Ryky On Mon, May 4, 2015 at 6:02 AM, Peter Blaha wrote: > It seems to be some low symmetry case ? > > WIEN2k determines "directions" and finds correctly, that the direction > changes (drawing a line). On the other hand, it calculates the distance > between points, and if this distance suddenly increases a lot (as in your > case), it "thinks" there should be an offset. > > In addition, I can see that even the intervals are not the same (97 or 98) > in the second direction. > > Maybe some rounding problem in xcrysden ?? > > Try using a denser mesh in the second direction. > > > > > > On 05/01/2015 06:58 PM, Ryky Nelson wrote: > >> Hi wien2k users, >> >> I'm trying to plot a bandstructure for Ta2PdSe6 with the attached >> Ta_2Pd_Se_6.klist_band. After following the normal procedure I got the >> plot (BSTa_2Pd_Se_6_total.pdf) with two windows although there is no >> skip in the k-point list. Could anybody help me figure out why the >> windows split and the solution to this problem? >> >> Thank you! >> >> Best, Ryky >> >> >> ___ >> 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 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] Physical significance of magnetization direction with -so
I hope my five cent might be usefull: If you do have magnetic moments, be they ferro-, ferri-, or antiferromagnetic, or induced by an external field, the results can depend on the orientation of the moments. In addition, keep in mind that the various magnetic moments one likes to think of may not be constants of motion, or good quantum numbers, so they cannot be used to specify the eigenstates. Inasmuch as S and L are good quantum numbers Hund's first and second rules for single ions state that the ground state of an electron shell in the Coulomb potential of the nuclear charge will have maximum total spin moment S=\sum s_i and maximum total angular momentum L=\sum l_i compatibel with the Pauli principle. L and S are constants of motion, they commute with the Hamiltonian of the nuclear Coulomb potential. L and S can, therefore, be used to enumerate the eigenstates. The energy is given by the size of L and S. The direction of L and S is unimportant (for a single ion without magnetic field applied!) the nuclear Coulomb potential is radial symmetric. Each state of the shell is (2L+1)(2S+1)-fold degenerate. This degeneracy is partially split by spin-orbit coupling and by the electrostatic crystal field. You find the Hamiltionian for spin-orbit coupling H_so=\lambda (S*L) with S and L the vectors of the total spin and angular momentum of the electrons in one shell (say, d-, or f-shell) from considering the energy of an electron spin s in the magnetic field due to the relative motion of the nuclear charge with respect to the electron on its path at angular momentum l around the nucleus. With this H_so only J=L+S stays a constant of motion, neither S nor L. You can find the magnitude of J by Hund's third rule if H_so stays the most important player down to that energy. However, this is still just the radial symmetric potential of a single nuclear charge, the energy of the eigenstates is given by specifying J and you can point J in any direction. In a crystal the charge distribution of the surrounding ions also acts on the electrons in the shell. This crystal field Hamiltonian obviously is not spherical symmertric, it will reduce the rotational symmetry to the point symmetry of the site. If there is a magnetic moment on an ion the energy will depend on its direction in the lattice. This is the source of the magnetic single-ion anisotropy. What the eigenstates of the combined Hamiltonian look like depends on the relative size and symmetry of the contributions. For outer d-shells crystal fields usually dominate over H_so leading e.g. to what is called the quenching of the orbital angular momentum (L=0) which is sensitive to magnetic fields. For 4f-shells which are shielded by outer d- and s-shells H_so is frequently dominant and Hund's third rule often survives, allowing to calculate J and consider the dependance of the energy on its direction in the lattice. Martin --- Dr. Martin Pieper Karl-Franzens University Institute of Physics Universitätsplatz 5 A-8010 Graz Austria Tel.: +43-(0)316-380-8564 Am 03.05.2015 19:37, schrieb Laurence Marks: An elementary question: do the results of -so depend upon the magnetization direction used in initso, or should they in principle be independent of it? -- 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 Links: -- [1] http://www.numis.northwestern.edu [2] http://MURI4D.numis.northwestern.edu ___ 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] trouble with generating rxesw file
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 0.861922359467E+01 1 6 0.174109078944E-01 0.925869750977E+01 ... with the first entry reading xxxE+22, this already starts causing trouble for the DOS calculation. Matters only get worse if I narrow the energy range. However, it is only ever the weights in the first row that appear as NaN or xxxE+22, the rest of the file is always sensible. Would you have a guess as to what might be causing these first few entries to consistently read NaN, etc? Or any other suggestions about how to proceed? Thank you and very best regards, Thomas ___ 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] Bandstructure Plot Splits
It seems to be some low symmetry case ? WIEN2k determines "directions" and finds correctly, that the direction changes (drawing a line). On the other hand, it calculates the distance between points, and if this distance suddenly increases a lot (as in your case), it "thinks" there should be an offset. In addition, I can see that even the intervals are not the same (97 or 98) in the second direction. Maybe some rounding problem in xcrysden ?? Try using a denser mesh in the second direction. On 05/01/2015 06:58 PM, Ryky Nelson wrote: Hi wien2k users, I'm trying to plot a bandstructure for Ta2PdSe6 with the attached Ta_2Pd_Se_6.klist_band. After following the normal procedure I got the plot (BSTa_2Pd_Se_6_total.pdf) with two windows although there is no skip in the k-point list. Could anybody help me figure out why the windows split and the solution to this problem? Thank you! Best, Ryky ___ 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] Problem with qrsh -V -INHERIT in wien2k 13
Dear all, Maybe someone can help me with this problem I seems to have with the command "qrsh". I'am not sure what it is going on with some wien2k calculations in one node of 64 cpus of my cluster. The problem is related with the process of coping *.def* files to my working directory when lapw1c/2c_mpi runs. Sometimes it works fine but other times it fails, and that seems to be random. of course when I can create by hand these files in my directory and then wien2k works fine and I can by-pass the problem. The administrator of my cluster said that it is not a problem of file-permissions. Maybe it is related with the network traffic? or with some re-initializations of the qrsh before any other execution?, or an specific waiting time parameter of my cluster to be set in wien2k macros or programs? Now, I'm using opemmpi, but I tried different parallelism-methods with similar results. Have anyone an idea that I can suggest to my cluster administrator?, He also said me that the same problem appears with the last wien2k version. As the next lines show, the fail seems related with the command "qrsh -V -inherit...", Sincerely, César The output is the next: 64 nodes for this job: node046 starting parallel lapw1 at vie may 1 12:16:13 CEST 2015 -> starting parallel LAPW1 jobs at vie may 1 12:16:14 CEST 2015 running LAPW1 in parallel mode (using .machines) 32 number_of_parallel_jobs [1] 48397 ... ... ... [32] 50043 [2]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [2] 50297 [14] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [13] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [11] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [10] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [9]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [8]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [7]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [6]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [5]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [4]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [3]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [1]Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [18] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [12] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [15] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [1] 50399 [3] 50425 [4] 50452 [5] 50483 [17] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [6] 50511 [7] 50556 [16] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [19] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [8] 50663 [9] 50701 [10] 50737 [11] 50777 [12] 50819 [13] 50847 [14] 50893 [15] 50926 [16] 50956 [16] Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [15] - Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [14] + Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [13] + Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [12] + Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [11] + Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [10] + Fin ( $remote $remotemachine "cd $PWD;$t $ttt;rm -f .lock_$lockfile[$p]" ) >> .time1_$loop [9] + Fin ( $remote
