... | ... | @@ -131,8 +131,27 @@ matrix, or a sparse matrix in COO format. |
|
|
|
|
|
### Discussion
|
|
|
|
|
|
#### More general class of systems
|
|
|
Would it be useful to have a more general class of systems that that only
|
|
|
knows how to "act" on a wavefunction? The same question for the symmetries.
|
|
|
|
|
|
#### Calculating band structure
|
|
|
Write this
|
|
|
Formally we need to solve an infinite eigenvalue problem. In practice
|
|
|
we use the symmetry of the system to "fold" the problem into the fundamental
|
|
|
domain. The finite eigenvalue problem to solve is then:
|
|
|
|
|
|
[∑ ∑[Uₐ(kₐ)]ⁿ Hₐₙ ] u(k̲) = E(k̲) u(k̲)
|
|
|
a nₐ
|
|
|
|
|
|
where the first sum is over the symmetry generators, the second sum is over
|
|
|
the cycle length of the generator. `Uₐ(kₐ)` is the `GL(ℂ, N)` representation
|
|
|
of one of the symmetry group generators, `-π ≤ kₐ ≤ π` is the associated
|
|
|
momentum, `k̲` is a vector of all the momenta. `Hₐₙ` is the Hamiltonian
|
|
|
matrix linking the fundamental domain to the nth domain in the direction
|
|
|
of the generator `a`. For any reasonable system all the `Hₐₙ` are 0 for `n`
|
|
|
larger than a certain value (usually 1 or 2).
|
|
|
|
|
|
|
|
|
|
|
|
#### Recursive Greens Function
|
|
|
Write this
|
... | ... | @@ -140,8 +159,8 @@ Write this |
|
|
---------------------
|
|
|
##### Footnotes
|
|
|
|
|
|
[3]: We should probably define everything as arrays straight away to make it easier to
|
|
|
conform to the C system API.
|
|
|
[3]: We should probably define everything as arrays straight away to make it
|
|
|
easier to conform to the C system API.
|
|
|
|
|
|
|
|
|
|
... | ... | @@ -155,21 +174,32 @@ that can be efficiently evaluated by a vectorized value function. |
|
|
|
|
|
### Data members
|
|
|
|
|
|
+ `sites`: sequence of `builder.Site` objects, the sites in the system
|
|
|
+ `site_arrays`: sequence of `builder.SiteArray` objects, one per high-level
|
|
|
site family. The tags in the `SiteArray` are ordered lexicographically.
|
|
|
This is more efficient than storing a sequence of sites (site family
|
|
|
is only stored once).
|
|
|
|
|
|
+ `site_values`: a sequence of the same length as `site_families`. Contains
|
|
|
either a callable or an array of shape `(N, norbs_fam, norbs_fam)`.
|
|
|
+ `sites`: A property which behaves like a sequence of `Site`s. The
|
|
|
`Site`s are ordered in the same way as the low-level format; by
|
|
|
site family and then lexicographically by tag. The implementation
|
|
|
just looks up tags in `site_arrays`.
|
|
|
|
|
|
+ `values`: a sequence of the same length as `blocks`. Contains either
|
|
|
a callable or an array. The array has shape
|
|
|
`(N, norbs_fam, norbs_fam)` if the `block` refers to `elements` that
|
|
|
are onsites, or `(N, norbs_fam_to, norbs_fam_from)` if the block
|
|
|
refers to `elements` that are hoppings[5].
|
|
|
a callable or an array. If it is an array, it has shape
|
|
|
`(N, norbs_fam_to, norbs_fam_from)` where `N` is the length of the
|
|
|
`elements` pointed to by the corresponding `block`. If it is a
|
|
|
callable, then the first argument is a `Site` (or `SiteArray`
|
|
|
for vectorized value functions, see below). If the `elements`
|
|
|
are hoppings (i.e `site_to != site_from`) then the the second
|
|
|
argument is also a `Site`. This means we also need to either
|
|
|
explicitly store whether a particular sequence of `elements`
|
|
|
is onsites/hoppings, or check if the first pair has
|
|
|
`site_to == site_from` or not[5].
|
|
|
|
|
|
### Evaluating Hamiltonian Blocks
|
|
|
If a block has a corresponding `value` that is an array, return the array.
|
|
|
Otherwise, if the callable has an attribute `__vectorized__` then it
|
|
|
is called once with `SiteArray` as its first (and second, for hoppings)
|
|
|
Otherwise, if the callable `value` has an attribute `__vectorized__` then it
|
|
|
is called once with a `SiteArray` as its first (and second, for hoppings)
|
|
|
argument. If the callable is not vectorized then it is called once for
|
|
|
each element in the block's `els`. If the block has the `conjugate` flag
|
|
|
set then the Hermitian conjugate of each value is calculated, and this
|
... | ... | @@ -187,11 +217,10 @@ re-definition of the low-level interface. |
|
|
|
|
|
|
|
|
## C `System` API
|
|
|
Here we define the C low-level system API. Systems implemented in C must conform
|
|
|
to this interface. Solvers implemented in C may rely on this interface.
|
|
|
Here we define the C low-level system API. Systems implemented in C must
|
|
|
conform to this interface. Solvers implemented in C may rely on this interface.
|
|
|
|
|
|
```C
|
|
|
|
|
|
typedef uint32_t uint_t; // may be any suitably large unsigned integer
|
|
|
typedef double complex complex_t ;
|
|
|
|
... | ... | @@ -199,7 +228,7 @@ struct Symmetry_t { |
|
|
|
|
|
uint_t num_directions ;
|
|
|
|
|
|
// get a representation of a group element in GL(C, N)
|
|
|
// get a representation of a group element in GL(ℂ, N)
|
|
|
// this representation can be used to act on wavefunctions
|
|
|
// returns a representation as a dense matrix
|
|
|
void (*get_dense_representation)(
|
... | ... | @@ -208,7 +237,7 @@ struct Symmetry_t { |
|
|
uint_t N,
|
|
|
complex_t* out) ;
|
|
|
|
|
|
// get a representation of a group element in GL(C, N)
|
|
|
// get a representation of a group element in GL(ℂ, N)
|
|
|
// this representation can be used to act on wavefunctions
|
|
|
// returns a representation as a sparse COO matrix
|
|
|
void (*get_sparse_representation)(
|
... | ... | @@ -272,10 +301,9 @@ struct CSystem_t { |
|
|
### Discussion
|
|
|
|
|
|
#### Array Format
|
|
|
Most of the arrays are arrays of some "composite" type and hence are "2D arrays".
|
|
|
Maybe instead we should have a `struct` for each one, e.g.:
|
|
|
Most of the arrays are arrays of some "composite" type and hence are "2D
|
|
|
arrays". Maybe instead we should have a `struct` for each one, e.g.:
|
|
|
```C
|
|
|
|
|
|
struct SiteFamily_t {
|
|
|
uint_t first_site, n_orbitals ;
|
|
|
} ;
|
... | ... | |