|
|
This document specifies a proposal for the new low-level system format in Kwant-2.
|
|
|
The requirements are:
|
|
|
+ Efficient evaluation and construction of the Hamiltonian matrix
|
|
|
+ Efficient evaluation of submatrices of the Hamiltonian (e.g. all elements which
|
|
|
have a value function which depends on time)
|
|
|
|
|
|
We will start by describing the format for a *finite* system, that is, a system with no symmetries.
|
|
|
We will then move on to *infinite* systems with symmetries.
|
|
|
We will then move on to *infinite* systems with symmetries. We will then list the operations
|
|
|
that the low-level system must efficiently support and sketch the implementation of these operations
|
|
|
given the low-level format.
|
|
|
|
|
|
## Finite Systems
|
|
|
### Site Ordering
|
... | ... | @@ -104,7 +102,7 @@ between the fundamental domain and its image under the action of the connection |
|
|
set element) are stored in the same way as for the finite system.
|
|
|
|
|
|
|
|
|
group element: g0 g1
|
|
|
group element: g1 g2
|
|
|
_______________________ _______________________
|
|
|
/ \ / \ ...
|
|
|
pair of families: fam1,fam2 fam2,fam3 ... fam1,fam2 fam2,fam3 ...
|
... | ... | @@ -117,7 +115,51 @@ set element) are stored in the same way as for the finite system. |
|
|
. .
|
|
|
. .
|
|
|
|
|
|
\______/ \______/
|
|
|
|
|
|
"blocks"
|
|
|
|
|
|
## Implementation of Common Operations
|
|
|
We can thus store the graph of the system in this way. Each combination `(g, fam1, fam2, val)` corresponds
|
|
|
to a "block" of the graph (we need to think of a better name, as this won't necessarily correspond at all
|
|
|
to a block matrix of the Hamiltonian). We store the graph as an array of ordered pairs, and we also store
|
|
|
a sequence of "blocks" which consists of `(g, fam1, fam2, val)`. `val` is either a single function or
|
|
|
a sequence of matrices, as discussed in the section on finite systems.
|
|
|
|
|
|
graph: ⎡i1, i2 ... iN, iN+1, ..., iN+M, ...⎤
|
|
|
⎣j1, j2 ... jN, jN+1, ..., jN+M, ...⎦
|
|
|
|
|
|
block offsets: [0, N, N+M, ...]
|
|
|
|
|
|
blocks: [(g1, fam1, fam2, val1), (g1, fam1, fam2, val2), ...
|
|
|
(g1, fam1, fam3, valM), ...
|
|
|
(g2, fam1, fam2, valK), ...
|
|
|
]
|
|
|
|
|
|
Is there any advantage at all in keeping the graph in a single array, as opposed to split
|
|
|
into several arrays explicitly associated with each block?.
|
|
|
|
|
|
|
|
|
## Supported Operations
|
|
|
Here we note down the various common operations that the low-level format has to efficiently support
|
|
|
and how they would be implemented with the above definition for the low-level format.
|
|
|
|
|
|
### Calculating band structure
|
|
|
This requires evaluating the full Hamiltonian matrices associated with *each* of the elements
|
|
|
of the connection set, and then solving an eigenvalue equation like:
|
|
|
|
|
|
[H + V_0 exp(i k_x x) + V_1 exp(i k_y x) + ... + h.c] u = E u
|
|
|
|
|
|
### Evaluating all elements which depend on some parameter (e.g. time)
|
|
|
Iterate over the blocks, inspect the `value`, if the `value` takes a parameter with the correct
|
|
|
name we add the block index to a list of block indices. We can cache this list of block indices.
|
|
|
Whenever we want to evaluate the part of the Hamiltonian which depends on parameter X we have just
|
|
|
to evaluate the blocks which we cached.
|
|
|
|
|
|
### Application of the Hamiltonian to a vector
|
|
|
To be written.
|
|
|
|
|
|
### Obtaining a submatrix between user-defined sites
|
|
|
This is just the current behaviour of `hamiltonian_submatrix`. This is not easy with the above format.
|
|
|
If the sites of the submatrix are known before finalization then the user can define a site family
|
|
|
that contains the sites for which they wish to extract a submatrix. As the sites are ordered by
|
|
|
site family, this enables efficient construction of the submatrix. |