From szaboa at iis.ee.ethz.ch Tue Jan 13 11:55:39 2015 From: szaboa at iis.ee.ethz.ch (Aron Szabo) Date: Tue, 13 Jan 2015 11:55:39 +0100 Subject: [Wannier] wannier90 + vasp initial projections parallelism Message-ID: <54B4F9AB.8020008@iis.ee.ethz.ch> Dear Wannier90 developers, I'm using vasp 5.3 and wannier90 2.0. I've noticed that the calculation of the initial projections for the wannierization in vasp is sequential, it doesn't speed up with the increasing number of cpu-s. For large systems I'm calculating separately smaller sets of projections to emulate some parallelism, but there is a huge overhead from calculating the overlaps first in each case. It can take 1-2 days just to start calculating the projections when I have 2-300 atoms (1-2000 bands). So generating the projections can take more time than the actual wannierization. If the calculation of the overlaps could be somehow switched off, it would already solve this problem practically, because then the calculation of the projections would scale nicely, and the overlaps could be calculated in a separate run. I'm not good in fortran, so I'm asking you whether it could be done maybe by just commenting out a few lines somewhere either in vasp's or wannier90's code, and if so, where is it exactly? I'm also interested if it is planned at all to parallelize the wannierization sometimes in the future, or is the problem itself something that's not possible to parallelize efficiently? Thanks in advance, Aron Szabo PhD student at IIS, ETH Zurich From nicola.marzari at epfl.ch Tue Jan 13 12:00:37 2015 From: nicola.marzari at epfl.ch (Nicola Marzari) Date: Tue, 13 Jan 2015 12:00:37 +0100 Subject: [Wannier] wannier90 + vasp initial projections parallelism In-Reply-To: <54B4F9AB.8020008@iis.ee.ethz.ch> References: <54B4F9AB.8020008@iis.ee.ethz.ch> Message-ID: <54B4FAD5.30508@epfl.ch> Hi Aron, but without overlaps you won't have MLWFs? I guess you are just trying to do "poor man's Wannier" via projections? Still, might be worth trying quantum-espresso, since those calculations are parallelized. All plane wave codes are fairly similar, at the end... I'll be in ETHZ next week (wed/thu), so we could always catch up there. nicola On 13/01/2015 11:55, Aron Szabo wrote: > Dear Wannier90 developers, > > I'm using vasp 5.3 and wannier90 2.0. I've noticed that the calculation > of the initial projections for the wannierization in vasp is sequential, > it doesn't speed up with the increasing number of cpu-s. For large > systems I'm calculating separately smaller sets of projections to > emulate some parallelism, but there is a huge overhead from calculating > the overlaps first in each case. It can take 1-2 days just to start > calculating the projections when I have 2-300 atoms (1-2000 bands). So > generating the projections can take more time than the actual > wannierization. If the calculation of the overlaps could be somehow > switched off, it would already solve this problem practically, because > then the calculation of the projections would scale nicely, and the > overlaps could be calculated in a separate run. I'm not good in fortran, > so I'm asking you whether it could be done maybe by just commenting out > a few lines somewhere either in vasp's or wannier90's code, and if so, > where is it exactly? I'm also interested if it is planned at all to > parallelize the wannierization sometimes in the future, or is the > problem itself something that's not possible to parallelize efficiently? > > Thanks in advance, > Aron Szabo > PhD student at IIS, ETH Zurich > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- ---------------------------------------------------------------------- Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL From szaboa at iis.ee.ethz.ch Tue Jan 13 12:35:17 2015 From: szaboa at iis.ee.ethz.ch (Aron Szabo) Date: Tue, 13 Jan 2015 12:35:17 +0100 Subject: [Wannier] wannier90 + vasp initial projections parallelism In-Reply-To: <54B4FAD5.30508@epfl.ch> References: <54B4F9AB.8020008@iis.ee.ethz.ch> <54B4FAD5.30508@epfl.ch> Message-ID: <54B502F5.9050604@iis.ee.ethz.ch> Dear Nicola, I meant to do separately the calculation of the overlaps (with the unmodified code. This part seemed to scale with the cpu-s, and it doesn't depend on the projections), and the calculations of the projections that could be "parallelized" by running vasp many times with selecting just a few projections in the input for each, and just concatenate the results (and change the band indices). That's how I do it now, and it works, but the overlaps are calculated in each case, while they are identical, and it takes a lot of time unnecessarily, making it impossible to go above a certain size (300 atoms approx.). Anyway, my next question would have been that how is it done in quantum espresso. So thank you for your answer, I'm going to check whether I could do all my tasks with quantum espresso. It seems to be more practical in this respect then. And thank you for your offer to meet in person. I will probably use the opportunity, and contact you in private to arrange the details. Best regards, Aron On 01/13/2015 12:00 PM, Nicola Marzari wrote: > > Hi Aron, > > > but without overlaps you won't have MLWFs? I guess you are just trying > to do "poor man's Wannier" via projections? > > Still, might be worth trying quantum-espresso, since those calculations > are parallelized. All plane wave codes are fairly similar, at the end... > > I'll be in ETHZ next week (wed/thu), so we could always catch up there. > > nicola > > > On 13/01/2015 11:55, Aron Szabo wrote: >> Dear Wannier90 developers, >> >> I'm using vasp 5.3 and wannier90 2.0. I've noticed that the calculation >> of the initial projections for the wannierization in vasp is sequential, >> it doesn't speed up with the increasing number of cpu-s. For large >> systems I'm calculating separately smaller sets of projections to >> emulate some parallelism, but there is a huge overhead from calculating >> the overlaps first in each case. It can take 1-2 days just to start >> calculating the projections when I have 2-300 atoms (1-2000 bands). So >> generating the projections can take more time than the actual >> wannierization. If the calculation of the overlaps could be somehow >> switched off, it would already solve this problem practically, because >> then the calculation of the projections would scale nicely, and the >> overlaps could be calculated in a separate run. I'm not good in fortran, >> so I'm asking you whether it could be done maybe by just commenting out >> a few lines somewhere either in vasp's or wannier90's code, and if so, >> where is it exactly? I'm also interested if it is planned at all to >> parallelize the wannierization sometimes in the future, or is the >> problem itself something that's not possible to parallelize efficiently? >> >> Thanks in advance, >> Aron Szabo >> PhD student at IIS, ETH Zurich >> _______________________________________________ >> Wannier mailing list >> Wannier at quantum-espresso.org >> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > From giovanni.pizzi at epfl.ch Tue Jan 13 13:12:20 2015 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Tue, 13 Jan 2015 13:12:20 +0100 Subject: [Wannier] wannier90 + vasp initial projections parallelism In-Reply-To: <54B502F5.9050604@iis.ee.ethz.ch> References: <54B4F9AB.8020008@iis.ee.ethz.ch> <54B4FAD5.30508@epfl.ch> <54B502F5.9050604@iis.ee.ethz.ch> Message-ID: <54B50BA4.60702@epfl.ch> Dear Aron, indeed, the calculation of overlaps and projections is done by the code interface, so for direct help of the VASP interface, you should address directly to the VASP developers (disabling the calculation of one part, or adding parallelism on the calculation of initial projections, should be easy, I believe). If you want to use Quantum ESPRESSO, as Nicola suggested, the executable to run is pw2wannier90.x (and since all tutorials of Wannier90 are written with this interface in mind, you will already find instructions and example input files to pw2wannier90.x in the Wannier90 tutorial/examples). You will want to explicitly define write_amn and write_mmn in the input file to pw2wannier90.x to select whether to calculate these matrices (other options exist to choose whether to write the u_nk for Wannier function plotting [write_unk], etc.; see the source file PP/src/pw2wannier90.f90 inside the QE distribution, for instance). Best, Giovanni On 01/13/2015 12:35 PM, Aron Szabo wrote: > Dear Nicola, > > I meant to do separately the calculation of the overlaps (with the > unmodified code. This part seemed to scale with the cpu-s, and it > doesn't depend on the projections), and the calculations of the > projections that could be "parallelized" by running vasp many times > with selecting just a few projections in the input for each, and just > concatenate the results (and change the band indices). That's how I do > it now, and it works, but the overlaps are calculated in each case, > while they are identical, and it takes a lot of time unnecessarily, > making it impossible to go above a certain size (300 atoms approx.). > > Anyway, my next question would have been that how is it done in > quantum espresso. So thank you for your answer, I'm going to check > whether I could do all my tasks with quantum espresso. It seems to be > more practical in this respect then. > > And thank you for your offer to meet in person. I will probably use > the opportunity, and contact you in private to arrange the details. > > Best regards, > Aron > > On 01/13/2015 12:00 PM, Nicola Marzari wrote: >> >> Hi Aron, >> >> >> but without overlaps you won't have MLWFs? I guess you are just trying >> to do "poor man's Wannier" via projections? >> >> Still, might be worth trying quantum-espresso, since those calculations >> are parallelized. All plane wave codes are fairly similar, at the end... >> >> I'll be in ETHZ next week (wed/thu), so we could always catch up there. >> >> nicola >> >> >> On 13/01/2015 11:55, Aron Szabo wrote: >>> Dear Wannier90 developers, >>> >>> I'm using vasp 5.3 and wannier90 2.0. I've noticed that the calculation >>> of the initial projections for the wannierization in vasp is >>> sequential, >>> it doesn't speed up with the increasing number of cpu-s. For large >>> systems I'm calculating separately smaller sets of projections to >>> emulate some parallelism, but there is a huge overhead from calculating >>> the overlaps first in each case. It can take 1-2 days just to start >>> calculating the projections when I have 2-300 atoms (1-2000 bands). So >>> generating the projections can take more time than the actual >>> wannierization. If the calculation of the overlaps could be somehow >>> switched off, it would already solve this problem practically, because >>> then the calculation of the projections would scale nicely, and the >>> overlaps could be calculated in a separate run. I'm not good in >>> fortran, >>> so I'm asking you whether it could be done maybe by just commenting out >>> a few lines somewhere either in vasp's or wannier90's code, and if so, >>> where is it exactly? I'm also interested if it is planned at all to >>> parallelize the wannierization sometimes in the future, or is the >>> problem itself something that's not possible to parallelize >>> efficiently? >>> >>> Thanks in advance, >>> Aron Szabo >>> PhD student at IIS, ETH Zurich >>> _______________________________________________ >>> Wannier mailing list >>> Wannier at quantum-espresso.org >>> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >> > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 From szaboa at iis.ee.ethz.ch Tue Jan 13 13:21:58 2015 From: szaboa at iis.ee.ethz.ch (Aron Szabo) Date: Tue, 13 Jan 2015 13:21:58 +0100 Subject: [Wannier] wannier90 + vasp initial projections parallelism In-Reply-To: <54B50BA4.60702@epfl.ch> References: <54B4F9AB.8020008@iis.ee.ethz.ch> <54B4FAD5.30508@epfl.ch> <54B502F5.9050604@iis.ee.ethz.ch> <54B50BA4.60702@epfl.ch> Message-ID: <54B50DE6.20409@iis.ee.ethz.ch> Dear Giovanni, thank you very much for your help. Best, Aron On 01/13/2015 01:12 PM, Giovanni Pizzi wrote: > Dear Aron, > indeed, the calculation of overlaps and projections is done by the > code interface, so for direct help of the VASP interface, you should > address directly to the VASP developers (disabling the calculation of > one part, or adding parallelism on the calculation of initial > projections, should be easy, I believe). > > If you want to use Quantum ESPRESSO, as Nicola suggested, the > executable to run is pw2wannier90.x (and since all tutorials of > Wannier90 are written with this interface in mind, you will already > find instructions and example input files to pw2wannier90.x in the > Wannier90 tutorial/examples). > You will want to explicitly define write_amn and write_mmn in the > input file to pw2wannier90.x to select whether to calculate these > matrices (other options exist to choose whether to write the u_nk for > Wannier function plotting [write_unk], etc.; see the source file > PP/src/pw2wannier90.f90 inside the QE distribution, for instance). > > Best, > Giovanni > > > On 01/13/2015 12:35 PM, Aron Szabo wrote: >> Dear Nicola, >> >> I meant to do separately the calculation of the overlaps (with the >> unmodified code. This part seemed to scale with the cpu-s, and it >> doesn't depend on the projections), and the calculations of the >> projections that could be "parallelized" by running vasp many times >> with selecting just a few projections in the input for each, and just >> concatenate the results (and change the band indices). That's how I >> do it now, and it works, but the overlaps are calculated in each >> case, while they are identical, and it takes a lot of time >> unnecessarily, making it impossible to go above a certain size (300 >> atoms approx.). >> >> Anyway, my next question would have been that how is it done in >> quantum espresso. So thank you for your answer, I'm going to check >> whether I could do all my tasks with quantum espresso. It seems to be >> more practical in this respect then. >> >> And thank you for your offer to meet in person. I will probably use >> the opportunity, and contact you in private to arrange the details. >> >> Best regards, >> Aron >> >> On 01/13/2015 12:00 PM, Nicola Marzari wrote: >>> >>> Hi Aron, >>> >>> >>> but without overlaps you won't have MLWFs? I guess you are just trying >>> to do "poor man's Wannier" via projections? >>> >>> Still, might be worth trying quantum-espresso, since those calculations >>> are parallelized. All plane wave codes are fairly similar, at the >>> end... >>> >>> I'll be in ETHZ next week (wed/thu), so we could always catch up there. >>> >>> nicola >>> >>> >>> On 13/01/2015 11:55, Aron Szabo wrote: >>>> Dear Wannier90 developers, >>>> >>>> I'm using vasp 5.3 and wannier90 2.0. I've noticed that the >>>> calculation >>>> of the initial projections for the wannierization in vasp is >>>> sequential, >>>> it doesn't speed up with the increasing number of cpu-s. For large >>>> systems I'm calculating separately smaller sets of projections to >>>> emulate some parallelism, but there is a huge overhead from >>>> calculating >>>> the overlaps first in each case. It can take 1-2 days just to start >>>> calculating the projections when I have 2-300 atoms (1-2000 bands). So >>>> generating the projections can take more time than the actual >>>> wannierization. If the calculation of the overlaps could be somehow >>>> switched off, it would already solve this problem practically, because >>>> then the calculation of the projections would scale nicely, and the >>>> overlaps could be calculated in a separate run. I'm not good in >>>> fortran, >>>> so I'm asking you whether it could be done maybe by just commenting >>>> out >>>> a few lines somewhere either in vasp's or wannier90's code, and if so, >>>> where is it exactly? I'm also interested if it is planned at all to >>>> parallelize the wannierization sometimes in the future, or is the >>>> problem itself something that's not possible to parallelize >>>> efficiently? >>>> >>>> Thanks in advance, >>>> Aron Szabo >>>> PhD student at IIS, ETH Zurich >>>> _______________________________________________ >>>> Wannier mailing list >>>> Wannier at quantum-espresso.org >>>> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier >>> >> >> _______________________________________________ >> Wannier mailing list >> Wannier at quantum-espresso.org >> http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > From zaldolam at email.uark.edu Tue Jan 13 20:58:48 2015 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Tue, 13 Jan 2015 13:58:48 -0600 Subject: [Wannier] overlaps seedname.nnkp are not generated Message-ID: Dear wannier's owners and developers, I have posted one question earlier, but I have not heard any response about it. My question is that I have run wannier90.x -pp to generate the overlaps seedname.nnkp before running pw2wannier90.x. However, they are not generated. I have found the below message Unable to satisfy B1 with any of the first 12 shells Your cell might be very long, or you may have an irregular MP grid Try increasing the parameter search_shells in the win file (default=12) Exiting....... kmesh_get_automatic I have looked for similar cases in the mailing list and found one suggestion to set kmesh_tol=0.00001 by Dr Jonathan Yate. Do I need to add this command to my seedname.win file? I did add it to my seedname.win file, but I got the same error message. I also tried to reduce the number of kponits chosen if this was the reason, but I still have the same problem. Would you please help me with it? I will appreciate any feedback as I feel that I miss something. Many thanks in advance I appreciate your time Zeina -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Tue Jan 13 21:08:29 2015 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Tue, 13 Jan 2015 20:08:29 +0000 Subject: [Wannier] overlaps seedname.nnkp are not generated In-Reply-To: References: Message-ID: <057CE136-2CBD-4AD1-8FC8-7F79B37D5C11@epfl.ch> Dear Zeina, difficult to give an answer without looking at the .win input file. If you need more help, you will need to post it too. One possible think to check: did you properly specify the kpoints, with the correct points and using enough digits? Are the points compatible with the mp_grid value? Did you use the kmesh.pl script to generate them? Best, Giovanni P.S.: Please, remember to add your affiliation at the end of your emails. -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 On 13 Jan 2015, at 20:58, Zeina Al-Dolami wrote: Dear wannier's owners and developers, I have posted one question earlier, but I have not heard any response about it. My question is that I have run wannier90.x -pp to generate the overlaps seedname.nnkp before running pw2wannier90.x. However, they are not generated. I have found the below message Unable to satisfy B1 with any of the first 12 shells Your cell might be very long, or you may have an irregular MP grid Try increasing the parameter search_shells in the win file (default=12) Exiting....... kmesh_get_automatic I have looked for similar cases in the mailing list and found one suggestion to set kmesh_tol=0.00001 by Dr Jonathan Yate. Do I need to add this command to my seedname.win file? I did add it to my seedname.win file, but I got the same error message. I also tried to reduce the number of kponits chosen if this was the reason, but I still have the same problem. Would you please help me with it? I will appreciate any feedback as I feel that I miss something. Many thanks in advance I appreciate your time Zeina _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Wed Jan 14 01:39:25 2015 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Tue, 13 Jan 2015 18:39:25 -0600 Subject: [Wannier] error opening xml data file Message-ID: Dr.Giovanni, I have followed your advice by using the same kpoints that are generated by kmesh.pl. It went smooth and seedname.nnkp file was generated. However, I get the below error message when I run pw2wannier90.x from pw_readfile : error # 1 error opening xml data file I have already checked whether there is a misspelling in the input file, but there is not. Would you please help me with it? Thanks in advance Zeina -------------- next part -------------- An HTML attachment was scrubbed... URL: From deyu.lu at gmail.com Wed Jan 14 04:39:22 2015 From: deyu.lu at gmail.com (Deyu Lu) Date: Tue, 13 Jan 2015 22:39:22 -0500 Subject: [Wannier] Band structure interpolation with "cut" mode Message-ID: Dear wannier90 users and developers: I'm relatively new to this code, and recently I've been using the band structure interpolation function. My motivation is to understand how the Hamiltonian in the Wannier basis ( H(R) ) decays as a function of distance. For practical purpose, I run my tests on bulk silicon in example 11 using occupied bands only and a 4x4x4 k-mesh. As bands_plot_mode = cut computes distance directly, I was testing the "cut" mode, and using "sk" as references. As bands_plot_dim = 3 was not allowed in version 1.2, but is enabled in version 2.0, all my calculations were performed with a 2.0 linux intel ifort build. I noticed several inconsistencies between "sk" and "cut", which I describe below. Perhaps someone can help me to clarify these points. 1. Degeneracy Wigner-Seize (WS) grid points in "sk" are properly renormalized, satisfying the sum rule: \sum_R 1/g(R)=64. Grid points in the "cut" method do not satisfy the sum rule. This can be seen for points with degeneracy in "sk" greater than one. The renormalization factor for the points in the "cut" mode is always one. As a result, in "cut", a 729-point real space mesh was transformed to a 64-point k mesh, without proper weight. 2. WS grid points Let us look at H11 (wannier centers i=j=1) to avoid the complexity from translation_centre_frac and shift_vec for different wannier centers. In "sk", there are 93 WS grid points. The first 87 grid points have the same coordinates and distances as in the "cut" mode. However, the last six are different. In "sk": distance H11 R 10.795215 0.003258 -2 -2 2 10.795215 0.003258 -2 2 2 10.795215 0.003258 -2 2 -2 10.795215 0.003258 2 -2 2 10.795215 0.003258 2 -2 -2 10.795215 0.003258 2 2 -2 In "cut", the last six are: distance H11 R 10.0980 0.003509 -1 -2 0 10.0980 0.003509 1 2 0 10.0980 0.003509 -1 3 0 10.0980 0.003509 1 -3 0 10.0980 0.003509 -2 -1 0 10.0980 0.003509 2 1 0 The discrepancy comes from the fact that these points in the "cut" mode are double-counted. Because, e.g., the WS grid point of (-1, -2, 0) should be (-1, 2, 0) with a smaller distance of 6.610692 angstrom, after being translated by (0, 4, 0). Finally, I wonder whether it is a better to stick to H(R) calculated for 93 WS points, and apply distance cutoff directly to this matrix instead of creating the 9x9x9 H(R) matrix in the "cut" mode. I did my own implementation, and the resulting interpolated band structure looks reasonable. Best regards, Deyu Lu Associate Physicist, Theory & Computation Group the Center for Functional Nanomaterials Rm 1002, Building 735, Brookhaven National Lab Upton, NY, 11973 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhdnsi at hanmail.net Tue Jan 20 05:56:59 2015 From: rhdnsi at hanmail.net (=?utf-8?B?6rOg7Jq0?=) Date: Tue, 20 Jan 2015 13:56:59 +0900 (KST) Subject: [Wannier] spin Chern number calculation using Wannier90 Message-ID: <20150120135659.HM.000000000000rII@rhdnsi.wwl1454.hanmail.net> An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Wed Jan 21 04:14:30 2015 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Tue, 20 Jan 2015 21:14:30 -0600 Subject: [Wannier] pw2wannier90.x: something wrong Message-ID: Dear Wannier90's owners and develpoers, I am running pw2wannier90.x to generate seedname.amn, seedname.mmn, and seedname.unk. However, I get the below error message. I am not sure about the reasons. Would you please help me with this problem? Any feedback is greatly appreciated as I am new to this field. Thanks in advance Zeina ----------------- *** Reading nnkp ----------------- Checking info from wannier.nnkp file Something wrong! rlatt(i,j) = 1.798435722546081E-002 at(i,j)= 1.00000000000000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaldolam at email.uark.edu Thu Jan 29 19:15:41 2015 From: zaldolam at email.uark.edu (Zeina Al-Dolami) Date: Thu, 29 Jan 2015 12:15:41 -0600 Subject: [Wannier] pw2wannier90.x: something wrong Message-ID: Dear owners and developers, I sent the below question about 9 days ago, but I have not heard any response. Would you please help me with it? I feel that I am lost and can not figure it out. Thanks in advance for any help or feedback Zeina Dear Wannier90's owners and developers, I am running pw2wannier90.x to generate seedname.amn, seedname.mmn, and seedname.unk. However, I get the below error message. I am not sure about the reasons. Would you please help me with this problem? Any feedback is greatly appreciated as I am new to this field. Thanks in advance Zeina ----------------- *** Reading nnkp ----------------- Checking info from wannier.nnkp file Something wrong! rlatt(i,j) = 1.798435722546081E-002 at(i,j)= 1.00000000000000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovanni.pizzi at epfl.ch Thu Jan 29 23:36:46 2015 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Thu, 29 Jan 2015 22:36:46 +0000 Subject: [Wannier] pw2wannier90.x: something wrong In-Reply-To: References: Message-ID: <317A7EB7-0A33-456E-AAAF-6EB5FA0CBE14@epfl.ch> Dear Zeina, If you look on google or on the archives of this mailing list, you will see that this question has been asked multiple times. A couple of examples: http://mailman.qe-forge.org/pipermail/wannier/2010-March/000316.html http://mailman.qe-forge.org/pipermail/wannier/2013-May.txt The answer is that the cell that you are entering in the DFT calculation and the cell that you are entering in the .win file are different; they should instead be identical (one of the elements is 1.798435722546081E-002 in one case, 1.0000 in the other). Please fix the definition of the cell in the .win file. Best, Giovanni -- Giovanni Pizzi Post-doctoral Research Scientist EPFL STI IMX THEOS MXC 340 (B?timent MXC) Station 12 CH-1015 Lausanne (Switzerland) Phone: +41 21 69 31124 On 29 Jan 2015, at 19:15, Zeina Al-Dolami wrote: > Dear owners and developers, > I sent the below question about 9 days ago, but I have not heard any response. Would you please help me with it? I feel that I am lost and can not figure it out. Thanks in advance for any help or feedback > > Zeina > > > > Dear Wannier90's owners and developers, > I am running pw2wannier90.x to generate seedname.amn, seedname.mmn, and seedname.unk. However, I get the below error message. I am not sure about the reasons. Would you please help me with this problem? Any feedback is greatly appreciated as I am new to this field. Thanks in advance > > Zeina > > ----------------- > *** Reading nnkp > ----------------- > > Checking info from wannier.nnkp file > > Something wrong! > rlatt(i,j) = 1.798435722546081E-002 at(i,j)= 1.00000000000000 > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier From sharmajncasr at gmail.com Sat Jan 31 06:08:18 2015 From: sharmajncasr at gmail.com (SRKC Sharma Yamijala) Date: Sat, 31 Jan 2015 10:38:18 +0530 Subject: [Wannier] Spin-orbit coupling and Pseudopotentials Message-ID: Dear Wannier Member, I am getting the following error message when I am using pw2wannier90 interface. Error in routine pw2wannier90 (1): NCLS calculation not implimented with USP After reading the previous mails, I understood that usage of norm-conserving PSPs is must if I need to use SO in my calculation (Please correct me if I am wrong), when using pw2wannier90 interface. On Espresso website, I couldn't get any norm-conserving PSP with full-relativistic effects. Could you please suggest me what should I do if I would like to continue with QE. Thanking you for your help and support, Sincerely, Sharma. ******************************************************** *Chaitanya Sharma,* *Prof. Pati'*s group, Chemistry and Physics Materials unit, JNCASR, BANGLORE, Lab:: (080-2208) 2581, 2809 https://sites.google.com/site/sharmasrkcyamijala/ ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: