Re: [Kwant-devel] Ideas about Kwant Symmetry API
Hi Christoph, I'll try to address all of your questions. I discuss some more issues in my reply to your old email on the topic. Correct me if I’m wrong but it seems to me that a good representation of > the spatial part would be rational matrices like the ones returned by > > http://www.cryst.ehu.es/cgi-bin/plane/programs/nph-plane_get > gen?gnum=4=plane=table > > for the plane group “pg”. > > Is this what you propose? > Yes, my idea was this. This may not be the most efficient, but it is quite transparent in my opinion. > > 2. Internal/gauge part >> > > Is there a theorem that states that the combination of a unitary matrix > with optional complex conjugation and optional antisymmetry is all that one > needs to cover “all” (however defined) symmetries? These cover almost all possible symmetries of a time-independent system of free particles I can think of, but I'm not aware of any theorem about this. One other thing we could think of are continuous on-site symmetries, like SU(2) spin rotations, these could be implemented using the group generators. Continuous symmetries like this are always on-site and can be decoupled from any spatial symmetry (i.e. every symmetry operation is a product of an on-site continuous symmetry and a spatial symmetry). > > > ### Generating the group >> All these discrete groups are finitely generarated. We can split off the >> pure lattice translation part, and generate the finite point group part as >> a quotient. This works in a brute force way (generate products up to a >> certain length), or we can think of something smarter. Storing the >> operators in the above linear representation form has the advantage of >> taking products is quite straightforward. We may need to worry about >> numerical accuracy when deciding equivalence of operators in this >> representation, but it shouldn't be a big problem. >> > > I wonder if it’s not better to store the group elements not as real-space > transformation matrices (that are subject to numerical error), but rather > as “skewed” matrices filled with rational numbers that can be processed > exactly. It seems to me that the real-space transformation matrices can be > recovered from the exact ones by means of a coordinate transformation. If you think of storing the matrices in the basis of the primitive lattice vectors (such that all rotations are invertible integer matrices) sounds like a good idea. On the other hand, it is not very intuitive, we'll have to provide an interface to transform at a higher level. We should figure out whether we can treat the internal parts of the symmetries in a symbolic way as well. It seems somewhat more complicated, think of a pi/6 spin rotation for example. These usually still have closed forms in terms of exponential/trigonometric functions, maybe we could use sympy to treat them exactly? > > If we want to implement the full list of space groups we could fetch >> crystallographic tables from http://www.cryst.ehu.es/ for example, there >> is plain-text interface to basic data, like the group elements (only the >> real spce part) for all space groups. >> > > Isn’t there any public library for doing this? It’s all maths after all, > so it should not be necessary to consult online databases. I found a paper > that outlines methods to generate such data. ( > http://www.intechopen.com/books/recent-advances-in-crystall > ography/unique-and-effective-characterization-of-space-group > s-in-computer-applications) > > The attached Python script is based on the code on page 21 (or 264) of the > above paper. It generates what seem to be all the matrices that are needed > to generate all the point groups in space. The script demonstrates that > cubing a matrix that corresponds to 1/3-rotation results in a unity matrix. Yes, we could generate the space groups ourselves. This code system looks a bit over the top for me, it's just an obfuscated way of storing 3*3 matrices of trits (1,0,-1) in a single integer. If we want to automate more fancy representation theory (like representations of nonsymmorphic space groups at high symmetry points of the BZ) it could be necessary to consult online databases as generating these tables seems rather cumbersome. First we probably just should implement generating representations and characters, which is quite straightforward, and leave it to the user to consult the appropriate database to find out what it corresponds to. > > ### Storing the lattice >> > > 1. Lattice sites should be grouped in symmetry related families. >> > > Can you elaborate on what you mean? Do you mean “families” in the sense > of Kwant’s site families? Or rather as an abstract concept? When you speak > of sites here, do you mean the sites that belong to the fundamental domain > (or translational unit cell) of the symmetry, or rather the sites that make > up a complete Kwant system? I'm sorry, I'm not familiar yet with the kwant lingo. I mean that the sublattices (which have exactly
Re: [Kwant-devel] Symmetries
Hi Christoph, Here are my comments to your old email. I see what you mean: calculations are done with matrices that only have the > translational symmetries left. So what’s the point in solvers knowing > anything about non-translational symmetries? First of all, it makes sense to define a calculation as “calculate the band > structure / Green’s function for this model” and not just “calculate the > band energies for a given k”. To do the former efficiently, an > understanding of non-rotational symmetries is needed. That understanding > must be on the level of the solver, and the low-level format should provide > everything that a solver needs to know. > One could then argue: Why not only _declare_ the symmetry, without > actually storing the system in a way that takes advantage of it? I think > that a storage format that utilizes symmetry offers increased robustness. > There is less potential for error when some important properties of a > system are known to be true by construction. Just like a quasi-1-d lead in > current Kwant (=InfiniteSystem) is always periodic as declared. I agree, we can't get around solving Hamiltonians of the size of the translational unit cell. The root reason for this is, for translationally invariant systems we need to use k as a quantum number, and aside from a measure zero part of the Brillouin-zone k is not invariant under a given space group (SG) symmetry. The gain comes from only having to solve for the fundamental domain of k-space, which is often called "irreducible wedge", as it is usually a wedge-like shape with its point at the gamma point. > > There’s one more aspect: when the Hamiltonian is invariant under a spatial > symmetry, the bands have degeneracies at special high-symmetry values of k. > While it’s true that these degeneracies occur only exactly for a subspace > of the reciprocal space that has measure zero (that’s actually a > re-phrasing of what you said above), it’s also true that the whole > “topology” of the band structure gets modified by these degeneracies. We > might be able, who knows, to somehow exploit their existence. Perhaps the > Hamiltonian can be simplified in the vicinity of a special k point? Perhaps > we can do some automatic analysis of the band structure? In any way, to do > this it’s necessary that the full symmetry is present in a machine-readable > way. I also think it would be useful to automate symmetry analysis at high symmetry k-points. This could result in some speedup in the diagonalization, if we utilize the block-diagonal structure enforced by the symmetries. While this may not be a significant gain in speed when calculating the entire band-structure, these high symmetry points come up quite often during analysis and would make sense to implement this at the level of the solver rather than doing post-processing (like diagonalizing degenerate bands with respect to some symmetry) at a higher level. Let me now briefly sketch how I imagine that symmetries would work in low-level systems. > > Let’s consider a general space group G with a translational subgroup T. T > is always Abelian and typically consists of infinitely many elements that > can be indexed by a vector of integers, but it could be also the trivial > group with a single element 1 (when there’s no translational symmetry). We assume that T is a “normal subgroup” of G. That means that gT = Tg, i.e. > left and right cosets of T are the same. T is normal for all space groups. > (I cannot think of any useful application where T would be not normal – but > then I cannot think of any application where G is not some space group.) The cosets of T behave as a group, i.e. g_1 T g_2 T = g_1 g_2 T. That group > (whose elements are the cosets of T) is denoted G/T – a factor group of G. Each coset of T has infinitely many elements, but we can specify it by a > single representative. (All the other members of the coset can be generated > from the representative by applying pure translations to it.) To describe the group in a very useful way, it is enough to store exactly > one representative for each coset of T. The representatives are chosen in a > unique way, such that they only contain translations by less than one > primitive cell (and only in positive direction). Such sub-unit-cell > translations are necessary to describe space groups that contain “screw > axes” and “glide planes”. Any element of the full group G can now be described uniquely by a single > representative of a coset and a translation. I fully agree with your analysis, this is the most transparent way of thinking of space groups in my opinion. > This allows us to describe the full system by only specifying the > Hamiltonian for a fundamental domain and the space group G. Each hopping is > associated with an element of G. One subtle issue is that some bits of the > Hamiltonian correspond to sites that lie on “Wyckoff positions”, that is > special points that are kept invariant by
Re: [Kwant-devel] Symmetries
Hi Everyone,
After long discussions with Joe and Michael I got a way better idea about
what the low level system is, and how it's supposed to work. My first
reaction was, the level of abstraction we want to maintain, such as not
storing any of the spatial structure of the system, will make representing
space group symmetries very cumbersome. But after much thought, I now think
this is a good idea and can be done without extreme difficulty. I will
sketch my thoughts of the necessary information, mathematical structure and
the rationale behind this structure without too much thought to the details
of the implementation, I'll leave that to those who are better versed in
programming.
(1) Necessary information about the full symmetry group G:
(a) A format to store the group elements and a product rule of the group.
For abelian normal subgroups it would suffice to declare the generators and
their order (which may be infinite), for the noncommutative rest we could
explicitly store the group elements. I'm not sure it's wise to hard code
the integer matrix-vector representation, it definitely works for the
spatial part of space groups, but I'm not sure it's sufficient to store
more subtle cases. I'm thinking of, for example, systems with translation
invariance but finite periodic boundary conditions, like a square lattice
rolled up into a cylinder or torus. I think we should be able to treat such
systems on the same footing as infinite translation invariant systems,
which would be possible, for example, by modifying the product rule for
translations by taking sums of translations modulo the periodic size of the
system. Note that at this level of abstractions the only information about
the spatial action of a given symmetry (e.g. a rotation) is encoded in the
way it commutes with the pure translations, the abstract product rule is
all we need. There is also an internal Hilbert space transformation part
(see next point), we can hard code this to have a product rule of
(anti)linear operators, as all of what we do in the end is acting on
Hilbert spaces.
(b) For any group element g in G and every site i in FD(G) (the fundamental
domain of G) we need the following information:
(i) Is site i invariant under g? This we need to know, when we later want
to construct larger patches of the system by applying the symmetries.
Without any information about the actual spatial structure, we have to
externally supply this information, so we know whether we need to create a
duplicate of the site. We will later need the subgroup of G that leaves
site i invariant which follows from this, P(i) = {g in G such that g leaves
i invariant}. For space groups this is the "point group of site i", but
let's leave this general.
(ii) The internal Hilbert space transformation U(i,g). Here I think we
should allow for antilinear and antisymmetry operations as well (it's only
two booleans) to incorporate TR, magnetic and PH symmetries. This also
leaves the format open to continuous on-site symmetries (e.g. spin
rotations), such symmetry would leave all the sites invariant and we could
store only the generators here (like i\sigma_j for spin rotations) and
leave it to later implementations of the solver to catch such symmetries
and apply appropriate simplifications.
(2) Information about the Hamiltonian:
(a) We can go with the format that was proposed earlier, a term in the
hamiltonian (e.g. hopping) is specified as h(i,j,g) where i, j in FD(G) and
g in G, this is a hopping between i and g(j).
(b) Checks about the compatibility of h(i,j,g) with the symmetry G can be
carried out using information in (1).
(3) Simplifying the problem using an abelian normal subgroup of G, T.
We usually think of T as the translation subgroup, but it can be different,
for example in a finite square quantum dot it can be the group of 4-fold
rotations. Or in a square quantum wire it can be {translations along the
wire} X {fourfold rotations}. The use of T has the advantage, that we only
need to solve a problem of the size of FD(T) at a time, at the cost that we
need to solve it many times. This we must do if T is an infinite group (we
can't solve infinite systems) but is optional for finite groups (or finite
subgroups). For example on an infinite cylinder I can just forget about the
periodic translations (rotations around the axis of the cylinder), and
treat one ring with N sites around as my unit cell. Alternatively, I can
treat one site as my unit cell and utilize the translations in the periodic
direction as well. This will mean solving the single site problem N times
for all the different quantized wavenumbers in the circular direction, but
as sparse matrix diagonalization scales superlinearly, this is a good
tradeoff.
(a) First we need to construct the system in FD(T). This is generally
larger than FD(G), for example if T is translations, it's the translational
unit cell. This can be done using the information from (1) and (2), the
extended system in
[Kwant-devel] Ideas about Kwant Symmetry API
Hi Kwant people!
I recently joined the Quantum Tinkerer group in Delft, and I'd like to
start a discussion about implementing space-group symmetries in kwant. Find
my initial thoughts below.
Best,
Daniel
I think we can be very general, and treat all kinds of on-site, spatial and
mixed symmetries on the same footing.
### Storing symmetry elements
A generic symmetry element g should have the following properties:
1. Spatial part
1. Real space translation t(g). This is already implemented as pure
translations for crystaiine systems, for these all the rest is trivial
(identity). Can also be fraction of a lattice vector, not only for
nonsymmorphic symmetries, some symmorphic symmetries also have fractional
translation part for certain choices of the spatial origin.
2. Orthogonal real space rotation O(g). This is necessary for all kinds
of point groups. (2) has to be compatible with the translations, such that
it maps lattice vectors into integer combinations of lattice vectors. (1)
and (2) need to be compatible with the lattice, such that it maps
sites/sublattices of the same type (same number of local degrees of
freedom) onto each other.
3. Permutation of the sublattices under the symmetry. This follows from
(1) and (2) given the lattice site coordinates.
2. Internal/gauge part
1. Set of unitaries U(g)_{ij}. If sublattice i is mapped on j, there is
a unitary U(g)_{ij} in U(m) (m is the number of degrees of freedom on sites
i and j) that specifies the transformation that has to happen. In simple
cases this would be a spin rotation (or a direct sum of other angular
momentum representations if there are multiple orbitals on the site) and
can be generated from O(g). However, we should allow arbitrary unitaries,
as it is not so rare that the situation is more complex. For example the
effective model of a site with large anisotropy may only contain orbitals
with maximum J_z for some axis with a high J.
2. Complex conjugation. This is a boolean that tells us if the operator
is antiunitary and should include complex conjugation. We need this for
time reversal and particle-hole, but in this framework we can have mixed
operators, like magnetic space group elements.
3. Antisymmetry. Another boolean, this we need to indicate
particle-hole-like symmetries, that flip the sign of the energy.
### Generating the group
All these discrete groups are finitely generarated. We can split off the
pure lattice translation part, and generate the finite point group part as
a quotient. This works in a brute force way (generate products up to a
certain length), or we can think of something smarter. Storing the
operators in the above linear representation form has the advantage of
taking products is quite straightforward. We may need to worry about
numerical accuracy when deciding equivalence of operators in this
representation, but it shouldn't be a big problem. If we want to implement
the full list of space groups we could fetch crystallographic tables from
http://www.cryst.ehu.es/ for example, there is plain-text interface to
basic data, like the group elements (only the real spce part) for all space
groups.
### Storing the lattice
1. Lattice sites should be grouped in symmetry related families.
2. Could be nice to also allow grouping of orbitals of the sites according
to symmetry representations.
3. There is an ambiguity in the basis because of different choices of the
angular momentum quantization basis on various sites, so it would be useful
to allow attaching a basis (SU(2) or O(3) matrix) to each site, to keep
track of the various quantization axes. This can be useful when dealing
with situations like the anisotropic atoms in 2/1 if the axis is different
on every site, this happens on lattices of interest like pyrochlores.
