qsymm issueshttps://gitlab.kwant-project.org/qt/qsymm/-/issues2023-11-02T19:17:53Zhttps://gitlab.kwant-project.org/qt/qsymm/-/issues/51use nox2023-11-02T19:17:53ZAnton Akhmerovuse noxqsymm CI is quite old, we should switch to mamba+nox, similar to pymablockqsymm CI is quite old, we should switch to mamba+nox, similar to pymablockhttps://gitlab.kwant-project.org/qt/qsymm/-/issues/50support sparse arrays2023-10-25T14:45:18ZAnton Akhmerovsupport sparse arraysRecent scipy defines sparse arrays in addition to sparse matrices, which will eventually be deprecated. These will fail an instance check `isinstance(x, sparse.spmatrix)`. We should support these too.Recent scipy defines sparse arrays in addition to sparse matrices, which will eventually be deprecated. These will fail an instance check `isinstance(x, sparse.spmatrix)`. We should support these too.https://gitlab.kwant-project.org/qt/qsymm/-/issues/43sign convention in double group representations2022-09-28T18:44:26ZGerson J Ferreirasign convention in double group representationsMy question here is if there's a way to keep track weather the symmetry element is a barred or unbarred symmetry operation of the double group. It seems that you have been working on a similar topic within the *pg_representations* branch...My question here is if there's a way to keep track weather the symmetry element is a barred or unbarred symmetry operation of the double group. It seems that you have been working on a similar topic within the *pg_representations* branch. So, this might be related.
One possible approach is to add an extra property to point group objects labeling if they are barred or unbarred operations and keep track of this at each multiplication in `generate_group`. Ideally, it would be interesting if `generate_group` could return only the unbarred operations. For instance, a mirror operation could be defined as
```python
U = np.kron(-expm(-1j*np.pi*sy/2), -sy)
My = qsymm.mirror([0,1], U=U, barred=False)
Ebar = My * My # should return the barred identity
```
## Why it is important?
*(important for me, at least)*
For the theory of invariants this sign issue is irrelevant, since all operations involve `U` twice, as in `U @ H @ U.T = H`, and the overall sign of `U` sign cancels. But the basis transformation proposed in [Mozrzymas, J. Phys. A: Math. Theor. 47, 505203 (2014)](http://dx.doi.org/10.1088/1751-8113/47/50/505203) requires a product of the representations in the original and desired basis (see their Eqs. 3.15 and 3.16). So, it seems important to avoid ambiguities that might mix a barred representation in one basis and a unbarred in another basis, which would make the sum in the coefficient r_ab wrong.
## Details
I'm using qsymm `generate_group` to build the group elements from its generators, and I've notice that there's no control if the symmetry element represent a barred or unbarred double group operation. For instance, the following code gives True for `A == B`, even though their matrices have different signs.
```python
import qsymm
A = qsymm.identity(2, 4)
B = qsymm.identity(2, 4)
B.U = -B.U
print('A == B?', A == B)
print('A:', A.U)
print('B:', B.U)
```
This becomes an issue when I use the `generate_group` routine. In the following example for graphene, `G1` is built from the generators `(C3, My)`, while `G2` is built manually for all 6 unbarred symmetry operations `(Um, C3, My, C3b, Mya, Myb)`. I would expect `G1` to be the same as `G2`, but while `G2` has only unbarred operators, `G1` has a mixture of barred and unbarred operators. Particularly, the identity differs as illustrated above.
```python
import numpy as np
import qsymm
from scipy.linalg import expm
# Pauli matrices (auxiliar)
s0 = np.array([[1, 0],[0, 1]])
sx = np.array([[0, 1],[1, 0]])
sy = np.array([[0, -1j],[1j, 0]])
sz = np.array([[1, 0],[0, -1]])
phi = 2*np.pi/3
U = np.kron(expm(-1j*phi*sz/2), s0*np.cos(+phi)-1j*sz*np.sin(+phi))
C3 = qsymm.rotation(1/3, U=U)
U = np.kron(expm(+1j*phi*sz/2), s0*np.cos(-phi)-1j*sz*np.sin(-phi))
C3b = qsymm.rotation(-1/3, U=U)
U = np.kron(-expm(-1j*np.pi*sy/2), -sy)
My = qsymm.mirror([0,1], U=U)
s = -np.sin(phi)*sx - np.cos(phi)*sy
U = np.array([[0, 1j*np.exp(-1j*phi)], [-1j*np.exp(1j*phi), 0]])
U = np.kron(-expm(-1j*np.pi*s/2), U)
Mya = qsymm.mirror([-np.sin(phi), -np.cos(phi)], U=U)
s = -np.sin(phi)*sx + np.cos(phi)*sy
U = np.array([[0, 1j*np.exp(1j*phi)], [-1j*np.exp(-1j*phi), 0]])
U = np.kron(-expm(-1j*np.pi*s/2), U)
Myb = qsymm.mirror([-np.sin(phi), +np.cos(phi)], U=U)
Um = qsymm.identity(2, 4)
G1 = list(qsymm.groups.generate_group([C3, My]))
G2 = list(qsymm.groups.generate_group([Um, C3, My, C3b, Mya, Myb]))
print('Group size:', len(G1), len(G2))
for i in range(len(G1)):
if G1[i] == Um:
print('Matrix rep of identity in G1')
print(G1[i].U)
if G2[i] == Um:
print('Matrix rep of identity in G2')
print(G2[i].U)
```
Notice that both cases return groups of length 6, but the double group should have 12 elements here. Essentially, the code does not account for the sign difference.https://gitlab.kwant-project.org/qt/qsymm/-/issues/41Make `SymmetryGroup` object so the result of symmetry finding is unique2022-03-15T12:53:45ZDániel VarjasMake `SymmetryGroup` object so the result of symmetry finding is uniqueCurrently `symmetries` returns a pair of discrete and continuous group symmetries. If there are any continuous symmetries, this result is not unique, as the discrete symmetries can be mixed with any continuous symmetry. This is a recurri...Currently `symmetries` returns a pair of discrete and continuous group symmetries. If there are any continuous symmetries, this result is not unique, as the discrete symmetries can be mixed with any continuous symmetry. This is a recurring problem, that the same symmetry group action can be represented by `qsymm` in different ways, and it is not always easy to tell whether two instances are the same.
I propose the solution to combine the continuous and discrete symmetries into a single object, and implement various symmetry group operations (such as equivalence check, and normalizing the representations) on such objects.https://gitlab.kwant-project.org/qt/qsymm/-/issues/40Implement indexing/slicing of Model2021-02-04T13:35:04ZDániel VarjasImplement indexing/slicing of ModelIt would be convenient if `Model` object could be sliced the same way as arrays, to get a block of the Hamiltonian for example. The nontrivial part of this, is that the `__getitem__` (`[key]`) functionality is currently used as for dicts...It would be convenient if `Model` object could be sliced the same way as arrays, to get a block of the Hamiltonian for example. The nontrivial part of this, is that the `__getitem__` (`[key]`) functionality is currently used as for dicts to extract the matrix coefficient of the symbolic expression `key`. Deducing whether something is a coefficient or an index/slice based on its type is complicated by the fact that the key `1` is used to refer to the constant part, but it also could be an index.
I propose the following syntax:
- let the first entry in `[]` be interpreted as a symbolic coefficient
- all subsequent entries as indides/slices into the array part
This would be backward compatible, and should allow operations like `model[:, 0:2, 2:4]` to cut out a block of the `Model` while keeping all the symbolic dependence.
Does anyone see a potential problem with this proposal?https://gitlab.kwant-project.org/qt/qsymm/-/issues/39Fill Kwant system with position dependent parameters from Qsymm model2021-01-27T16:15:46ZIsidora ArayaFill Kwant system with position dependent parameters from Qsymm modelIt would be great if one could create a Kwant system by filling a Qsymm model with position dependent parameters. The motivation for this is to study defects in systems with Hamiltonians that break particular symmetries.
Things to consi...It would be great if one could create a Kwant system by filling a Qsymm model with position dependent parameters. The motivation for this is to study defects in systems with Hamiltonians that break particular symmetries.
Things to consider:
* The workhorse that converts onsites and hoppings to Kwant value functions is Model.lambdify . That's [over here](https://gitlab.kwant-project.org/kwant/kwant/-/blob/master/kwant/qsymm.py#L362).
* Unlike kwant.continuum, which knows how to treat position dependence, Model.lambdify [does not know that](https://gitlab.kwant-project.org/qt/qsymm/-/blob/master/qsymm/model.py#L690)
So a minimal change that would allow to create models with position dependence would be to:
* Subclass a model and implement a different lambdify method
* Replace model parameters so that they acquire position dependecehttps://gitlab.kwant-project.org/qt/qsymm/-/issues/38Automate the process of finding the real space lattice vectors and site posit...2021-01-08T16:38:22ZDániel VarjasAutomate the process of finding the real space lattice vectors and site positions of BlochModelsNow `kwant.qsymm.model_to_builder` takes lattice vectors and site positions as input, but this information is typically already encoded in the Bloch Hamiltonian written in the real space convention, so we could make these arguments optio...Now `kwant.qsymm.model_to_builder` takes lattice vectors and site positions as input, but this information is typically already encoded in the Bloch Hamiltonian written in the real space convention, so we could make these arguments optional and automate this step. Also useful for finding the Brillouin-zone of `BlochModel`s, which in turn would allow automating finding candidates for spatial symmetries.https://gitlab.kwant-project.org/qt/qsymm/-/issues/37With sympy==1.5 kwant.qsymm.builder_to_model results in malformed BlochModel2020-12-17T09:23:40ZDániel VarjasWith sympy==1.5 kwant.qsymm.builder_to_model results in malformed BlochModelWith `sympy=1.5` the `BlochModel` returned by `kwant.qsymm.builder_to_model` has `momenta` as strings, while these should be `sympy.Symbol`s. The reason is `all(m in qsymm.model._commutative_momenta for m in ('k_x', 'k_y'))` (where `_com...With `sympy=1.5` the `BlochModel` returned by `kwant.qsymm.builder_to_model` has `momenta` as strings, while these should be `sympy.Symbol`s. The reason is `all(m in qsymm.model._commutative_momenta for m in ('k_x', 'k_y'))` (where `_commutative_momenta` is a list of `sympy.Symbol`s) evaluates to True in 1.5, it is False in all other versions I tried. We should require `sympy==1.5.1` for example, or rewrite this check in some more failsafe way.https://gitlab.kwant-project.org/qt/qsymm/-/issues/36pass tolerance as argument in model.tosympy()2020-12-14T17:14:34ZAnastasiia Varentcovapass tolerance as argument in model.tosympy()default behavior now:
![image](/uploads/5da89fd59fbf93fc6c77de4fd25e052b/image.png)
the only possible adjustment:
![image](/uploads/d376a438e0055c42bd8e412dd24d4971/image.png)
current work around:
![image](/uploads/077ae1639b25d4c84...default behavior now:
![image](/uploads/5da89fd59fbf93fc6c77de4fd25e052b/image.png)
the only possible adjustment:
![image](/uploads/d376a438e0055c42bd8e412dd24d4971/image.png)
current work around:
![image](/uploads/077ae1639b25d4c84723c8a3b891d09e/image.png)
would be convenient just:
```python
model.tosympy(tolerance=1e-5)
```https://gitlab.kwant-project.org/qt/qsymm/-/issues/33Ensure that models are always constructed in the same way2020-09-28T09:55:55ZAnton AkhmerovEnsure that models are always constructed in the same waySearching for a model tends to return different linear combinations of terms over different runs. We should improve on that, so that model construction is reproducible.
At worst, we should control the rng sources and require a seed.Searching for a model tends to return different linear combinations of terms over different runs. We should improve on that, so that model construction is reproducible.
At worst, we should control the rng sources and require a seed.https://gitlab.kwant-project.org/qt/qsymm/-/issues/31Prettify and display families in Pauli basis2020-09-16T13:39:34ZDániel VarjasPrettify and display families in Pauli basisWould be useful for toy models to be able to display models in terms of tensor products of Pauli matrices. This should involve prettification that minimizes the number of terms in the Pauli basis. Could also provide the option of prettif...Would be useful for toy models to be able to display models in terms of tensor products of Pauli matrices. This should involve prettification that minimizes the number of terms in the Pauli basis. Could also provide the option of prettification and display in terms of custom basis matrices.Anastasiia VarentcovaAnastasiia Varentcovahttps://gitlab.kwant-project.org/qt/qsymm/-/issues/30Model.subs always removes elements close to zero2020-06-21T11:05:19ZHugo KerstensModel.subs always removes elements close to zeroI have a `Model` which has elements smaller than `1e-8` that are totally valid. However, when I try to substitute a variable using `Model.subs` the elements close to zero get removed.
This is caused by `Model.transform_symbolic` (that ...I have a `Model` which has elements smaller than `1e-8` that are totally valid. However, when I try to substitute a variable using `Model.subs` the elements close to zero get removed.
This is caused by `Model.transform_symbolic` (that is used by `Model.subs`) setting `normalize=True` for the new model construction. When `normalize=True`, elements that are `np.allclose` to zero are removed. It doesn't like there is a way to pass arguments such that this `normalize` is not passed to the new model.https://gitlab.kwant-project.org/qt/qsymm/-/issues/29Handle non-commuting symbols in Model2020-06-11T10:31:08ZDániel VarjasHandle non-commuting symbols in ModelAfter implementing #20 it is possible to have both momentum and coordinate type symbols in Models. However, we only support commutative symbols at the moment, in order to be able to properly handle quantum Hamiltonians, we need to make s...After implementing #20 it is possible to have both momentum and coordinate type symbols in Models. However, we only support commutative symbols at the moment, in order to be able to properly handle quantum Hamiltonians, we need to make sure non-commuting symbols are handled properly in the `Model` class.https://gitlab.kwant-project.org/qt/qsymm/-/issues/28Find gauged symmetries2022-08-19T14:52:37ZDániel VarjasFind gauged symmetriesWhen the Hamiltonian includes gauge fields, it happens that qsymm misses some symmetries.
For example, when the superconducting order parameter has a constant complex value, in `qsymm` this is represented as two terms with real coeffici...When the Hamiltonian includes gauge fields, it happens that qsymm misses some symmetries.
For example, when the superconducting order parameter has a constant complex value, in `qsymm` this is represented as two terms with real coefficients `Re Δ` and `Im Δ`. Treating both of these as free parameters, `qsymm.symmetries` finds no time-reversal symmetry. However, any constant `Δ` is gauge-equivalent to a purely real `Δ`, which has TR invariance. The reason TR is not found in the general case is that the unitary part of TR depends on the gauge choice (the phase of `Δ`) and `qsymm` only looks for symmetries with constant unitary parts.
Looking for symmetries with constant unitary part works fine usually, as physical symmetries should be independent of the specific parameters in the system. For gauge-fields, however, there is an inherent gauge freedom, which is not physical, and the symmetries may depend on the gauge choice. For now it is the user's responsibility to carry out a gauge-fixing before looking for symmetries, but this is not always obvious.
For example a Hamiltonian family might include non-physical gauge-like symmetries, i.e. when parts of the family are related by a family of unitary transformations. This typically happens when changing the phase of a complex valued parameter results purely in a unitary transformation of the Hamiltonian. Like in the above example with `Δ`, it may happen that the family lacks a symmetry with constant unitary part for arbitrary phase of the parameter, but has this symmetry for any fixed value of the phase. Such a situation might result in mysterious degeneracies, seemingly not associated with any symmetry.
Would be nice to automate detection of such gauge-like symmetries, gauge-fixing, or allow some form of gauge-dependence in the symmetries that the symmetry finder looks for.https://gitlab.kwant-project.org/qt/qsymm/-/issues/26Add a check that the unitary part of `PointGroupElement` is actually unitary2020-04-19T12:45:25ZDániel VarjasAdd a check that the unitary part of `PointGroupElement` is actually unitaryCurrently no check is done, if a symmetry operator is defined non-unitary, the Hamiltonian generator pipeline finishes without any errors, finding no suitable solution. We should add a check, perhaps at definition time for `PointGroupEle...Currently no check is done, if a symmetry operator is defined non-unitary, the Hamiltonian generator pipeline finishes without any errors, finding no suitable solution. We should add a check, perhaps at definition time for `PointGroupElement`. Might also be a good time to think about making `PointGroupElement`s explicitly immutable.https://gitlab.kwant-project.org/qt/qsymm/-/issues/23Add changelog entries for recently merged fixes2019-12-17T13:13:12ZJoseph WestonAdd changelog entries for recently merged fixesDániel VarjasDániel Varjashttps://gitlab.kwant-project.org/qt/qsymm/-/issues/22Make qsymm work with non-Hermitian Hamiltonians2020-06-10T10:32:27ZDániel VarjasMake qsymm work with non-Hermitian HamiltoniansMaking qsymm work with non-Hermitian Hamiltonians can be achieved by a few relatively simple steps:
+ `Model` already works with non-Hermitian Hamiltonians. All symbols are assumed real (this we should clarify in the docstring), but it ...Making qsymm work with non-Hermitian Hamiltonians can be achieved by a few relatively simple steps:
+ `Model` already works with non-Hermitian Hamiltonians. All symbols are assumed real (this we should clarify in the docstring), but it is still possible to express an arbitrary Hamiltonian family by separating the Hermitian and anti-Hermitian parts.
+ The symmetry finder doesn't rely on any assumption about the input being Hermitian as far as I know, and should work as is. We should still review the code with this in mind and write some tests. To be clear, we do not allow non-Hermitian conserved quantities or non-(anti)unitary discrete (anti)symmetries, because this would require dealing with non-compact Lie-algebras, which is hard.
+ We should add a `transpose` attribute to `PointGroupElement`s to signal that the transformed operator is also transposed, which requires amending the `apply` method. This will allow declaring hermiticity-like constraints as symmetries by setting `conjugate=True` and `transpose=True`. Should provide a constructor `hermiticity` for convenience. The symmetry finder should work to find such symmetries if they are provided in `candidates` (this is not completely obvious, should think more and test it).
+ The Hamiltonian generator now only produces Hermitian Hamiltonians. We could add a `hermitian` flag that controls whether the result is made Hermitian. This requires changing the basis the Hamiltonian terms are generated from to a full matrix basis from the current Hermitian matrix basis in `continuum generator`, the same in the onsites in `bloch_generator` and skipping the Hermitian symmetrization for the hoppings. With `hermitian=False` and some hermiticity-like symmetries provided in `symmetries` everything should work the same.Dániel VarjasDániel Varjashttps://gitlab.kwant-project.org/qt/qsymm/-/issues/21Improve pretty display of point group and continuous group elements2019-12-03T14:05:17ZDániel VarjasImprove pretty display of point group and continuous group elements1) There is a bug in the display of `ContinuousGroupElement` when obtained without `prettify`, the rotation matrix is always `R(ϕ)` even though the `L` is normalized differently (for example it should be `R(ϕ/2)` to be consistent). Could...1) There is a bug in the display of `ContinuousGroupElement` when obtained without `prettify`, the rotation matrix is always `R(ϕ)` even though the `L` is normalized differently (for example it should be `R(ϕ/2)` to be consistent). Could renormalize `L` by the norm of the real space rotation.
2) The display of rotation axes that are not main crystallographic directions is unreadable, because it is a series of floating point numbers not separated by commas or spaces. Should add commas where floating point is used. Could also improve display for directions that are 60 degree rotated using `sympy.nsimplify`.Dániel VarjasDániel Varjashttps://gitlab.kwant-project.org/qt/qsymm/-/issues/20Add `positions` similar to `momenta` to `Model`2020-06-13T11:46:17ZDániel VarjasAdd `positions` similar to `momenta` to `Model`It would be useful for Hamiltonians with real space dependence (such as hopping terms in non-crystalline systems, or the continuum description of a quantum well) if we allowed definition of symbols that are `positions`. The only differen...It would be useful for Hamiltonians with real space dependence (such as hopping terms in non-crystalline systems, or the continuum description of a quantum well) if we allowed definition of symbols that are `positions`. The only difference compared to `momenta` would be that they don't flip sign under antiunitary symmetry operations.
It could also be useful to allow multiple vectors that transform the same way, for example to treat interaction terms that have multiple momentum variables.
This is all possible in current `qsymm` in a hacky way: extend the real space dimension to the total number of transforming symbols, use `momenta` that is a single vector with all these vectors stacked, and make `R` in `PointGroupElements` block-diagonal with the appropriate transformation matrices in each block. The `positions` type transformation can be faked by using `-R` in antiunitary operators.
`<TLDR>`
We could consider supporting other similar quantities, like `angular_momenta` which change sign under TR but do not change under spatial inversion (this really only makes sense in 3D, in lower dimensions it is ambiguous whether something is a rotation or an inversion). This would mostly be useful for classical dynamical variables, _not_ for fixed external fields. For example one may ask, what is the symmetry of the electromagnetic term `E⋅B`, a product of a `position` and an `angular_momentum` type variable (it is invariant under anything that doesn't change space-time orientation). However, when examining the symmetries of the quantum Hamiltonian `B⋅σ` with fixed external field `B`, `B` should _not_ be transformed. We should give this more thought, it is not clear to me how many types of such objects we need in general, whether the behaviour under PH and TR is independent.Dániel VarjasDániel Varjas