Mailman 3 March 2019 - Kwant-discuss

Error using Qsymm in kwant
by Srilok Srinivasan March 19, 2019

March 19, 2019

Dear kwant developers, I am currently testing the new feature of kwant 1.4 - the interface with qsymm library. kag_lat = kwant.lattice.kagome() kagome = kwant.Builder(kwant.TranslationalSymmetry(*kag_lat.prim_vecs)) kagome[kag_lat.shape((lambda pos: True), (0, 0))] = 0 kagome[kag_lat.neighbors(1)] = 1 kwant.plot(kagome,site_color=family_color,site_lw=0.01) kagome = wraparound(kagome).finalized() #dispersion_2D(kag_lat,kagome) import kwant.qsymm kwant.qsymm.find_builder_symmetries(kagome) When I try to find the symmetries of the kagome lattice using the find_builder_symmetries I get the following error. Can you please help me fix this? ---------------------------------------------------------------------------TypeError Traceback (most recent call last)<ipython-input-10-b70a7b7c1860> in <module> 7 #dispersion_2D(kag_lat,kagome) 8 import kwant.qsymm----> 9 kwant.qsymm.find_builder_symmetries(kagome) /anaconda3/lib/python3.6/site-packages/kwant/qsymm.py in find_builder_symmetries(builder, momenta, params, spatial_symmetries, prettify, sparse) 449 450 ham = builder_to_model(builder, momenta=momenta,--> 451 real_space=False, params=params) 452 453 # Use dense or sparse computation depending on Hamiltonian size /anaconda3/lib/python3.6/site-packages/kwant/qsymm.py in builder_to_model(syst, momenta, real_space, params) 153 # translation vectors. 154 if dim == 0:--> 155 proj = np.empty((0, len(list(syst.sites())[0].pos))) 156 elif dim < len(list(syst.sites())[0].pos): 157 proj, r = la.qr(np.array(periods).T, mode='economic') TypeError: 'tuple' object is not callable Thanks Regards, Srilok Srinivasan

2 1

edge passivation
by kuangyia lee March 18, 2019

March 18, 2019

Hi everyone, I am not excellent in using kwant. Recently I want to use kwant to model the edge passivation to a ribbon structure (say a graphene ribbon). Can anyone show me how to implement? Thanks a lot. Best, Kuangyia

2 3

Kwant 1.4 version
by Ali Asgharpour March 18, 2019

March 18, 2019

Hello I think I have updated kwant on my laptop since it gives me the version 1.4.0a1 when I write kwant.version.version. But, new libraries added to the latest version such as kwant.kpm.conductivity or importing kwant.qsymm are not working when I call them. What should I do? Best regards, Ali

2 1

help on constructing a one-dimensional tight-binding chain using kwant
by Hanning Chen March 18, 2019

March 18, 2019

Dear kwant developers, I am a new user of kwant package. I just tried to build a very simple 10-site one-dimensional chain using kwant. It seems OK to assign the Hamiltonian matrix’s on-site elements, while the assignment of the matrix’s off-site elements is always problematic. Below is my first kwant script: alpha = 0 beta = -1 a = 1 lat = kwant.lattice.chain(a=1,name='10_site_1D_chain',norbs=1) L = 10 for i in range(L): for j in range(L): if (i == j): syst[lat(i)]=alpha print("ON-SITE HAMILTONIAN MATRIX ELEMENT: ",i," ",j," ",syst[lat(i)]) else: syst[lat(i),lat(j)]=beta print("OFF-SITE HAMILTONIAN MATRIX ELEMENT: ",i," ",j," ",syst[lat(i),lat(j)]); syst[lat(j),lat(i)]=beta print("OFF-SITE HAMILTONIAN MATRIX ELEMENT: ",j," ",i," ",syst[lat(j),lat(i)]); Please let me know how to fix this seemly simple problem. Thank you very much for your help in advance. Hanning Chen, Ph.D. Assistant Professor Department of Chemistry George Washington University Washington, DC 20052 http://www.chenlagbwu.net

2 1

relative coordinate of neighbor sites
by Hossein Karbaschi March 15, 2019

March 15, 2019

Dear all, I’m new in kwant and I want to use this package to calculate transport properties of some graphene-liked materials with multi orbital per atom. In order to define hopping in the form of matrix, we need to determine the relative coordinate of neighbor sites. If we build the system using latt = kwant.lattice.honeycomb could anyone help me to show how can I access the relative coordinate (I mean (x2-x1)i+(y2-y1)j) of neighbor sites? Thanks in advance! -- Hossein Karbaschi, PhD. in solid state physics.

2 1

updating values of sites and hoppings in Builder
by Marcin Kurpas March 15, 2019

March 15, 2019

Dear KWANT Developers and Users, I would like to write a modular code using KWANT, that allows turning on and off selected Hamiltonian terms H_i of the full Hamitonian H: H =H_1 + H_2 + H_3 + ... For simplicity let's assume, that H_1 and H_2 modify onsite energies of the same sites and the values of onsite energies are given by value functions. In low level programming one can write H(i,j) = H(i,j) + onsite(args) + onsite2(args) + ... I would like to implement similar approach in KWANT, but it seems to be a bit tricky. One cannot simply add two value functions as the "+" operator does not work for value functions. Similarly, defining a value fuction as def onsite(site): return sys[site] + U does not work for the same reasons, if previously the onsite energy for a site was given by the value function. Using separate builders for each H_i would be a nice approach, but unfortunately the method *update* overwrites the old values by new ones. I have found a partial solution to this problem import kwant def onsite1(site): return 2 def onsite2(site): return onsite1(site) + 2 N=4 syst=kwant.Builder() lat = kwant.lattice.square(a=1) syst[((lat(i,j)) for i in range(N) for j in range(N))]= onsite2 print(syst.finalized().hamiltonian_submatrix()) but I am not fully happy with it. The code is not really transparent and can get messy if more terms will be added. My question is : is there a more efficient way to implement such an approach in KWANT using builder object(s)? Best regards, Marcin Kurpas

2 2

Normalized Conductance
by Sergio Castillo Robles March 11, 2019

March 11, 2019

Hi programers, I was wondering if there is a way to plot the electronic quantum conductance of certain system but with the data being normalized (the max value set to 1 and the other values set accordingly)? Thanks for your time.

1 0

Dangling Bonds in Kwant
by Sergio Castillo Robles March 8, 2019

March 8, 2019

Hello everyone, I was wondering, what exactly does KWANT consider a dangling bond? An unsatisfied valence, a truncated unit cell,..? I was looking for detailed information in the documentation, but no success so far. Thanks for your time.

2 1

Heat and energy currents using tkwant
by RECK Phillipp March 8, 2019

March 8, 2019

Dear Thomas, dear kwant community, the purpose of this mail is to discuss the technical details to calculate time-dependent heat and energies currents using tkwant (extension of kwant which allows to create a time-dependent Hamiltonian and compute the time-dependent observables like densities and currents) and if/how our additional modules to do so can be integrated into tkwant. As far as I know, tkwant is not yet officially released but publicly available. Upon request of Christoph Groth, we will share our discussion with the kwant community and invite anyone to participate. As far as I know, the kwant mailing list was not (only) meant to be a Q&A platform for the community to ask questions to the developers but also for the whole community to discuss topics. Moreover, with the recent retiring of the developer mailing list, it was recommended to use the general mailing list also for development discussions. Still, this mail is mainly addressed to Thomas, which is why I apologize in advance for code details which are not explained and thus not understandable for everyone. That being said, let's come to the physics. I. Heat and energy currents in time-dependent systems ( https://github.com/PhiReck/heatCurrent ) We want to calculate time-dependent heat currents into a lead. The heat current is defined as I_h = I_E - μ I_N, with I_E being the energy current, μ is the chemical potential in the given lead and I_N is the particle current. Since μ is assumed to be known and I_N(t) can be calculated directly by (t)kwant with the help of the kwant.operator.Current class, the only missing part is the energy current. In a static setup, the energy current is obtained easily by an additional factor of the energy in the integrand of the Landauer-Büttiker formula (e.g. for two leads: I_E =e/h \int dE E T(E) [f_L(E)-f_R(E)] ). However for time-dependent systems, the energy is not conserved anymore which makes things more complicated. I do not want to explain how tkwant works here, since this would take too long. The basic idea is that the lesser Green's function can be expressed in terms of the time-dependent scattering states. The integration over the energy in a Landauer-Büttiker-type formula is done by an instance of the kwant.manybody.Solve class. The provided operator, e.g. kwant.operator.Current or kwant.operator.Density, tells this solver which observable is to be calculated. So far, the kwant.operators available are: - Density: 'bra_i M_i ket_i' - Current: 'bra_i H_ij ket_j - c.c. ' - Source: 'bra_i M_i H_ii ket_i - c.c. where "i" and "j" are sites, H is the Hamiltonian, M denotes an arbitrary onsite Operator (which is a matrix with dimensions given by the number of orbitals) and bra and ket are wave functions. For instance, for spin densities and spin currents, M would be the appropriate Pauli matrix (at least if spin is the only additional degree of freedom). For the purpose of time-dependent heat and energy currents we need additionally: - Energy Current: 'bra_i H_ij H_jk ket_k - c.c.' - Explicit time dependence of hopping: 'bra_i M_i dH_ij/dt ket_j + c.c.' These are of a similar shape as the operators above but different enough such that the old operators cannot be used. We already implemented them ( https://github.com/PhiReck/heatCurrent ) and tested them successfully in comparison to the analytical Keldysh-Green's function approach in the resonant level model. As far as we see, the calculation of the time-dependent wave function takes distinctly more time than the computation of the energy current (factor of >10) such that the calculation time is not really affected by the energy current. (Note that we did not only implement the operators above, but also utility functions that makes it as easy for the user to calculate particle currents in tkwant as the heat current into/from a lead.) II. A general operator module ( https://github.com/PhiReck/generalOperator ) Moreover, since the operators above all look rather similar, we generalized the operator module and discussed it already on the development mailing list. With this general operator, one is able to calculate any term of the following arbitrary form: - generalOperator: 'bra_a O1_ab O2_bc ... O25_yz ket_z +/-/0 c.c. ' Here, 'a' to 'z' denote again sites where 'z' is used as an arbitrary level of deepness (i.e., 'z' could be equal to 'b', if only one hopping is desired, or 'd' if three hoppings are wished). Moreover, On_xy are user-defined operators (if x==y, it is also an onsite operator). '+/-/0' is meant to imply that the complex conjugate can either be added subtracted or not taken into account at all, depending on what the user wants to do. In practice, we would first initialize each operator as O1 = generalOperator.Operator(syst, O1-FUNCTION, where=where_O1) O2 = generalOperator.Operator(syst, O2-FUNCTION, where=where_O2) ... with On-FUNCTION being the function that defines the operator, e.g. syst.hamiltonian or any other function that takes 1-2 sites and returns a matrix with dimensions given by the additional degrees of freedom (spin, orbitals, ...) at the sites at hand. Moreover, each operator has to know where it is to be considered/computed, specified normally as a list of hoppings (where_On). The product is achieved by prodOp = generalOperator.Op_Product(O1, O2, ..., complex_conj, const_fac) 'complex+conj' takes care of the +/-/0 option above and 'const_fac' is a constant factor which is multiplied to the result (in case of the current, it would be the imaginary unit 1j). To tell tkwant to calculate the matrix product with the wave functions as shown above, it is used the same way as for the kwant.operators: result = prodOp(bra,ket) which returns a list of results for all possible site connections. Speaking of the site connections (or as I call it: the path finding), note that now, the different where_On have to be matched: since we want to have something like "O1_ab O2_bc", we have to make sure that only hoppings in where_O1 are connected to hoppings in where_O2 which have the same site 'b' at the according position. This path finding is done automatically in the initialization of the class generalOperator.Op_Product. The path finding is the only new conceptual thing, but the user does not have to worry about it which is why I don't want to go into details here now. (There is a documentation in the git repository if someone is interested.) How to create a new operator from the generalOperator at the example of the Energy Current : This is a copy of the source code, where I omitted the check_hermiticity option and the sum option for better readability. class offEnergyCurrent: def __init__(self, syst, where1, where2): self.hamil1 = Operator(syst, syst.hamiltonian, where1) self.hamil2 = Operator(syst, syst.hamiltonian, where2) self.offEn = Op_Product(self.hamil1, self.hamil2, complex_conj=-1, const_fac=1j) def __call__(self, bra, ket=None, args=(), *, params=None): return self.offEn(bra, ket, args, params=params) Long story short: With the help of the generalOperator, it is very easy to create new operators (just define the individual operators and take the product via generalOperator.Op_Product). Before, for each operator inheriting from the kwant.operator._Localoperator, an individual "_operate" method was needed, although they are very similar in all 5 cases from above. At the moment, I am not sure if anyone ever needs to create new operators. So far, for kwant, it seems that the 3 kwant.operators have been enough (and would have been enough for our purpose of thermoelectric properties). With t-kwant however, I have the feeling that certain operators will be more complicated as compared to their time-independent counterparts as we have seen in the case of the energy current. Therefore, this general operator might be of use in the future. However, the larger universality of the general Operator comes at a price: Calculations are slower, which is mostly due to the fact that recursive functions are called for each single site combination. For the three examples of the kwant.operators, we see that the __call__ of the same operators initialized with the general operator takes roughly 3-5 times longer. This means that the general operator is not (yet?) suited to replace the 'specialized' ones, but at least it will help potential users to easily define and use new operators: they won't have to write and test an operate method in the 'old' kwant.operator._LocalOperator way. So this is the current state of progress. We hope to merge both the 'specialized' heat/energy current as well as the general operator with tkwant soon. @ Thomas: Do you see any problems or do you have any concerns about merging it with tkwant? Maybe I should have added that all the features of the kwant operators should be able to use, e.g. bind or functions for where. For instance, all the kwant examples from the tutorial also work fine with the general operator. Best regards, Phillipp Reck

3 7

Kwant 1.4 has been released
by Christoph Groth March 6, 2019

March 6, 2019

We are pleased to announce the release of Kwant 1.4, the result of a year and a half of development. Highlights of the new release: * Adding magnetic field to systems, even in complicated cases, is now specially supported. * The KPM module can now calculate conductivities. * The `Qsymm library <https://gitlab.kwant-project.org/qt/qsymm>`_ for Hamiltonian symmetry analysis has been integrated. * The handling of system parameters has been improved and optimized. * Plotting has been improved, most notably through the addition of a routine that plots densities with interpolation. * Installing Kwant on Windows is now much easier thanks to Conda packages. All these and other improvements that are detailed in the "what's new in Kwant 1.4" document [1]. The new version is practically 100% backwards-compatible with scripts written for previous versions of Kwant 1.x. The following people contributed code to this release: * Anton Akhmerov * Paul Clisson * Christoph Groth * Thomas Kloss * Bas Nijholt * Pablo Pérez Piskunow * Tómas Örn Rosdahl * Rafał Skolasiński * Dániel Varjas * Joseph Weston We would like to hear your feedback at kwant-discuss(a)kwant-project.org. [1] https://kwant-project.org/doc/1.4/pre/whatsnew/1.4

1 0