From jry20 at cam.ac.uk Fri Aug 1 00:47:36 2008 From: jry20 at cam.ac.uk (Jonathan Yates) Date: Thu, 31 Jul 2008 23:47:36 +0100 Subject: [Wannier] spread and wannier_list In-Reply-To: <1abcddff0807311035h5bcb051jc23129c1136e5fe8@mail.gmail.com> References: <1abcddff0807311035h5bcb051jc23129c1136e5fe8@mail.gmail.com> Message-ID: <6718AEA2-3D41-42B9-848D-D6093378D276@cam.ac.uk> On 31 Jul 2008, at 18:35, Vivek Ranjan wrote: > Hello, > > I am running wannier for a material. This one is giving me a lot of > trouble in terms of getting all the spreads closer to 1. One or two of > them always become closer to 25 angstrom. For a specific k-sampling, > however, I was able to get a satisfactory result. The problem is that > when the change wannier_plot_list the same starts getting a different > spread. For clarity, I put 28-32 in wannier_plot_list and get a > satisfactory spread. However, when I change the parameter (keeping > everything else the same) to 3, 20, the spreads for a couple of WF > changes. However, the total of WF-centres remain the same. > > I was wondering how the spreads are dependent on wannier_plot_list. I > am using wannier90-1.1. Vivek, The spreads should not depend in any way on wannier_plot_list. The keyword is used only at the very end of the calculation, after the MLWF have been computed. Is the effect actually due to wannier_plot_list, or is it the case that re-running the calculation (with the same input file) provides enough numerical noise to re-order the MLWF (the numbering is, of course, arbitrary)? As I've mentioned before, it is very helpful to be able to see the actual input/output files. If you prefer not to post them to the public list feel free to post them directly to myself and Arash. Jonathan -- Dr Jonathan Yates | Theory of Condensed Matter Group Corpus Christi College | Cavendish Laboratory Cambridge, CB2 1RH, UK | Cambridge, CB3 OHE, UK email jry20 at cam.ac.uk | Tel +44 (0)1223 337461 From Tonatiuh.Rangel at uclouvain.be Mon Aug 4 10:13:02 2008 From: Tonatiuh.Rangel at uclouvain.be (Tonatiuh Rangel) Date: Mon, 4 Aug 2008 10:13:02 +0200 (CEST) Subject: [Wannier] lcr transport Message-ID: <484455f4d8d97e6fb1c58446b280c0e9.squirrel@mmp.sipr-dc.ucl.ac.be> Dear all, I am trying to do transport calculations using Wannier90. In the Wannier90 tutorial there is just an example of transport calculations. This example shows how to do transport calcuation for bulk systems. But I want to calculate the quatum conductance for a system consisting of left and right leads connectred through a central conductor. I see in the user guide that I have to set transport_mode=lcr and I have to provide the name of the hamiltonian files in the input file. I would like to know how to generate these hamiltonian files. If there is an utility to do it. I see that I can make a transport calculation for bulk and set tran_write_ht=true to write the bulk hamiltonian. Then, I might build the other 5 hamiltoinians this hamiltonian. Is this correct? I would appreciate any clue. Best wishes Tonatiuh Rangel From marzari at MIT.EDU Mon Aug 4 10:32:09 2008 From: marzari at MIT.EDU (Nicola Marzari) Date: Mon, 04 Aug 2008 16:32:09 +0800 Subject: [Wannier] lcr transport In-Reply-To: <484455f4d8d97e6fb1c58446b280c0e9.squirrel@mmp.sipr-dc.ucl.ac.be> References: <484455f4d8d97e6fb1c58446b280c0e9.squirrel@mmp.sipr-dc.ucl.ac.be> Message-ID: <4896BE89.6010404@mit.edu> Dear Tonatiuh, I've replied with the details in a separate email, but just wanted to mention that we are working right now at making this more user friendly - in the meanwhile we should put a brief tutorial out, but I do not see this happening before everyone is back from holidays (Aug 20 or so). nicola Tonatiuh Rangel wrote: > Dear all, > > I am trying to do transport calculations using Wannier90. > > In the Wannier90 tutorial there is just an example of transport > calculations. This example shows how to do transport calcuation for bulk > systems. But I want to calculate the quatum conductance for a system > consisting of left and right leads connectred through a central conductor. > > I see in the user guide that I have to set transport_mode=lcr and I have > to provide the name of the hamiltonian files in the input file. > > I would like to know how to generate these hamiltonian files. If there is > an utility to do it. > I see that I can make a transport calculation for bulk and set > tran_write_ht=true to write the bulk hamiltonian. Then, I might build the > other 5 hamiltoinians this hamiltonian. Is this correct? > > I would appreciate any clue. > > Best wishes > Tonatiuh Rangel > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://www.democritos.it/mailman/listinfo/wannier -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From za.torbatian at yahoo.com Wed Aug 6 14:48:17 2008 From: za.torbatian at yahoo.com (zahra torbatian) Date: Wed, 6 Aug 2008 05:48:17 -0700 (PDT) Subject: [Wannier] (no subject) Message-ID: <312062.83655.qm@web46410.mail.sp1.yahoo.com> hello I have acquired 9 wannier functions for CrAs ( zince blend structure ) . can I acquire new wannier functions ( num_ wann> 9 ) with select proper projection? ?????? ??????????????????? num_bands?????????? =?? 16 num_wann??????????? = 9 Fermi_energy??????? =?? 7.2202 ? dis_froz_max???? = 10 dis_win_max????? =?? 20 ? exclude_bands??? =?? 1-4 ? begin unit_cell_cart bohr -5.345566537? 0.000000000? 5.345566537 ?0.000000000? 5.345566537? 5.345566537 -5.345566537? 5.345566537? 0.000000000 end unit_cell_cart begin atoms_frac Cr 0.00?? 0.00?? 0.00 As 0.25? 0.25? 0.25 end atoms_frac begin projections cr:d f=-0.125,-0.125, 0.375:s f= 0.375,-0.125,-0.125:s f=-0.125, 0.375,-0.125:s f=-0.125,-0.125,-0.125:s end projections ?begin kpoint_path ! L 0.50000? 0.50000 0.5000 G 0.00000? 0.00000 0.0000 ! G 0.00000? 0.00000 0.0000 X 0.50000? 0.00000 0.5000 ! X 0.50000? 0.00000 0.5000 K 0.37500 -0.37500 0.0000 ! K 0.37500 -0.37500 0.0000 G 0.00000? 0.00000 0.0000 ! end kpoint_path ! KPOINTS mp_grid : 6 6 6 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cras.bn.agr Type: application/octet-stream Size: 332070 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cras.bn.agr Type: application/octet-stream Size: 332070 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cras.bn.jpg Type: image/jpeg Size: 30163 bytes Desc: not available URL: From marzari at MIT.EDU Thu Aug 7 08:42:36 2008 From: marzari at MIT.EDU (Nicola Marzari) Date: Thu, 07 Aug 2008 14:42:36 +0800 Subject: [Wannier] Wannier post from lee0su@hotmail.com In-Reply-To: References: Message-ID: <489A995C.8060004@mit.edu> > Subject: RE: [Wannier] (no subject) > From: Young-Su Lee > Date: Thu, 7 Aug 2008 00:45:52 +0000 > > I think if you use enough number of bands, you can get num_wann > 9 bands. > > Maybe the next step is to select 13 wannier functions to include sp3 > anti-bonding type orbitals. > > > > youngsu -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From carlos.loia.reis at gmail.com Wed Aug 20 20:11:00 2008 From: carlos.loia.reis at gmail.com (Carlos Reis) Date: Wed, 20 Aug 2008 19:11:00 +0100 Subject: [Wannier] *.mmn file format Message-ID: <1382facf0808201111q66110ee4qbe26ff3e428d974c@mail.gmail.com> Hello I'm trying to calculate the spreads OmegaI, OmegaOD and OmegaD (equations 34, 35 and 36 of PRB 56, 12851) using the b vector list of the wannier90 output file and the information contained in the *mmn file. Are the blocks in this file ordered according to the order of the b vector list? kpt1 b1 kpt1 b2 . . . kpt1 bn kpt2 b1 kpt2 b2 . . . kpt2 bn . . . . kptn' bn I know that the file format is described in the User's Guide but I need to have a correspondence between a given block in this file and a given b vector but I don't think I understand how the list of 5 integers prior to each block can give me that. I'm sorry if this is a basic question. Any help will be appreciated. Best regards, Carlos Reis. From a.mostofi at imperial.ac.uk Thu Aug 21 02:38:31 2008 From: a.mostofi at imperial.ac.uk (Arash Mostofi) Date: Thu, 21 Aug 2008 01:38:31 +0100 Subject: [Wannier] *.mmn file format In-Reply-To: <1382facf0808201111q66110ee4qbe26ff3e428d974c@mail.gmail.com> References: <1382facf0808201111q66110ee4qbe26ff3e428d974c@mail.gmail.com> Message-ID: <48ACB907.3070704@imperial.ac.uk> Dear Carlos Let's say that a particular line in the nnkpts block of seedname.nnkp looks like 5 9 1 -1 0 The first integer tells us that we are considering kpoint number 5 in the list of kpoints given in the input file. Let's denote it by vector k. The second integer means that kpoint number 9 in the list of kpoints is a periodic image of the vector k+b. Note that the kpoint specified in the second column will always be in the first Brillouin zone, which is why the next three integers are there. They tell you which periodic image of the reciprocal cell the k+b that you actually want is in. In this example we have (k+b)_actual = (k+b)_1BZ + 1*B_1 + (-1)*B_2 + 0*B_3 where (k+b)_1BZ is kpoint number 9 in the list of kpoints, and B_i are the reciprocal lattice vectors. Given that you know k and can work out (k+b)_actual as above, then calculating the b-vector itself is not so difficult. Alternatively, if you look into the source code, the array called "bk" directly contains the b_vectors for each k-point. Hope that helps Arash -- :------------------------------------------------------------: : Dr. Arash A. Mostofi :: a.mostofi at imperial.ac.uk : : Lecturer and RCUK Fellow :: : : Depts. of Materials & Physics :: : : Imperial College London :: T +44 (0)207 594 6753 : : London SW7 2AZ, United Kingdom :: F +44 (0)207 594 6757 : :------- http://www.cmth.ph.ic.ac.uk/people/a.mostofi -------: Carlos Reis wrote: > Hello > > I'm trying to calculate the spreads OmegaI, OmegaOD and OmegaD > (equations 34, 35 and 36 of PRB 56, 12851) using the b vector list of > the wannier90 > output file and the information contained in the *mmn file. > > Are the blocks in this file ordered according to the order of the b vector list? > > kpt1 b1 > kpt1 b2 > . > . > . > kpt1 bn > kpt2 b1 > kpt2 b2 > . > . > . > kpt2 bn > . > . > . > . > kptn' bn > > I know that the file format is described in the User's Guide but I > need to have a correspondence between a given block in this file and a > given b vector but I don't think I understand how the list of 5 > integers prior to each block can give me that. > > I'm sorry if this is a basic question. Any help will be appreciated. > > Best regards, Carlos Reis. > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://www.democritos.it/mailman/listinfo/wannier From carlos.loia.reis at gmail.com Thu Aug 21 10:41:44 2008 From: carlos.loia.reis at gmail.com (Carlos Reis) Date: Thu, 21 Aug 2008 09:41:44 +0100 Subject: [Wannier] *.mmn file format Message-ID: <1382facf0808210141i5f16d982lfea477f8317de5e6@mail.gmail.com> Dear Arash Thank you very much for your response. It solves the problem! I would also like to congratulate you and your team for your excellent work on wannier90. Best regards, Carlos. From akut at yahoo.com Fri Aug 22 05:43:11 2008 From: akut at yahoo.com (Alex Kutana) Date: Thu, 21 Aug 2008 20:43:11 -0700 (PDT) Subject: [Wannier] Omega minimum search divergence in wannier90 Message-ID: <84393.30758.qm@web30507.mail.mud.yahoo.com> Dear wannier90 developers: I have encountered the following problem during the search for the minimum of omega in wannier90: at some step of the minimum search, the next omega is predicted to be smaller than the current one, whereas it turns out to be much larger, i.e. omega increases during the search. Since there seems to be no check on the actual (as opposed to predicted) value of the new omega, the whole search routine blows up from there. The increase in omega diagonal (O_D) occurs during step 3. Here are the values at the beginning of step 3: LINE --> Spread at initial point : 49.8723128210178 LINE --> Spread at trial step : 49.5779629623660 LINE --> Slope along search direction : -0.156333808720867 LINE --> Trial step length : 2.00000000000000 LINE --> Optimal parabolic step length : 17.0690978644447 LINE --> Spread at predicted minimum : 48.5380742807289 However, at the end of the step: O_D= 54.0158131 O_OD= 6.2368759 O_TOT= 77.7379108 <-- SPRD Delta: O_D= 0.2895663E+02 O_OD= -0.1091029E+01 O_TOT= 0.2786560E+02 <-- DLTA, i.e. the diagonal component of omega tilda increased by 29.0! I suspect it may also be a compiler issue, since I couldn't get wannier90 to run with gfortran on my machine, but it seems to run with no problem with ifort. Here is the link to the archive with my .win, .amn, .mmn, .eig, and .wout files: http://www.mediafire.com/?zx2cvkelcmx Thank you. Alex Kutana From marzari at MIT.EDU Fri Aug 22 10:43:55 2008 From: marzari at MIT.EDU (Nicola Marzari) Date: Fri, 22 Aug 2008 15:43:55 +0700 Subject: [Wannier] Omega minimum search divergence in wannier90 In-Reply-To: <84393.30758.qm@web30507.mail.mud.yahoo.com> References: <84393.30758.qm@web30507.mail.mud.yahoo.com> Message-ID: <48AE7C4B.7070603@mit.edu> Thanks Alex - Arash or Jonathan might comment better - here are my observations 1) when the optimal parabolic step length is much larger than the trial step length, it would be safer to choose a smaller step (e.g. 2 or 3 times the trial) and also reset to steepest descent the algorithm 2) it would be good to have a check that if the functional has not gone down, U and M are restored to the previous step, we go back to steepest descent, and the trial step length is halved (so that even a large step now will be 2 or 3 times the half trial). Alex, maybe you could even look into the code and fix these, nic Alex Kutana wrote: > Dear wannier90 developers: > > I have encountered the following problem during the search for the minimum of omega in wannier90: > at > some step of the minimum search, the next omega is predicted to be > smaller than the current one, whereas it turns out to be much larger, i.e. omega increases during the search. > Since > there seems to be no check on the actual (as opposed to predicted) > value of the new omega, the whole search routine blows up from there. > > The increase > in omega diagonal (O_D) occurs during step 3. Here are the values at the > beginning of step 3: > > LINE --> Spread at initial point : 49.8723128210178 > LINE --> Spread at trial step : 49.5779629623660 > LINE --> Slope along search direction : -0.156333808720867 > LINE --> Trial step length : 2.00000000000000 > LINE --> Optimal parabolic step length : 17.0690978644447 > LINE --> Spread at predicted minimum : 48.5380742807289 > > However, at the end of the step: > > O_D= 54.0158131 O_OD= 6.2368759 O_TOT= 77.7379108 <-- SPRD > Delta: O_D= 0.2895663E+02 O_OD= -0.1091029E+01 O_TOT= 0.2786560E+02 <-- DLTA, > > i.e. the diagonal component of omega tilda increased by 29.0! > I > suspect it may also be a compiler issue, since I couldn't get wannier90 > to run with gfortran on my machine, but it seems to run with no problem > with ifort. > Here is the link to the archive with my .win, .amn, .mmn, .eig, and .wout files: > http://www.mediafire.com/?zx2cvkelcmx > > Thank you. > > Alex Kutana > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://www.democritos.it/mailman/listinfo/wannier -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From jry20 at cam.ac.uk Fri Aug 22 19:40:56 2008 From: jry20 at cam.ac.uk (Jonathan Yates) Date: Fri, 22 Aug 2008 18:40:56 +0100 (BST) Subject: [Wannier] Omega minimum search divergence in wannier90 In-Reply-To: <48AE7C4B.7070603@mit.edu> References: <84393.30758.qm@web30507.mail.mud.yahoo.com> <48AE7C4B.7070603@mit.edu> Message-ID: On Fri, 22 Aug 2008, Nicola Marzari wrote: > Thanks Alex - Arash or Jonathan might comment better - here > are my observations > > 1) when the optimal parabolic step length is much larger than > the trial step length, it would be safer to choose a smaller step > (e.g. 2 or 3 times the trial) and also reset to steepest > descent the algorithm > > 2) it would be good to have a check that if the functional has > not gone down, U and M are restored to the previous step, we > go back to steepest descent, and the trial step length is halved > (so that even a large step now will be 2 or 3 times the half trial). > > Alex, maybe you could even look into the code and fix these, Alex, Something I always try when the minimiser gives me very large spreads is guiding_centres = T (see comments about branch cuts in the orignal papers for the meaning of this keyword). At the moment this requires projections to be defined - however, a quick way to do this is to set begin projections random end projections With this set the minimisation goes down-hill very quickly - after 100 steps the spread is converged to 10^-7 giving Spreads (Ang^2) Omega I = 17.485221718 ================ Omega D = 0.010329097 Omega OD = 3.222348850 Final Spread (Ang^2) Omega Total = 20.717899666 - so, in this case, the upward jump in the spread is a bit misleading - but Nicola's suggestions are still worthwhile in the general case. Also note the keywords fixed_step and step_length. >> I >> suspect it may also be a compiler issue, since I couldn't get wannier90 >> to run with gfortran on my machine, but it seems to run with no problem >> with ifort. In the past I've had w90 working fine with gfortran on linux and osx. I'd be interested to know what the problem was, and the combination of compiler version, platform and libraries. (assuming this is the latest stable gfortran) Jonathan -- Dr Jonathan Yates | Theory of Condensed Matter Group Corpus Christi College | Cavendish Laboratory Cambridge, CB2 1RH, UK | Cambridge, CB3 OHE, UK email jry20 at cam.ac.uk | Tel +44 (0)1223 337461 From akut at yahoo.com Sat Aug 23 03:31:27 2008 From: akut at yahoo.com (Alex Kutana) Date: Fri, 22 Aug 2008 18:31:27 -0700 (PDT) Subject: [Wannier] Omega minimum search divergence in wannier90 Message-ID: <536218.1734.qm@web30504.mail.mud.yahoo.com> > > Alex, > > Something I always try when the minimiser gives me very large spreads is > guiding_centres = T > (see comments about branch cuts in the orignal papers for the meaning of > this keyword). > At the moment this requires projections to be defined - however, a quick > way to do this is to set > begin projections > random > end projections > > With this set the minimisation goes down-hill very quickly - after 100 > steps the spread is converged to 10^-7 giving > Spreads (Ang^2) Omega I = 17.485221718 > ================ Omega D = 0.010329097 > Omega OD = 3.222348850 > Final Spread (Ang^2) Omega Total = 20.717899666 Hi Jonathan, Thank you for your tip. Using guiding centers seems to do the trick. > > > - so, in this case, the upward jump in the spread is a bit misleading - > but Nicola's suggestions are still worthwhile in the general case. Also > note the keywords fixed_step and step_length. > I'd like to suggest another short-term solution for the cases when a stability problem like this is encountered: make the code fail with an error or issue a warning if omega starts increasing during the search. This will clearly tell the user that something may not be right in the calculation. > > In the past I've had w90 working fine with gfortran on linux and osx. > I'd be interested to know what the problem was, and the combination of > compiler version, platform and libraries. (assuming this is the latest > stable gfortran) > Here is an example of a discrepancy between ifort and gfortran: ifort and gfortran wannier90 are run on two identical sets of input files, producing different outputs: in the ifort case, Omega Total = 3.004308445, while in the gfortran case, Omega Total = 3.509288435. The names of output files are gr_ifort.wout and gr_gfortran.wout . The archive with all the files can be downloaded here: http://www.mediafire.com/?j0u10x3i4jy My system is Ubuntu linux, kernel version 2.6.24-19, run on an AMD64 2-core processor. The list of the dynamic libraries used by the 'gfortran' wannier90: ldd /opt/wannier90/bin/wannier90_gfortran_buggy linux-vdso.so.1 => (0x00007fff845fe000) liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x00007f8c7b911000) libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x00007f8c7af73000) libg2c.so.0 => /usr/lib/libg2c.so.0 (0x00007f8c7ad43000) libgfortran.so.2 => /usr/lib/libgfortran.so.2 (0x00007f8c7aa84000) libm.so.6 => /lib/libm.so.6 (0x00007f8c7a803000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f8c7a5f5000) libc.so.6 => /lib/libc.so.6 (0x00007f8c7a293000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c7c269000) No static libraries are linked. The version of gfortran is 4.2.3. Alex Kutana -- Oleksandr Kutana, Scientific Research Assistant California Institute of Technology Division of Chemistry and Chemical Engineering Mail code 210-41 Pasadena, CA 91125 phone: (626)395-4283 email: kutana at cheme.caltech.edu webpage: http://www.che.caltech.edu/groups/kpg/group/alex/