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 i-th 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> wrote:
Dear Christoph,

Maybe it is not exactly what you had in mind, but I use the low-level
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 low-level 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 quasi-1-d leads attached to quasi-0-d  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
> backwards-incompatible (but well documented) way”.
>
> I believe that there is virtually no one who uses the low level system
> interface [1] directly in non-trivial 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
> low-level 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 low-level 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://kwant-project.org/doc/1/reference/kwant.system