Hi, Pablo, I am a new user of Siesta. I tried your example as an exercise. When I increased the number of points used from gamma to X, the result did change!
see here: 50 points: http://img.iphy.org/55c_50p.png 300 points: http://img.iphy.org/55c_300p.png I think you should check your input fdf file very carefully. Maybe something is wrong. Jeffei On Wed, Apr 15, 2009 at 12:41 PM, Pablo A. Denis <pab...@fq.edu.uy> wrote: > Dear Andrei Postnikov, > > thank you very much for your answer > (one more time!). > > what I mean when I said that that the results did not change, was that we > used a denser k-mesh along gamma to X (600 points) and it was still very > difficult to decide how the bands were connected. > > Thus, I guess that we need to do all the stuff, analyze the orbital > character of the bands (something difficult), denser k-mesh, check the DOS, > although as you said this won`t give 100 % guarantee. > > In others PW codes it is not different because of the plane-waves. The > difference is that you can use symmetry, and that can help you. > > Many thanks for you help, > > pablo > > > ----- Original Message ----- From: <apost...@uni-osnabrueck.de> > To: <SIESTA-L@listserv.uam.es> > Sent: Tuesday, April 14, 2009 7:11 PM > Subject: Re: [SIESTA-L] band mixing problem with siesta > > >> Dear Pablo, >> I see from your data that the crossing/no crossing happens >> between the argument values 0.020781 and 0.24937: >>> >>> .016625 -.069279 >>> .020781 -.026979 ( up to here increasing ) >>> .024937 -.040879 ( from here on decreasing ) >>> .029093 -.077879 >> >> ...................... >>> >>> .016625 .034121 >>> .020781 .003579 ( up to here decreasing ) >>> .024937 .014821 ( from here on increasing ) >>> .029093 .056121 >> >> In my understanding, you'll see it with better "resolution" >> if using a more dense k-mesh along the Gamma-X path. >> In this sense, I don'understand how it can be that, as you write, >> >>> We have (...) increased the number of points used from gamma to X >>> and the results did not change. >> >> What exactly did not change? You'll have different argument values now >> and new function values corresponding to them! >> On the contrary, it is clear that whatever you tried otherwise >> >>> We have increased the number of k points, mesh cut-off, orbital confining >>> cut-off, >> >> won't have effect on how you see the bands "connected" or not >> (unless these experiments distort the band structure completely). >> >> In principle, there is no rocksolid way to see how the bands are >> connected UNLESS you take a limit of dense enough k-mesh >> (along the path you are interested in), in order to "resolve" >> a crossing from an avoided crossing. You can analyze the orbital >> character of bands before and after the suspected crossing >> but even this won't give the 100% guarantee because the orbital >> composition may change through the crossing. >> >> In order to distinguish a zero-gap semiconductor, I'd suggest, >> explore some vicinity of the suspected region... >> >> In practical sense, in a calculation with probably any code, >> the band energies come out numbered in the order of their >> increasing energies, separately in each k-points. >> So - sorry - I fail to see how it can be >> different in a PW code you refer to. Could you please explain it better? >> >> Best regards >> >> Andrei Postnikov >> >> >>> Dear Siesta users, >>> >>> We are having some problems with the band >>> structure. The face this problem when we >>> have metallic systems which have for example >>> 2 bands which crosses the fermi level ( a >>> (n,n) SWCNT for example). When we use >>> gnubands to plot get the bands.dat, these >>> two bands are mixed. In the case of a (5,5) >>> SWCNT we get (from gamma to X) >>> >>> .000000 -.241079 >>> .004156 -.198779 >>> .008312 -.155179 >>> .012468 -.111979 >>> .016625 -.069279 >>> .020781 -.026979 >>> .024937 -.040879 >>> .029093 -.077879 >>> .033249 -.114579 >>> .037405 -.150979 >>> .041561 -.186979 >>> .045718 -.222679 >>> .049874 -.258079 >>> .054030 -.293179 >>> .058186 -.327879 >>> .062342 -.362379 >>> .066498 -.396379 >>> .070654 -.430179 >>> .074811 -.463579 >>> .078967 -.496579 >>> .083123 -.529379 >>> >>> and >>> >>> .000000 .184921 >>> .004156 .148821 >>> .008312 .110321 >>> .012468 .072021 >>> .016625 .034121 >>> .020781 .003579 >>> .024937 .014821 >>> .029093 .056121 >>> .033249 .096921 >>> .037405 .137121 >>> .041561 .176921 >>> .045718 .216221 >>> .049874 .254921 >>> .054030 .293121 >>> .058186 .330721 >>> .062342 .367821 >>> .066498 .404321 >>> .070654 .440321 >>> .074811 .475721 >>> .078967 .510521 >>> .083123 .544721 >>> >>> >>> which is incorrect because none of them crosses the fermi level. In this >>> case we know that the system is metallic and we can fix this checking the >>> DOS and using grace. However, in other cases it is very hard to >>> understand >>> which is the correct assignment of the bands and decide whether or not >>> they were mixed, or if we have a metallic system or a zero band gap >>> semiconductor. >>> >>> We have increased the number of k points, mesh cut-off, orbital confining >>> cut-off, increased the number of points used from gamma to X and the >>> results did not change. The only way that we could overcome this problem >>> is using other plane-wave codes, but due to the size of the systems >>> studied we cannot do PW in every case. Thus, is there any way to overcome >>> this problem with siesta, or may be we are doing something weird? >>> >>> Many thanks in advance. >>> >>> Best regards, >>> >>> Pablo >>> >>> >> >> __________ NOD32 3989 (20090406) Information __________ >> >> This message was checked by NOD32 antivirus system. >> http://www.eset.com >> >> >
