# What’s new in Kwant 1.0#

This article explains the new features in Kwant 1.0 compared to Kwant 0.2. Kwant 1.0 was released on 9 September 2013. Please consult the full list of changes in Kwant for all the changes up to the most recent bugfix release.

## Lattice and shape improvements#

Lattices now have a method `neighbors`

,
which calculates all the n-th shortest possible hoppings on this lattice. This
replaces the `nearest`

attribute that some lattices used to have.

`shape`

uses an improved flood-fill algorithm, making
it work better on narrow ribbons (which were sometimes buggy before with
non-square lattices). Additionally, it was made symmetry-aware: If
`shape`

is used with a lead, the shape does not have
to be limited along the lead direction anymore. In fact, if the shape function
does not have the same symmetry as the lead, the result may be unexpected, so
it is highly recommended to use shape functions that have the same symmetry as
the lead.

`closest`

now returns an exact, and not approximate
closest point. A new method `n_closest`

was added,
which returns the n closest lattice points.

`possible_hoppings`

replaced by `HoppingKind`

#

The `Builder`

method `possible_hoppings`

has been rendered
obsolete. Where previously one would have had

```
for kind in lat.nearest:
syst[syst.possible_hoppings(*kind)] = t
```

now it suffices to write

```
syst[lat.neighbors()] = t
```

This is possible because `Builder`

now accepts *functions* as
keys in addition to `Site`

objects and tuples of them
(hoppings). These functions are expected to yield either sites or hoppings,
when given a builder instance as the sole argument. The use of such keys is to
implement sets of sites or hoppings that depend on what is already present in
the builder, such as `HoppingKind`

. In the above example,
`lat.neighbors()`

is a list of `HoppingKind`

objects.

## Some renames#

site groups are now called site families. This affects all the names that used to contain “group” or “groups”.

lead slices are now referred to as lead cells: This affects all names that used to contain “slice” or “slices” in the context of leads.

`self_energy`

has been renamed to`selfenergy`

in all cases, most notably in`kwant.physics.selfenergy`

.`wave_func`

has been renamed to`wave_function`

,`MonatomicLattice`

has been renamed to`Monatomic`

,`PolyatomicLattice`

has been renamed to`Polyatomic`

.`solve`

was split into two functions:`smatrix`

, and`greens_function`

. The former calculates the scattering matrix, the latter the retarded Green’s function between the sites adjacent to the leads. It is temporarily not possible to mix self-energy and modes leads within the same system.The object that contained the results,

`BlockResult`

was also split into`SMatrix`

and`GreensFunction`

.

## Band structure plots#

A convenience function `bands`

for quick plotting of band
structure was implemented.

## Immutable site families#

In order to make naming more consistent, `kwant.make_lattice`

was renamed and
can be found now as `kwant.lattice.general`

. Classes `Chain`

, `Square`

,
and `Honeycomb`

from `lattice`

were made functions
`chain`

, `square`

, and
`honeycomb`

.

In previous versions if one executed ```
a = kwant.lattice.square(); b =
kwant.lattice.square()
```

then `a`

and `b`

were actually different
lattices. This often led to confusions in more convoluted use cases, so this
behavior was changed. Now two site families created with the same parameters
are actually indistinguishable by Kwant. If it is desired to make two site
families which have the same geometry, but mean different things, as for
instance in Superconductors: orbital degrees of freedom, conservation laws and symmetries, then the `name`

argument has to
be used when creating a lattice, e.g. ```
a = kwant.lattice.square(name='a'); b =
kwant.lattice.square(name='b')
```

.

## Parameters to Hamiltonian#

Kwant now allows the Hamiltonian matrix elements to be described with functions that depend on an arbitrary number of parameters in addition to the sites on which they are defined.

Previously, functions defining the Hamiltonian matrix elements had to have the following prototypes:

```
def onsite(site):
...
def hopping(site1, site2):
...
```

If the Hamiltonian elements need to depend on some other external parameters (e.g. magnetic field) then those had to be provided by some other means than regular function parameters (e.g. global variables).

Now the value functions may accept arbitrary arguments after the *Site*
arguments. These extra arguments can be specified when
`smatrix`

is called by setting the arguments:

- args
A tuple of values to be passed as the positional arguments to the Hamiltonian value functions (not including the

*Site*arguments).

For example, if the hopping and onsite Hamiltonian value functions have the following prototype:

```
def onsite(site, t, B, pot):
...
def hopping(site1, site2, t, B, pot):
...
```

then the values of `t`

, `B`

and `pot`

for which to solve the system can be
passed to `smatrix`

like this:

```
kwant.smatrix(syst, energy,
args=(2., 3., 4.))
```

With many parameters it can be less error-prone to collect all of them into a single object and pass this object as the single argument. Such a parameter collection could be a dictionary, or a class instance, for example:

```
class SimpleNamespace(object):
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
# With Python >= 3.3 we can have instead:
# from types import SimpleNamespace
def onsite(site, p):
return p.mu * ...
def hopping(site1, site2, p):
return p.t * exp(-1j * p.B * ...)
params = SimpleNamespace(t=1, mu=2)
for params.B in B_values:
kwant.smatrix(syst, energy, args=[params])
```

Arguments can be passed in an equivalent way to
`wave_function`

,
`hamiltonian_submatrix`

, etc.

## Calculation of modes separated from solving#

The interface that solvers expect from leads attached to a
`FiniteSystem`

has been simplified and codified (see there).
Similar to self-energy, calculation of modes is now the lead’s own
responsibility.

The new class `ModesLead`

allows to attach leads that have a
custom way of calculating their modes (e.g. ideal leads) directly to a
`Builder`

.

Modes or self-energies can now be precomputed before passing the system to a
solver, using the method `precalculate`

. This may
save time, when the linear system has to be solved many times with the same
lead parameters.

## Change of the modes and lead_info format#

The function `modes`

now returns two objects:
`PropagatingModes`

and `StabilizedModes`

. The
first one contains the wave functions of all the propagating modes in real
space, as well as their velocities and momenta. All these quantities were
previously not directly available. The second object contains the propagating
and evanescent modes in the compressed format expected by the sparse solver
(previously this was the sole output of `modes`

). Accordingly,
the `lead_info`

attribute of `SMatrix`

contains the
real space information about the modes in the leads (a list of
`PropagatingModes`

objects).

## New module for random-access random numbers#

The module `kwant.digest`

provides functions that given some input compute a
“random” output that depends on the input in a (cryptographically) intractable
way. This functionality is useful for introducing disorder, e.g.:

```
def onsite(site):
return 0.3 * kwant.digest.gauss(repr(site)) + 4
```

## New module for random matrix theory Hamiltonians#

The module `kwant.rmt`

supports the creation of random matrix theory
Hamiltonians.

## Improved plotting functionality#

The plotting functionality has been extended. By default, symbols and lines in plots are now relative to the system coordinates, i.e. will scale accordingly if different zoom-levels are used. Different styles for representing sites and hoppings are now possible. 3D plotting has been made more efficient.