How strict should we take backwards compatibility?
Dear all,
With Kwant, we strive to keep backwards compatibility across major versions: a script that only uses the documented API and works with Kwant 1.x should continue to work unchanged with Kwant 1.y, for any y >= x.
Still, we have a bunch of ideas that require breaking strict compatibility. That’s why they have been going under “Kwant 2”:
• A new lowlevel system format that supports more general symmetries and vectorization of value functions.
• Composite systems that combine systems with various degrees of commensurate symmetries in a general way. (That’s a generalization of quasi1d leads attached to quasi0d scattering regions that we have now.)
• Various small changes and fixes to the interface.
These things pull in other changes (e.g. in the solvers) which means that “Kwant 2” is quite a big project.
Recently, I asked myself whether we really have to interpret backwards compatibility in such a strict way. Perhaps a better way would be “if it does not hurt >98% of the users, it’s OK to change things in a backwardsincompatible (but well documented) way”.
I believe that there is virtually no one who uses the low level system interface [1] directly in nontrivial ways (e.g. doing something with system.graph and not just calling system.hamiltonian_submatrix() for a finite system). Is this actually true? Can people who do things with lowlevel systems directly please chime in and tell us what their most involved usage cases are?
If it turns out that a weak interpretation of backwards compatibility is indeed OK, we could tackle the new lowlevel system format already for Kwant 1.3. This would make the development of Kwant more evolutionary and should make it more dynamic.
What do you think?
Christoph
Dear Christoph,
Maybe it is not exactly what you had in mind, but I use the lowlevel system interface to average a wavefunction over a site and its neigbors. This requires the functions syst.graph.num_nodes and syst.graph.out_neighbors, both of which are also used in plotter.py, to iterate over all sites within the graph and to directly access the neighbors of any given site. It seems to me that it should be rather easy to use similar functions within a new system interface (if anything will change for them at all), but I might be wrong there. I hope that this information is helpful to you.
Best regards, Koen Reijnders
On 01/04/16 18:07, Christoph Groth wrote:
Dear all,
With Kwant, we strive to keep backwards compatibility across major versions: a script that only uses the documented API and works with Kwant 1.x should continue to work unchanged with Kwant 1.y, for any y
= x.
Still, we have a bunch of ideas that require breaking strict compatibility. That’s why they have been going under “Kwant 2”:
• A new lowlevel system format that supports more general symmetries and vectorization of value functions.
• Composite systems that combine systems with various degrees of commensurate symmetries in a general way. (That’s a generalization of quasi1d leads attached to quasi0d scattering regions that we have now.)
• Various small changes and fixes to the interface.
These things pull in other changes (e.g. in the solvers) which means that “Kwant 2” is quite a big project.
Recently, I asked myself whether we really have to interpret backwards compatibility in such a strict way. Perhaps a better way would be “if it does not hurt >98% of the users, it’s OK to change things in a backwardsincompatible (but well documented) way”.
I believe that there is virtually no one who uses the low level system interface [1] directly in nontrivial ways (e.g. doing something with system.graph and not just calling system.hamiltonian_submatrix() for a finite system). Is this actually true? Can people who do things with lowlevel systems directly please chime in and tell us what their most involved usage cases are?
If it turns out that a weak interpretation of backwards compatibility is indeed OK, we could tackle the new lowlevel system format already for Kwant 1.3. This would make the development of Kwant more evolutionary and should make it more dynamic.
What do you think?
Christoph
Dear Koen,
Thanks a lot, that is exactly what we need to know! Your scripts would indeed be influenced by the change. If you don't mind, we would appreciate if you could share the relevant code. Do you use it on a square lattice or something more complicated?
Best, Anton
On Wed, Jan 6, 2016, 15:39 Koen Reijnders K.Reijnders@science.ru.nl wrote:
Dear Christoph,
Maybe it is not exactly what you had in mind, but I use the lowlevel system interface to average a wavefunction over a site and its neigbors. This requires the functions syst.graph.num_nodes and syst.graph.out_neighbors, both of which are also used in plotter.py, to iterate over all sites within the graph and to directly access the neighbors of any given site. It seems to me that it should be rather easy to use similar functions within a new system interface (if anything will change for them at all), but I might be wrong there. I hope that this information is helpful to you.
Best regards, Koen Reijnders
On 01/04/16 18:07, Christoph Groth wrote:
Dear all,
With Kwant, we strive to keep backwards compatibility across major versions: a script that only uses the documented API and works with Kwant 1.x should continue to work unchanged with Kwant 1.y, for any y
= x.
Still, we have a bunch of ideas that require breaking strict compatibility. That’s why they have been going under “Kwant 2”:
• A new lowlevel system format that supports more general symmetries and vectorization of value functions.
• Composite systems that combine systems with various degrees of commensurate symmetries in a general way. (That’s a generalization of quasi1d leads attached to quasi0d scattering regions that we have now.)
• Various small changes and fixes to the interface.
These things pull in other changes (e.g. in the solvers) which means that “Kwant 2” is quite a big project.
Recently, I asked myself whether we really have to interpret backwards compatibility in such a strict way. Perhaps a better way would be “if it does not hurt >98% of the users, it’s OK to change things in a backwardsincompatible (but well documented) way”.
I believe that there is virtually no one who uses the low level system interface [1] directly in nontrivial ways (e.g. doing something with system.graph and not just calling system.hamiltonian_submatrix() for a finite system). Is this actually true? Can people who do things with lowlevel systems directly please chime in and tell us what their most involved usage cases are?
If it turns out that a weak interpretation of backwards compatibility is indeed OK, we could tackle the new lowlevel system format already for Kwant 1.3. This would make the development of Kwant more evolutionary and should make it more dynamic.
What do you think?
Christoph
Anton Akhmerov wrote:
Thanks a lot, that is exactly what we need to know! Your scripts would indeed be influenced by the change.
Well, we will most likely provide syst.graph.num_nodes, and it might be actually possible to have syst.graph.out_neighbors with reasonable (log) efficency as well.
Dear Anton and Christoph,
Sure, no problem. I use my code for graphene systems, not for square lattices, which makes it a bit more complicated. Please find a code snippet below. I typically call my function as average_wavefunction(syst, (abs(wavefuncSyst)**2)[modeNumber,:]), where wavefuncSyst is the output of kwant.wave_function for a given lead, i.e. something like kwant.wave_function(syst, energy=0.1)(0) . By the way, just for curiosity, it is easy to say what the current efficiency of syst.graph.out_neighbors is? Or is it more or less instantaneous?
Just to give you a complete picture, after the averaging, I usually write the averaged wavefunction to a file together with the coordinates of the system, which I extract using the function extract_site_coords below (inspired by the code in kwant.plotter). After that, I plot it using a different program. For this output step it is rather essential that the element i of the output of kwant.wave_function has a position that corresponds to syst.pos(i), or that there is some other easy way of determining the position of the site corresponding to the ith element in the output of kwant.wave_function. I guess that this will more or less stay the same, or do you also plan to change a couple of things there?
Best regards, Koen

def average_wavefunction(syst, wavefunc):
avgData=numpy.zeros(syst.graph.num_nodes) for i in xrange(syst.graph.num_nodes): avgData[i]=numpy.add(avgData[i],wavefunc[i]/2.0) for j in syst.graph.out_neighbors(i): avgData[j]=numpy.add(avgData[j],wavefunc[i]/6.0)
return avgData

def extract_site_coords(syst):
# code inspired by the code in kwant.plotter pos = numpy.array(tinyarray.array([syst.pos(i) for i in xrange(syst.graph.num_nodes)]))
return pos

Combining everything in main(), it more or less looks like this:
wavefunc = kwant.wave_function(syst,energy=En)(0) posData = extract_site_coords(syst) for i in xrange(0,noModes): avgDataMode = average_wavefunction(syst, (abs(wavefunc)**2)[i,:]) write_wavefunction(numpy.concatenate((posData,numpy.array([avgDataMode]).T), axis=1), 'wavefunctionAvg_Mode' + str(i) + '.dat')

On 01/06/16 17:14, Anton Akhmerov wrote:
Dear Koen,
Thanks a lot, that is exactly what we need to know! Your scripts would indeed be influenced by the change.
If you don't mind, we would appreciate if you could share the relevant code. Do you use it on a square lattice or something more complicated?
Best, Anton
On Wed, Jan 6, 2016, 15:39 Koen Reijnders <K.Reijnders@science.ru.nl mailto:K.Reijnders@science.ru.nl> wrote:
Dear Christoph, Maybe it is not exactly what you had in mind, but I use the lowlevel system interface to average a wavefunction over a site and its neigbors. This requires the functions syst.graph.num_nodes and syst.graph.out_neighbors, both of which are also used in plotter.py, to iterate over all sites within the graph and to directly access the neighbors of any given site. It seems to me that it should be rather easy to use similar functions within a new system interface (if anything will change for them at all), but I might be wrong there. I hope that this information is helpful to you. Best regards, Koen Reijnders On 01/04/16 18:07, Christoph Groth wrote: > Dear all, > > With Kwant, we strive to keep backwards compatibility across major > versions: a script that only uses the documented API and works with > Kwant 1.x should continue to work unchanged with Kwant 1.y, for any y > >= x. > > Still, we have a bunch of ideas that require breaking strict > compatibility. That’s why they have been going under “Kwant 2”: > > • A new lowlevel system format that supports more general symmetries > and vectorization of value functions. > > • Composite systems that combine systems with various degrees of > commensurate symmetries in a general way. (That’s a generalization > of quasi1d leads attached to quasi0d scattering regions that we > have now.) > > • Various small changes and fixes to the interface. > > These things pull in other changes (e.g. in the solvers) which means > that “Kwant 2” is quite a big project. > > Recently, I asked myself whether we really have to interpret backwards > compatibility in such a strict way. Perhaps a better way would be “if > it does not hurt >98% of the users, it’s OK to change things in a > backwardsincompatible (but well documented) way”. > > I believe that there is virtually no one who uses the low level system > interface [1] directly in nontrivial ways (e.g. doing something with > system.graph and not just calling system.hamiltonian_submatrix() for a > finite system). Is this actually true? Can people who do things with > lowlevel systems directly please chime in and tell us what their most > involved usage cases are? > > If it turns out that a weak interpretation of backwards compatibility > is indeed OK, we could tackle the new lowlevel system format already > for Kwant 1.3. This would make the development of Kwant more > evolutionary and should make it more dynamic. > > What do you think? > > Christoph > > [1] http://kwantproject.org/doc/1/reference/kwant.system
Koen Reijnders wrote:
By the way, just for curiosity, it is easy to say what the current efficiency of syst.graph.out_neighbors is? Or is it more or less instantaneous?
Currently it’s very fast, just a few lookups in integer tables that are done in Cython. The time it takes does not depend on the size of the graph.
For this output step it is rather essential that the element i of the output of kwant.wave_function has a position that corresponds to syst.pos(i), or that there is some other easy way of determining the position of the site corresponding to the ith element in the output of kwant.wave_function.
I guess that this will more or less stay the same, or do you also plan to change a couple of things there?
Of course It will remain possible to map the wave function to spatial positions. We actually plan to improve the support for working with results (e.g. wave function) that are functions of space. Right now this is not one of the strongest parts of Kwant.
Koen, thanks for your feedback.
Christoph
participants (3)

Anton Akhmerov

Christoph Groth

Koen Reijnders