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
Re: [Kwant-devel] Symmetries
Thanks, Anton and Dániel, for your insightful postings. I think that, ultimately, there is not so much difference between the reduced and expanded approaches. The work that needs to be done to expand the reduced system is equivalent to the work to check that the expanded system indeed obeys the declared symmetries. (Or do you see any problem with the statement, Dániel?) The one advantage of the reduced approach that I can see, and that could tip the scale, is that it works better with Kwant's value functions, i.e. functions that return bits of the Hamiltonian dynamically when given some optional parameters. I think it’s more robust to specify that these functions will be only ever evaluated on the FD than to say that the functions will be evaluated on the UC, but their results must always respect the declared symmetries. In the latter case if some unitary transformations are involved, we might be forced to even do almost_equal checks up to some epsilon. I’m not yet sure how to best handle symmetries that put constraints on the value of a single site or hopping. We still want value functions to return a matrix in that case I guess, so we would have to do the necessary consistency checks on that matrix. But probably that’s not different from requiring that onsite Hamiltonians are Hermitian, and that we already do. Do you agree with the following? Even if we go the reduced way, we still want to have integer numberings of all the sites and hoppings in the expanded cell, so that • solvers that don’t need point symmetries, don’t have to deal with them, • we can store quantities (e.g. observables) for the expanded unit cell. So in that sense we can forget about the point symmetries when designing the API for expanded low-systems. All we need to make sure is that the API for expanded low-level systems can be implemented efficiently for reduced low-level systems as well. smime.p7s Description: S/MIME cryptographic signature
Re: [Kwant-devel] Symmetries
Dániel Varjas wrote: (...) Considering all these complications, I'm not sure that storing hoppings in the way you propose is feasible. As I understand, you would specify the sites for the hopping by saying it connects site i in the fundamental domain to site j in the image of the fundamental domain under some SG symmetry g. I don't see why this representation would simplify calculations and it's quite hard to keep track of it for humans, compared to just specifying everything in the translational unit cell. Thanks for this very clear analysis. Perhaps you are right and storing the complete translational unit cell is the way to go. But then, isn't the difficulty of verifying that the provided translational unit cell indeed satisfies the declared symmetries comparable to the construction of the translational unit cell from the fundamental domain and said symmetries? In the end whether we chose to store only the fundamental domain or the full translational unit cell probably doesn't make a difference in terms of computing efficiency. (It could matter if, say, rotational symmetries can also apply to bigger structures, for example a large quantum dot.) So we can choose whater is easier to work with. I'm still not sure, however, *what* is easier. What do you think? What does matter for sure, however, is which user interface is presented to the user who builds systems with symmetries. The idea to only store the fundamental domain came naturally to me because this is what we’re doing in Kwant builders currently. (Only that there are no other symmetries but translational, hence fundamental domain = translational unit cell.) When creating a system with symmetry in current Kwant, the user first specifies the symmetry and then performs actions on the system (=adding and removing sites/hoppings). Kwant makes sure that these actions are done in a way that preserves the declared symmetries, e.g. adding a single site adds all of its images as well. In practice this is implemented by storing only the fundamental domain. I assumed that this way of working also makes sense with symmetries other than translational. (Of course there would be a way to plot the automatically generated unit cell.) But I’m actually not sure. What do you think? Perhaps a good example would be making a diamond lattice. Is it easier to declare the full symmetries and specify a single atom, or to declare the symmetries and the the full unit cell? The former seems cleaner, but also more abstract. The latter is perhaps easier to imagine, but my first reaction is that it’s the inferior approach. However, if you can argue that systems with symmetries should be _stored_ as complete translational unit cells, this will give us a good reason not to bother with the minimalist approach during construction as well. If we consider not only spatial but also internal symmetries this becomes even more complicated, but perhaps we can first try to come to a conclusion disregarding that. smime.p7s Description: S/MIME cryptographic signature
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, a short reply to Cristophs answer and a few further comments and questions Christoph Groth wrote: > Hi Lars, > > Thanks a lot for your comments! I’m doing fine now, but I was ill on > Friday, hence the latish reply. > > I put the others in CC as they might want to comment as well. (I left > all of Lars' message in place.) Lars, if you like, you could re-send > your original message to the kwant-discuss list. (I think it’s general > enough for kwant-discuss, but kwant-devel would be also OK.) I would > then re-reply to it there and in this way we could perhaps have a > broader discussion. But I also do not mind if this remains non-public. > > We have been also discussing a lot about (non-Abelian) symmetries in > Kwant lately. I think we’ve learned a lot so far, but we’ve also > discovered quite some subtle points. > > One way that may work out is to specify a space group as a semidirect > product of a finite point group and an infinite Abelian group of > translations. But, let’s discuss first whether it’s at all worthwhile > to have low-level non-Abelian symmetries in Kwant. > > Lars Musland wrote: > >> I hope you are doing well. We've lately been thinking a little about >> the implementation of general spatial symmetries, and have come to a >> conclusion of sorts. Maybe somewhat diverging from your present plans >> we think that a generalization to rotational symmetries at the lowest >> level of Kwant is unneeded and maybe not even the best way to proceed. >> Our suggestion is that you instead generalize the low level >> implementation only to n-dimensional translational symmetries while >> instead implementing rotational symmetries at the lattice-level (maybe >> as a new type of SiteFamily). These generalizations would then be >> completely isolated tasks, which would allow you to quickly finish the >> (fairly) easy job of generalizing the low level translational symmetry >> without (yet) having to considerer the much more complicated task of >> generalizing to non-abelian space groups. >> >> The reason why we think a generalization to rotational symmetry is >> unnescessary at the low level is as follows: There are basically two >> benefits of utilizing symmetry in a code like Kwant. The first is that >> it makes the job of setting up models easier for the user: If >> hopping-parameters are related to each other by symmetry-operations, >> then the user will only need to define a small subset of these. For >> this benefit however, an implementation at a higher level will work >> just as well, and this might even be both easier and more flexible. > > I agree with your analysis under the assumption that rotational > symmetries are indeed not useful for speeding-up significant > calculations. It seems to me, however, that they would be useful at > least for the following applications: > > • Calculation of n-d band structure: Only a fraction of the BZ needs to > be calculated, the remainder is given by symmetry. For a square > lattice (p4mm wallpaper group) this give an 8-fold speed-up. The > speedup is greater in 3-d. Yes, the speedup from this would definitely be great. But as Espen also commented I do not think there is any need for a low level implementation to accomplish this. One can easily (more or less) have a higher lever implemetation consider the desired set of k-points, determine which ones are related by symmetries and then pass only the largest nescessary subset on to the solver. With other words, unlike the case with translational symmetries there is no need for the solver itself to have an understanding of this symmetry, so that an implementation of this at the very lowest level seems unnescessary. > > • Calculation of Green’s functions of infinite systems. We have a PhD > student (Mathieu Istas) who is working on doing calculations that take > the Green’s function of some infinite clean bulk as a starting point. > (As a second step, impurities are added to that bulk etc.) The > calculation of that Green’s functions G(x, x’) involves independent > numerical integrations in energy for each (x, x’) pair. If we know > that the Hamiltonian is invariant under a certain point group, this > should be make it possible to speed-up this calculation by a > considerable factor (e.g. 8 for a square lattice). Here I do not completely understand what you mean. I think I would need a longer explanation about what you are actually wishing to do in order to soundly judge whether this requires low level implementation. Nevertheless, I think the key question is the following: Is the symmetry to be used to actually reduce the size of the hamiltonian being operated upon by the solvers? If it is not, then it seems the solvers themselves do not require a description of the symmetry, so that again a low level implementation seems unneeded. If on the other hand you are planning to use it in this way, then I reffer back to my point below, where I state that I think it
