[Kwant-devel] Symmetries

Lars Musland lars.musland at smn.uio.no
Wed Jan 27 12:34:50 UTC 2016

Hi Kwant-people

Cristoph asked me to resend this message to the devel-list. So here follows. This is the original message. I will quickly send a modified version including replies to Cristophs answer and some further comments.
From: Lars Musland
Sent: 22 January 2016 14:36
To: christoph.groth at cea.fr
Cc: Espen Flage-Larsen
Subject: Re: Re: Conference in September

Hi Cristoph,

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.

The second benefit of utilizing symmetry is that it allows a speedup of the calculation itself, as well as a reduction of memory-requirements by using the symmetry to block-diagonalize the Hamiltonian before the nummerical treatment. This type of symmetry-utilization will obviously need to be implemented at a low level. A key point here however, is that this reduction will in any case only work if the symmetry group is abelian: The block-diagonalization of the Hamiltonian is possible because the Hamiltonian comutes with the symmetry-opperator, so that by a well known theorem they have a common diagonalization. However, if one is to do this using multiple symmetries at the same time, then all of the symmetry operators must also commute with each other. Thus, if one has a non-abelian symmetry group, then one can at best achieve this reduction using one abelian subgroup at a time. As long as one is dealing with an infinite spatial symmetry, the best choise of this subgroup would obviously always be the subgroup of translations.

It sems then that there are normally no benefits in efficiency from implementing rotational symmetries at a low level, while the benefits in user friendliness can also be achived at a higher level. This is why this aproach is our suggestion to you. There could of course be considerations that we are not aware of, and as developers of Kwant you are obviously best fitted to make the decission. But this is in any case our innput.

Best regarsds,
Espen and Lars
-------- Forwarded Message --------
Subject: Re: Conference in September
Date: Wed, 13 Jan 2016 11:56:06 +0100
From: Christoph Groth <christoph.groth at cea.fr>
To: Espen Flage-Larsen <espen.flage-larsen at fys.uio.no>

Espen Flage-Larsen wrote:

> How is the three dimensional extension going? Any news since we
> last visited?

We’re done with all the preliminary work: I guess you’ve seen that
we’ve moved to Python 3.  This took way longer than expected due
to various little issues, but it had to be done at one point.

Also, we’ve made up our minds on how to handle incompatible
changes to Kwant.  It’s actually stated nowhere „officially“ but
we like to be nice to the users of Kwant and provide backwards
compatibility within a major version (e.g. 1.x).  As such, at the
time when you were visiting us the plan was to release all the
backwards-incompatible stuff that is pending in one big release
(as “Kwant 2”).  But this would mean that that release would be
quite big and complex.  I think we now have a much better plan,
that relies on two principles:

(1) We relax our attitude to backwards compatibility a little bit:
I think it’s OK to sneak-in backwards-incompatible changes if
these are well-documented and will affect no one or only very few

(2) We will adopt a more evolutionary approach: thus, we will for
example introduce the new low-level system API as (for example)
kwant.system.System2, while the old kwant.system.System will
remain.  Eventually the old stuff will become deprecated and will
then be removed for Kwant 2.  But the plan is to have all the
functionality already present in some future version of Kwant 1.

Point 2 means that we will most likely not need to use point 1
very much.

I guess Point 2 is also good news for you, because it means that
we can have a version of Kwant that supports more general
symmetries quite soon, and this does not have to wait until the
fully-fledged multi-level “composite systems” (i.e. 0-d dot
embedded in a 1-d wire, both embedded in a 2-d bulk) are

So now I’m actually working on the interface of the new low-level
systems.  I would like to have support for general spatial
symmetries, so that one can, for example, define a graphene sheet
with only a single site and a single hopping (and not three sites
and hoppings like currently).  I hope that the support can be made
specific enough such that a generic band-structure routine will
automatically take care of them.

I had a look at spglib and while it has functionality to recognize
symmetries that exist, it doesn’t seem to do what we need: we need
a generic representation of spatial symmetries.  So far we were
thinking of representing the symmetries in the low-level system as
arbitrary groups, but I think that I can come up with something
that is _less_ general and more specific to spatial symmetries,
such that the code that deals with such symmetric systems can be
made more intelligent.

Please do share any ideas that you might have about these things.

> Lars is coming back from tomorrow and we will start discussions
> about the way forward.

I think the new approach (i.e. point 2 above) will make it easier
to identify some pretty isolated tasks that we could as Lars to
have a look at.

See you,

More information about the Kwant-devel mailing list