From butler525 at hotmail.com Fri Nov 5 02:38:38 2010 From: butler525 at hotmail.com (Butler Butler) Date: Thu, 4 Nov 2010 20:38:38 -0500 Subject: [Wannier] get the conduction bands right Message-ID: Hi verybody, I am new to wannier functions. As I hate to guess the initial WFs case by case, I just designed my own automatic projection scheme and implemented it into our own code. Then I tested whether my projection works. So here is what I got: 1. By my projection scheme, for semiconductors, the valence bands are very well reproduced when num_bands=num_wann. That is, with no disentanglement, the interpolated bands are good. For simple systems such as GaAs, I need like 10 wannierise loops to get the smooth interpolated bands. 2. Including disentanglement (that is for num_bands>num_wann), the interpolating quality drastically drops. Not only the conduction bands are extremely bad, the quality of the valence bands are also ruined. 3. Setting the inner energy window (setting dis_froz_max to the top of the valence bands), the interpolating quality of the valence bands indeed improves. But never at the level when without disentanglement. Besides, the interpolated conduction bands are also improved. But the quality of both are still unacceptable. So I have the following questions: 1. From the above description, is there a hint of whether my projection scheme works or not? Or maybe there are just some bugs in my .amn coding? I have no idea why it seems to work very well for valence bands but not for conduction bands. From such sharp contrast, is there a hint of how I shall improve my projection? As a code developer, the above question is my biggest concern. If my scheme does not really work, then I have to implement some other schemes. 2. From the theory viewpoint, it seems there is a distinction on what are the best WFs for the valence and for the conduction. Then what is that? Basically I want know what are the best way to design the initial WFs, which works well for both the valence and conduction. 3. Disentanglement seems to be very sensitive to the .amn implementation, while the wannierise process is very insensitive to it (I note that we can even use Bloch phases for wannierise but not for disentanglement). Is that right? 4. Can I expect a good, unified projection scheme for most systems at all? Or maybe we just have to stay at the present status: different projections for different systems? I really do not want to guess every time. 5. Is it practical to expect to get the correct conduction & valence bands for really large systems (c.f. for hundreds of bands altogether)? Thanks for all reading this, Dr. Lin-Hui Ye Department of Electronics Peking University, China -------------- next part -------------- An HTML attachment was scrubbed... URL: From jxzhu at lanl.gov Tue Nov 16 21:02:08 2010 From: jxzhu at lanl.gov (Jian-Xin Zhu) Date: Tue, 16 Nov 2010 13:02:08 -0700 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) Message-ID: Dear Wannier users, Sometimes when I run wannier90.x -pp case, I get the following error as written to case.wout file .... Exiting....... Eq. (B1) not satisfied in kmesh_get (1) ..... What's the reason for this type of error and how can I get it resolved? Thanks, Jianxin -- ############################### Jian-Xin Zhu, Ph.D Theoretical Division, MS B262 Los Alamos National Laboratory Los Alamos, New Mexico 87545 Phone: (505) 667 2363 Fax: (505) 665 4063 Email (main): jxzhu at lanl.gov Email (backup): physjxzhu at gmail.com URL: http://theory.lanl.gov ############################### From marzari at MIT.EDU Wed Nov 17 00:54:18 2010 From: marzari at MIT.EDU (Nicola Marzari) Date: Tue, 16 Nov 2010 23:54:18 +0000 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: References: Message-ID: <4CE319AA.2010702@mit.edu> I presume your shells/stars of b_k vectors are not sufficient to reproduce a 3-dim gradient. Have a close look at which shells have been chosen. (e.g. - in a cubic crystal, the smallest shell (a star of 6 vectors) is good. in a tetragonal crystal, one shell will be a star of 4 vecors, or of 2 vectors, and won't be enough to describe a gradient). nicola On 11/16/10 8:02 PM, Jian-Xin Zhu wrote: > Dear Wannier users, > > Sometimes when I run wannier90.x -pp case, > > I get the following error as written to case.wout file > > .... > Exiting....... > Eq. (B1) not satisfied in kmesh_get (1) > ..... > > What's the reason for this type of error and how can I get it resolved? > > Thanks, > > Jianxin > > > -- --------------------------------------------------------------------- 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 jonathan.yates at materials.ox.ac.uk Wed Nov 17 01:03:20 2010 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Wed, 17 Nov 2010 00:03:20 +0000 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: References: Message-ID: <196E2794-911F-408D-A5E8-72C80FE395AA@materials.ox.ac.uk> On 16 Nov 2010, at 20:02, Jian-Xin Zhu wrote: > Dear Wannier users, > > Sometimes when I run wannier90.x -pp case, > > I get the following error as written to case.wout file > > .... > Exiting....... > Eq. (B1) not satisfied in kmesh_get (1) > ..... > > What's the reason for this type of error and how can I get it resolved? Jianxin, The code is trying to find a good set of b-vectors to make a finite difference representation of the position operator (see the CPC article for technical details). It has done this successfully for the gamma point, but has failed when trying to use those b-vectors for the other k-points in the grid. This could be caused by not specifying the k-points to sufficient precision in the win file (eg 0.666 vs 0.66666666666). There is a script in the utilities directory called kmesh.pl that will write the k-points with sufficient precision. If this does not resolve the problem, please post the win file. Yours Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ From wissgott at ifp.tuwien.ac.at Wed Nov 17 10:40:39 2010 From: wissgott at ifp.tuwien.ac.at (Philipp Wissgott) Date: Wed, 17 Nov 2010 10:40:39 +0100 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: References: Message-ID: <4CE3A317.5030808@ifp.tuwien.ac.at> Dear Jianxin, Did you get the error message in connection with the wien2wannier interface? If yes, take a look at the FAQ section of the userguide available at http://www.wien2k.at/reg_user/unsupported/wien2wannier/ . Best, Philipp On 11/16/2010 09:02 PM, Jian-Xin Zhu wrote: > Dear Wannier users, > > Sometimes when I run wannier90.x -pp case, > > I get the following error as written to case.wout file > > .... > Exiting....... > Eq. (B1) not satisfied in kmesh_get (1) > ..... > > What's the reason for this type of error and how can I get it resolved? > > Thanks, > > Jianxin > > > > From jxzhu at lanl.gov Fri Nov 19 00:47:19 2010 From: jxzhu at lanl.gov (Jian-Xin Zhu) Date: Thu, 18 Nov 2010 16:47:19 -0700 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: <196E2794-911F-408D-A5E8-72C80FE395AA@materials.ox.ac.uk> References: <196E2794-911F-408D-A5E8-72C80FE395AA@materials.ox.ac.uk> Message-ID: <4797EF69-080D-43E7-BE05-443CD292705D@lanl.gov> Dear Jonathan and Nicola, I looked into my *.win file. It looks the k-values in this file do not pose the precision issue (eg 0.666 vs 0.66666666666). .... begin kpoints 0.000000000 0.000000000 0.000000000 0.000000000 0.000000000 0.125000000 0.000000000 0.000000000 0.250000000 0.000000000 0.000000000 0.375000000 0.000000000 0.000000000 0.500000000 0.000000000 0.000000000 0.625000000 0.000000000 0.000000000 0.750000000 0.000000000 0.000000000 0.875000000 0.000000000 0.125000000 0.000000000 0.000000000 0.125000000 0.125000000 0.000000000 0.125000000 0.250000000 0.000000000 0.125000000 0.375000000 0.000000000 0.125000000 0.500000000 0.000000000 0.125000000 0.625000000 0.000000000 0.125000000 0.750000000 0.000000000 0.125000000 0.875000000 0.000000000 0.250000000 0.000000000 0.000000000 0.250000000 0.125000000 0.000000000 0.250000000 0.250000000 0.000000000 0.250000000 0.375000000 0.000000000 0.250000000 0.500000000 0.000000000 0.250000000 0.625000000 0.000000000 0.250000000 0.750000000 0.000000000 0.250000000 0.875000000 .... I understand you want me to run kmesh.pl and paste the generated k-values into the corresponding block of *.win file. I have tested the script file. It seems the generated k-values do not improve the precision much as compared with the above listed. One remark: The above listed k-values are generated from the wien2wannier interface. I have a strange observation. For the number of k-points of like 6 6 6 (a fcc structure), the error is encountered. For the number of k-points like 8 8 8, the error does not appear. However, if I use even larger number of k-points, e.g., 12 12 12, the error comes up again. It seems there is no guarantee to resolve the problem by increasing the number of k-points (Of course, the calculation also becomes more expensive with large number of k-points). Instead, the way as suggested by Philip by increasing the value of kmesh_tol (e.g., from 0.000001 to 0.001) might be a simple fix. Best regards, Jianxin On Nov 16, 2010, at 5:03 PM, Jonathan Yates wrote: > > On 16 Nov 2010, at 20:02, Jian-Xin Zhu wrote: > >> Dear Wannier users, >> >> Sometimes when I run wannier90.x -pp case, >> >> I get the following error as written to case.wout file >> >> .... >> Exiting....... >> Eq. (B1) not satisfied in kmesh_get (1) >> ..... >> >> What's the reason for this type of error and how can I get it resolved? > > Jianxin, > > The code is trying to find a good set of b-vectors to make a finite difference representation of the position operator (see the CPC article for technical details). It has done this successfully for the gamma point, but has failed when trying to use those b-vectors for the other k-points in the grid. This could be caused by not specifying the k-points to sufficient precision in the win file (eg 0.666 vs 0.66666666666). There is a script in the utilities directory called kmesh.pl that will write the k-points with sufficient precision. > If this does not resolve the problem, please post the win file. > > Yours > Jonathan > > > > > -- > Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK > tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://www.democritos.it/mailman/listinfo/wannier -- ############################### Jian-Xin Zhu, Ph.D Theoretical Division, MS B262 Los Alamos National Laboratory Los Alamos, New Mexico 87545 Phone: (505) 667 2363 Fax: (505) 665 4063 Email (main): jxzhu at lanl.gov Email (backup): physjxzhu at gmail.com URL: http://theory.lanl.gov ############################### From jonathan.yates at materials.ox.ac.uk Fri Nov 19 01:14:38 2010 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Fri, 19 Nov 2010 00:14:38 +0000 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: <4797EF69-080D-43E7-BE05-443CD292705D@lanl.gov> References: <196E2794-911F-408D-A5E8-72C80FE395AA@materials.ox.ac.uk> <4797EF69-080D-43E7-BE05-443CD292705D@lanl.gov> Message-ID: On 18 Nov 2010, at 23:47, Jian-Xin Zhu wrote: > One remark: The above listed k-values are generated from the wien2wannier interface. > I have a strange observation. For the number of k-points of like 6 6 6 (a fcc structure), the error is encountered. > For the number of k-points like 8 8 8, the error does not appear. However, if I use even larger number of k-points, > e.g., 12 12 12, the error comes up again. It seems there is no guarantee to resolve the problem by increasing the > number of k-points (Of course, the calculation also becomes more expensive with large number of k-points). There is simple explanation: 1/8 can be exactly represented with 3decimal places of precision. 1/6 and 1/12 cannot be precisely expressed with a finite number of decimal places. So the fact that you see the error with grids of size 6 and 12 but not 8 shows us that it is a precision error. So either you increase the precision of the kpoints. Or decrease the value of kmesh_tol. They will both achieve the same end. Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ From jxzhu at lanl.gov Fri Nov 19 02:55:02 2010 From: jxzhu at lanl.gov (Jian-Xin Zhu) Date: Thu, 18 Nov 2010 18:55:02 -0700 Subject: [Wannier] Eq. (B1) not satisfied in kmesh_get (1) In-Reply-To: References: <196E2794-911F-408D-A5E8-72C80FE395AA@materials.ox.ac.uk> <4797EF69-080D-43E7-BE05-443CD292705D@lanl.gov> Message-ID: <569161A8-7170-4BE7-9FCC-61838F7FC1EE@lanl.gov> Dear Jonathan, If it goes this way, I may avoid the error by using rational fractions in all three directions, like 1/20 1/20 1/10 (if allowed for a specific crystal structure). Does it make sense? Thanks, Jianxin On Nov 18, 2010, at 5:14 PM, Jonathan Yates wrote: > > On 18 Nov 2010, at 23:47, Jian-Xin Zhu wrote: >> One remark: The above listed k-values are generated from the >> wien2wannier interface. >> I have a strange observation. For the number of k-points of like 6 >> 6 6 (a fcc structure), the error is encountered. >> For the number of k-points like 8 8 8, the error does not appear. >> However, if I use even larger number of k-points, >> e.g., 12 12 12, the error comes up again. It seems there is no >> guarantee to resolve the problem by increasing the >> number of k-points (Of course, the calculation also becomes more >> expensive with large number of k-points). > > There is simple explanation: > 1/8 can be exactly represented with 3decimal places of precision. > 1/6 and 1/12 cannot be precisely expressed with a finite number of > decimal places. > So the fact that you see the error with grids of size 6 and 12 but > not 8 shows us that it is a precision error. > > So either you increase the precision of the kpoints. Or decrease the > value of kmesh_tol. They will both achieve the same end. > > Jonathan > > > > > > -- > Department of Materials, University of Oxford, Parks Road, Oxford, > OX1 3PH, UK > tel: +44 (0)1865 612797 http://users.ox.ac.uk/ > ~oums0549/ > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://www.democritos.it/mailman/listinfo/wannier -- ############################### Jian-Xin Zhu, Ph.D Theorertical Division, MS B262 Los Alamos National Laboratory Los Alamos, NM 87545 Phone: (505) 667 2363 Fax: (505) 665 4063 Emai: jxzhu at lanl.gov Email (backup): physjxzhu at gmail.com URL: http://theory.lanl.gov ############################### From autieri at sa.infn.it Fri Nov 26 10:11:11 2010 From: autieri at sa.infn.it (Carmine Autieri) Date: Fri, 26 Nov 2010 10:11:11 +0100 (CET) Subject: [Wannier] ERROR in hamiltonian_wigner_seitz In-Reply-To: <403002200.41535.1290694532760.JavaMail.root@mail> Message-ID: <966642903.42028.1290762671394.JavaMail.root@mail> Dear Wannier users, I am a Phd student and I am new on this forum. I am studying Sr2RuO4 and Sr3Ru2O7 and I want to calculate accurately hopping in the direction 100 and 010. When I study Sr3Ru2O7 all is ok. When I study Sr2RuO4, I find a problem for mpgrid = 8 8 2 or 10 10 4, but all is ok if I use the same number of k-points in all directions (mpgrid = 6 6 6 or 4 4 4). I change only the grid of k-points. I get the following error as written to case.wout file for mpgrid= 8 8 2 103 lattice points in Wigner-Seitz supercell: vector -5 3 -2 degeneracy: 2 vector -4 1 -2 degeneracy: 1 vector -4 2 -2 degeneracy: 1 vector -4 2 -1 degeneracy: 1 vector -4 3 -1 degeneracy: 1 vector -4 3 0 degeneracy: 1 vector -4 4 -1 degeneracy: 4 vector -4 4 0 degeneracy: 2 vector -4 4 1 degeneracy: 4 vector -3 0 -2 degeneracy: 1 vector -3 1 -2 degeneracy: 1 vector -3 1 -1 degeneracy: 1 vector -3 2 -1 degeneracy: 1 vector -3 2 0 degeneracy: 1 vector -3 3 -1 degeneracy: 2 vector -3 3 0 degeneracy: 1 vector -3 3 1 degeneracy: 2 vector -3 4 0 degeneracy: 1 vector -3 4 1 degeneracy: 1 vector -3 5 2 degeneracy: 2 vector -2 -1 -2 degeneracy: 1 vector -2 0 -2 degeneracy: 1 vector -2 0 -1 degeneracy: 1 vector -2 1 -1 degeneracy: 1 vector -2 1 0 degeneracy: 1 vector -2 2 -1 degeneracy: 2 vector -2 2 0 degeneracy: 1 vector -2 2 1 degeneracy: 2 vector -2 3 0 degeneracy: 1 vector -2 3 1 degeneracy: 1 vector -2 4 1 degeneracy: 1 vector -2 4 2 degeneracy: 1 vector -1 -2 -2 degeneracy: 1 vector -1 -1 -2 degeneracy: 1 vector -1 -1 -1 degeneracy: 1 vector -1 0 -1 degeneracy: 1 vector -1 0 0 degeneracy: 1 vector -1 1 -1 degeneracy: 2 vector -1 1 0 degeneracy: 1 vector -1 1 1 degeneracy: 2 vector -1 2 0 degeneracy: 1 vector -1 2 1 degeneracy: 1 vector -1 3 1 degeneracy: 1 vector -1 3 2 degeneracy: 1 vector -1 4 2 degeneracy: 1 vector 0 -3 -2 degeneracy: 1 vector 0 -2 -2 degeneracy: 1 vector 0 -2 -1 degeneracy: 1 vector 0 -1 -1 degeneracy: 1 vector 0 -1 0 degeneracy: 1 vector 0 0 -1 degeneracy: 2 vector 0 0 0 degeneracy: 1 vector 0 0 1 degeneracy: 2 vector 0 1 0 degeneracy: 1 vector 0 1 1 degeneracy: 1 vector 0 2 1 degeneracy: 1 vector 0 2 2 degeneracy: 1 vector 0 3 2 degeneracy: 1 vector 1 -4 -2 degeneracy: 1 vector 1 -3 -2 degeneracy: 1 vector 1 -3 -1 degeneracy: 1 vector 1 -2 -1 degeneracy: 1 vector 1 -2 0 degeneracy: 1 vector 1 -1 -1 degeneracy: 2 vector 1 -1 0 degeneracy: 1 vector 1 -1 1 degeneracy: 2 vector 1 0 0 degeneracy: 1 vector 1 0 1 degeneracy: 1 vector 1 1 1 degeneracy: 1 vector 1 1 2 degeneracy: 1 vector 1 2 2 degeneracy: 1 vector 2 -4 -2 degeneracy: 1 vector 2 -4 -1 degeneracy: 1 vector 2 -3 -1 degeneracy: 1 vector 2 -3 0 degeneracy: 1 vector 2 -2 -1 degeneracy: 2 vector 2 -2 0 degeneracy: 1 vector 2 -2 1 degeneracy: 2 vector 2 -1 0 degeneracy: 1 vector 2 -1 1 degeneracy: 1 vector 2 0 1 degeneracy: 1 vector 2 0 2 degeneracy: 1 vector 2 1 2 degeneracy: 1 vector 3 -5 -2 degeneracy: 2 vector 3 -4 -1 degeneracy: 1 vector 3 -4 0 degeneracy: 1 vector 3 -3 -1 degeneracy: 2 vector 3 -3 0 degeneracy: 1 vector 3 -3 1 degeneracy: 2 vector 3 -2 0 degeneracy: 1 vector 3 -2 1 degeneracy: 1 vector 3 -1 1 degeneracy: 1 vector 3 -1 2 degeneracy: 1 vector 3 0 2 degeneracy: 1 vector 4 -4 -1 degeneracy: 4 vector 4 -4 0 degeneracy: 2 vector 4 -4 1 degeneracy: 4 vector 4 -3 0 degeneracy: 1 vector 4 -3 1 degeneracy: 1 vector 4 -2 1 degeneracy: 1 vector 4 -2 2 degeneracy: 1 vector 4 -1 2 degeneracy: 1 vector 5 -3 2 degeneracy: 2 Exiting....... ERROR in hamiltonian_wigner_seitz: error in finding Wigner-Seitz points How can I solve this problem? Thanks, Carmine From jonathan.yates at materials.ox.ac.uk Fri Nov 26 11:36:52 2010 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Fri, 26 Nov 2010 10:36:52 +0000 Subject: [Wannier] ERROR in hamiltonian_wigner_seitz In-Reply-To: <966642903.42028.1290762671394.JavaMail.root@mail> References: <966642903.42028.1290762671394.JavaMail.root@mail> Message-ID: On 26 Nov 2010, at 09:11, Carmine Autieri wrote: > Dear Wannier users, > > I am a Phd student and I am new on this forum. > I am studying Sr2RuO4 and Sr3Ru2O7 and I want to calculate accurately hopping in the direction 100 and 010. > When I study Sr3Ru2O7 all is ok. > When I study Sr2RuO4, I find a problem for mpgrid = 8 8 2 or 10 10 4, but all is ok if I use > the same number of k-points in all directions (mpgrid = 6 6 6 or 4 4 4). I change only the grid of k-points. > > > I get the following error as written to case.wout file for mpgrid= 8 8 2 > 103 lattice points in Wigner-Seitz supercell: Carmine, That routine is looping over a supercell of the unitcell to try to find all of the points in the Wigner-Seitz cell. The size of the search supercell is hardwired. I had thought the values were sufficient to catch most physical cases (at least no one had reported a problem in the past few years) however, I'm guessing that your cell and kpoint mesh requires a bigger search supercell. I think I will modify the code to use a keyword to set the search supercell. Then if the routine fails to find all of the points it can suggest increasing the parameter. (it could do this automatically..) If you like a challenge, modify hamiltonian_wigner_seitz yourself. Otherwise I will do it in the next few days. In either case I'd be interested in the *.win file - to know that we have fixed the issue, and also to make sure what I have described really is the problem. Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/