... | ... | @@ -7,15 +7,17 @@ After this, we will discuss the concrete implementation provided by Kwant, the |
|
|
|
|
|
## Preliminaries
|
|
|
|
|
|
### Low-Level Site Families
|
|
|
With the new format we will introduce the concept of a site family to the low
|
|
|
level systems. A low-level site family is simply a set of sites that have the
|
|
|
same number of orbitals associated with them. For the `kwant.builder.System`
|
|
|
implementation these *may* correspond to high-level `SiteFamily` objects,
|
|
|
but this is not a requirement. There may be more than one low-level site
|
|
|
family with the same number of orbitals. Note that this means that the
|
|
|
number of orbitals per site must be defined *a priori*, and cannot
|
|
|
be defined "on the fly" as it can now in Kwant 1.x.
|
|
|
### Site Ranges
|
|
|
|
|
|
With the new format we will introduce something similar to the concept of a
|
|
|
site family to the low level systems. A site range is simply a set of sites
|
|
|
that have the same number of orbitals associated with them (and that may also
|
|
|
be related in other ways). For the `kwant.builder.System` implementation these
|
|
|
*may* correspond to high-level `SiteFamily` objects, but this is not a
|
|
|
requirement. There may be more than one site range with the same number of
|
|
|
orbitals. Note that this means that the number of orbitals per site must be
|
|
|
defined *a priori*, and cannot be defined "on the fly" as it can now in Kwant
|
|
|
1.2.
|
|
|
|
|
|
### Sites and Site Ordering
|
|
|
The low-level format just considers sites as integers. A concrete
|
... | ... | @@ -28,15 +30,15 @@ Sites are arranged in the following way: |
|
|
indices: 0 1 2 N N+1 N+2 N+M
|
|
|
sites: [a1, a1, a3, ..., aN, b1, b2, ..., bM, ....]
|
|
|
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
|
|
|
site family "a" site family "b"
|
|
|
site range "a" site range "b"
|
|
|
|
|
|
The site families are ordered by their number of orbitals. The order of site
|
|
|
families with the same number of orbitals is not defined by the low-level
|
|
|
The site ranges are ordered by their number of orbitals. The order of site
|
|
|
ranges with the same number of orbitals is not defined by the low-level
|
|
|
interface; implementations may choose an order convenient for them. This means
|
|
|
that the low-level site families refer to a contiguous block of sites. This
|
|
|
that the low-level site ranges refer to a contiguous block of sites. This
|
|
|
choice of ordering has two advantages:
|
|
|
|
|
|
+ site families can be represented by 2 integers,
|
|
|
+ site ranges can be represented by 2 integers,
|
|
|
`(num_orbitals, first_site)`, as opposed to an integer and an
|
|
|
*array* of integers, `(num_orbitals, [site1, site2, ...])`
|
|
|
+ Slicing into quantities defined over all orbitals of the system (e.g.
|
... | ... | @@ -66,25 +68,21 @@ of the generators is raised - however this is not enough information for |
|
|
non-abelian groups.
|
|
|
|
|
|
|
|
|
### Connection Sets
|
|
|
### Connections
|
|
|
Once we have a system with sites, hoppings, and a given symmetry group we can
|
|
|
define what we will call the *connection set* of the system[1]. Informally we
|
|
|
define what we will call the *connections* of the system. Informally we
|
|
|
can define this in the following way. We take all the sites that are in the
|
|
|
fundamental domain of the symmetry group, or connected by a hopping to such
|
|
|
sites; call this set `S`. We now define the *connection set*, `C`, as the set
|
|
|
sites; call this set `S`. We now define the *connections* `C` as the set
|
|
|
of symmetry group elements that map sites from the fundamental domain to sites
|
|
|
in `S`. Note that the connection set always contains the identity (and only
|
|
|
in `S`. Note that the connections always contain the identity connection (and only
|
|
|
this element for a finite system or a completely disconnected infinite system).
|
|
|
|
|
|
Take the example of a 1D chain with nearest-neighbor hoppings, the connection
|
|
|
set is `{(0,), (1,), (-1,)}`. With second-nearest neighbor hoppings in addition
|
|
|
the connection set would be `{(0,), (1,), (-1,), (2,), (-2,)}`. For a square
|
|
|
lattice with nearest-neighbor hoppings the connection set would be `{(0, 0),
|
|
|
(1, 0), (-1, 0), (0, 1), (0, -1)}`
|
|
|
|
|
|
---------------------
|
|
|
##### Footnotes
|
|
|
[1]: This is not a very good name, hopefully a better one will be thought up
|
|
|
Take the example of a 1D chain with nearest-neighbor hoppings, the set of
|
|
|
connections is `{(0,), (1,), (-1,)}`. With second-nearest neighbor hoppings in
|
|
|
addition the connections would be `{(0,), (1,), (-1,), (2,), (-2,)}`. For a
|
|
|
square lattice with nearest-neighbor hoppings the connections would be `{(0,
|
|
|
0), (1, 0), (-1, 0), (0, 1), (0, -1)}`
|
|
|
|
|
|
|
|
|
## `System` API
|
... | ... | @@ -92,18 +90,18 @@ Here we define the low-level system API[2]. |
|
|
|
|
|
### Data members
|
|
|
|
|
|
+ `site_families`: sequence of pairs of integers, `(first_site, num_orbs)`
|
|
|
that define the grouping of sites into low-level families.
|
|
|
+ `site_ranges`: sequence of pairs of integers, `(begin_index, num_orbs)`
|
|
|
that define the grouping of sites into ranges.
|
|
|
|
|
|
+ `symmetry`: An object that knows how to simplify symmetry group elements.
|
|
|
|
|
|
+ `connection_set`: sequence of group elements. Each group element is a
|
|
|
+ `connections`: sequence of group elements. Each group element is a
|
|
|
sequence of pairs of integers, as described in the preliminary section on
|
|
|
symmetries.
|
|
|
|
|
|
+ `terms`: sequence of tuples of integers,
|
|
|
`(sym_el, fam_to, fam_from)` where `sym_el` indexes the
|
|
|
`connection_set`, `fam_to` and `fam_from` index the `site_families`.
|
|
|
`(connection, range_to, range_from)` where `connection` indexes
|
|
|
`connections`, `range_to` and `range_from` index the `site_ranges`.
|
|
|
|
|
|
### Methods
|
|
|
+ `elements`: given an index into `terms`, returns a read-only sequence
|
... | ... | @@ -112,9 +110,9 @@ On-site elements are represented by "self-hoppings" `(i, i)`. |
|
|
|
|
|
+ `hamiltonian_term`: evaluate a single term of the Hamiltonian.
|
|
|
Given an index into `terms`, and a dictionary of arguments,
|
|
|
returns an array of shape `(N, norbs_fam_to, norbs_fam_from)` where
|
|
|
returns an array of shape `(N, norbs_range_to, norbs_range_from)` where
|
|
|
`N` is the number of elements in the term and the `norbs_*`
|
|
|
are the number of orbitals in `fam_to` and `fam_from` for the term.
|
|
|
are the number of orbitals in `range_to` and `range_from` for the term.
|
|
|
|
|
|
+ `hamiltonian`: evaluate the Hamiltonian of the system. Given a sequence
|
|
|
of representations for the generators of the symmetry group of the
|
... | ... | @@ -148,7 +146,7 @@ more complicated and for questionable gain. |
|
|
The `terms` are just an arbitrary grouping of parts of the full Hamiltonian.
|
|
|
The abstract low-level system format requires that all parts of the Hamiltonian
|
|
|
grouped together into a single `term` must be associated with the same
|
|
|
symmetry group element and also with the same pair of site families.
|
|
|
symmetry group element and also with the same pair of site ranges.
|
|
|
|
|
|
Subclasses may then give further meaning to the `terms`. Finalized Builders,
|
|
|
for example, will most probably make `terms` from elements that are evaluated
|
... | ... | @@ -202,7 +200,7 @@ easier to conform to the C system API. |
|
|
|
|
|
## `kwant.builder.System` Implemetation
|
|
|
|
|
|
The low-level site families will correspond to the high-level site
|
|
|
The low-level site ranges will correspond to the high-level site
|
|
|
families[3]. The `elements` will be grouped by value: a separate
|
|
|
array of hoppings (onsites) for each value function, and a separate
|
|
|
array for constant values. The `terms` will thus refer to elements
|
... | ... | |