Hi Nick, Thank you for your answers. I appreciate it. Recently, I do some other tests and I put it here.
cores Transiesta Tbtrans 32 8h 19m 41s 557ms 47m 46s 89ms 48 6h 29m 41s 770ms 47m 37s 510ms 64 4h 18m 26s 283ms 47m 32s 215ms 96 4h 20m 11s 997ms 47m 28s 189ms The number of energy points is 43. I have two questions for the result. 1. Why it takes longer time on 48 node if transiesta parallels across energy points? 2. Why it takes the same time for tbtrans if tbtrans parallels across energy points? Another question is on the linear scalability for atom number. I have read this article: The SIESTA method; developments and applicability <http://iopscience.iop.org/article/10.1088/0953-8984/20/6/064208/meta;jsessionid=6E37FEDC0B8943CD097C536638603E54.c4.iopscience.cld.iop.org>. It said siesta was coupled to several linear-scaling solvers. And also said other method scaling as N^3. Does this means siesta scaling between linear and N^3? What about transiesta and tbtrans? Thanks for your time. Really appreciate your help. Best, Yangchuan ME | UT Austin On Wed, Aug 24, 2016 at 3:58 PM, Nick Papior <[email protected]> wrote: > > > On 24 Aug 2016 21:55, "Yangchuan Li" <[email protected]> wrote: > > > > Hi Nick, > > > > I really appreciate your answer. It makes my work more efficient. > > Recently I also do a siesta speed test. It's a geometry optimization > running. I select k grid to be 1x1x4. And I run on 64, 128, 256 cores. > There is no speed up as a result. > > So, is it right to make the following summary? > > 1. siesta is parallel across k points (points in .KP file which after > symmetry analysis). > No, by default siesta is parallel over orbitals. Unless you specifically > request k parallelization. > However, there is a limit to the scalability (for any code), say if your > system have very few orbitals then parallelization to many cores will be > dominated by overhead. > > 2. transiesta is parallel across energy points, which is the sum of > three variable (TS.ComplexContour.NumCircle, TS.ComplexContour.NumLine, > TS.ComplexContour.NumPoles) > Yes. > > 3. tbtrans is parallel across k points, which is not related with kz. > But the kxy point after symmetry analysis. > No, tbtrans is also parallel across energy points. > > 4. There is no need to use cores more than energy points. > For tbtrans and transiesta, this is currently true. > > Is there anything wrong with my understanding? > > Thanks for your time. > > > > Best regards, > > Yangchuan Li > > Graduate research assistant > > ME | UT Austin > > > > On Fri, Aug 19, 2016 at 4:12 PM, Nick Papior <[email protected]> > wrote: > >> > >> Transiesta does not calculate the transmission, so the number of energy > points is irrelevant for this calculation. > >> > >> The number of points for transiesta is determined from the flags > explained in section 8.7.3 of siesta 4.0 manual. > >> See here: > >> https://launchpad.net/siesta/4.0/4.0/+download/siesta.pdf > >> > >> -- > >> > >> Kind regards Nick Papior > >> > >> > >> On 19 Aug 2016 22:16, "Yangchuan Li" <[email protected]> wrote: > >>> > >>> Hi Nick, > >>> > >>> Thank you for your answer. Yes, you are right. In the output of > tbtrans the number of energy points is 43. > >>> But how can I know the number ahead? In electrode the k-points are > 1x1x10, in system the k-pts are 1x1x100. And I select 121 points in > transmission vs energy plot. How transiesta select the final points to be > 43? > >>> Hope you can answer this so I can use resources efficiently. I > appreciate your answer. Thanks. > >>> > >>> Yangchuan > >>> Graduate research assistant > >>> ME | UT Austin > >>> > >>> > >>> On Thu, Aug 18, 2016 at 12:00 AM, Nick Papior <[email protected]> > wrote: > >>>> > >>>> This is not surprising, transiesta is only parallelized across energy > points. This means you probably have between 33 and 64 energy points on > your contour. > >>>> > >>>> 2016-08-17 23:00 GMT+02:00 Yangchuan Li <[email protected]>: > >>>>> > >>>>> Dear siesta users, > >>>>> > >>>>> I did a speed up test of transiesta (version 4.0 stable) on a > cluster. I run a job of 380 atoms with different number of cores. And here > is the result. The running time doesn't include tbtrans running. > >>>>> cores Transiesta > >>>>> 32 8h 19m 41s 557ms > >>>>> 64 4h 18m 26s 283ms > >>>>> 96 4h 20m 11s 997ms > >>>>> 128 4h 18m 9s 189ms > >>>>> 256 4h 18m 37s 196ms > >>>>> 512 4h 19m 8s 984ms > >>>>> > >>>>> It seems strange because from 32 to 64 I got a perfect speed up, > while increase the cores from 64 doesn't give me anything. > >>>>> So, why this happened and is there a way to speed up more? > >>>>> Any comments will be appreciated. Thanks. > >>>>> > >>>>> Yangchuan > >>>>> Graduate research assistant > >>>>> ME | UT Austin > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Kind regards Nick > >>> > >>> > > > > -- > Kind regards Nick >
