qsymm issueshttps://gitlab.kwant-project.org/qt/qsymm/-/issues2021-02-04T13:35:04Zhttps://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/35Qsymm broken on Sympy 1.72020-12-11T18:01:59ZJoseph WestonQsymm broken on Sympy 1.7While running the Kwant test suite against a freshly-made environment I see that the Qsymm tests fail:
![image](/uploads/c6126cb38dc08324abc35a98bb2dcc09/image.png)While running the Kwant test suite against a freshly-made environment I see that the Qsymm tests fail:
![image](/uploads/c6126cb38dc08324abc35a98bb2dcc09/image.png)https://gitlab.kwant-project.org/qt/qsymm/-/issues/34Implement JSON serialization of main objects2020-09-28T09:55:55ZAnton AkhmerovImplement JSON serialization of main objectsSince some of the qsymm processes aren't deterministic (#33), the best practice is to serialize different qsymm objects on disk in a standardized manner.
I propose to implement a `.to_json` method for all the standard objects.Since some of the qsymm processes aren't deterministic (#33), the best practice is to serialize different qsymm objects on disk in a standardized manner.
I propose to implement a `.to_json` method for all the standard objects.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 symmetries2020-09-01T17:51:11ZDá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/25Scipy 1.3.3 breaking things2020-01-24T17:01:27ZHélène SpringScipy 1.3.3 breaking thingsThis is a vague issue. Scipy 1.3.3 *sometimes* breaks things. Scipy.linalg *sometimes* returns the error "SVD did not converge" when trying to create a qsymm.hamiltonian_generator.hamiltonian_from_family() instance. However, when running...This is a vague issue. Scipy 1.3.3 *sometimes* breaks things. Scipy.linalg *sometimes* returns the error "SVD did not converge" when trying to create a qsymm.hamiltonian_generator.hamiltonian_from_family() instance. However, when running this on 100 engines on the cluster, this 'sometimes' leads to at least one error, stopping everything. The Hamiltonian in question that trips the error doesn't seem to have anything special about it, but I'll list it here for completeness. It requires the nonhermitian branch of qsymm to work.
```python
def make_ham_from_fam_8x8_fp3():
#start from power 3 for k and whittle it down.
#the coupled Hamiltonian with maximum k power = 3 and j=3/2 part set to 0
S = qsymm.groups.spin_matrices(1/2)
rot = qsymm.ContinuousGroupGenerator(R=2 * S[1], U=scipy.linalg.block_diag(3 * S[2], S[2], S[2], S[2]))
PH = qsymm.PointGroupElement(-np.eye(2), True, True, scipy.linalg.block_diag(2 * S[0], 2 * S[0], 2 * S[0], 2 * S[0]))
herm = qsymm.PointGroupElement(-np.eye(2), True, False, np.eye(8), True)
sym = [rot, PH, herm]
family = qsymm.continuum_hamiltonian(sym, dim=2, total_power=3, hermitian=False, prettify=True)
coeffs_hop=['t2','t21',0,0,'t22',0,'t23',0,0,0,
'td1b','td2a','td3a','t11b','to1b','to2b','t12b','to3b','t13b','td1a',
'td2b','td3b','t11a','to1a','to2a','t12a','to3a','t13a',0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,'t1b',0,0,0,0,0,
0,0,0,0,'t1a',0,0,0,0,0,
0,0,0,0
]
coeffs_onsite=['mu','mu1','muoff1','muoff2','mu2','muoff3','mu3','lambda1','lambda2','lambda3',
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0
]
hopping=Symbol('r')*qsymm.hamiltonian_generator.hamiltonian_from_family(family, coeffs=coeffs_hop, tosympy=True)
onsite=Symbol('os')*qsymm.hamiltonian_generator.hamiltonian_from_family(family, coeffs=coeffs_onsite, tosympy=True)
return onsite+hopping
```
Other similar hamiltonians that also rely on the nonhermitian branch of qsymm don't raise the error. Most importantly, the error doesn't occur for Scipy 1.3.1, so presumably they did something unfortunate in between versions. What that is and how it enters here is the mystery.https://gitlab.kwant-project.org/qt/qsymm/-/issues/24Qsymm tests fail on latest requirements2019-12-25T12:50:47ZJoseph WestonQsymm tests fail on latest requirementsI didn't look into this in detail, but the latest pipelines are failing with the cutting-edge dependency versions, but passing with the old dependency versions.I didn't look into this in detail, but the latest pipelines are failing with the cutting-edge dependency versions, but passing with the old dependency versions.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 Varjashttps://gitlab.kwant-project.org/qt/qsymm/-/issues/7Allow text-based definition of unitary part of symmetries2019-11-11T13:51:05ZDániel VarjasAllow text-based definition of unitary part of symmetriesWould be useful if the unitary part of symmetry operators could be defined in a text-like format, same as Model (like writing '1j * kron(sigma_y, sigma_0)')Would be useful if the unitary part of symmetry operators could be defined in a text-like format, same as Model (like writing '1j * kron(sigma_y, sigma_0)')