kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2019-10-15T08:06:07Zhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/322Review whether builder interface can be vectorized2019-10-15T08:06:07ZAnton AkhmerovReview whether builder interface can be vectorizedWith vectorized systems being much faster, constructing them still will stay slow (actually slower than before). We should at least consider constructing vectorizing the system construction interface.With vectorized systems being much faster, constructing them still will stay slow (actually slower than before). We should at least consider constructing vectorizing the system construction interface.vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/319make physics.gauge support vectorized systems2020-10-22T09:01:24ZAnton Akhmerovmake physics.gauge support vectorized systemsBecause we aim to change the lead format, this is ~blocked by #316.Because we aim to change the lead format, this is ~blocked by #316.vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/317Teach plotter to use the vectorized API2020-10-22T09:01:55ZAnton AkhmerovTeach plotter to use the vectorized APIvectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/316implement vectorized ND systems2020-05-08T14:11:30ZAnton Akhmerovimplement vectorized ND systemsRequires also:
- finalization of ND systems
- Reimplementing modes, optionally taking a tuple of extra momenta if the system has more than 1 translation symmetry.
- Making `spectrum` work with these.
- Plotting
The format change will a...Requires also:
- finalization of ND systems
- Reimplementing modes, optionally taking a tuple of extra momenta if the system has more than 1 translation symmetry.
- Making `spectrum` work with these.
- Plotting
The format change will also remove the extra sites, mentioned in [this discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/323/#note_32200).vectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/315update continuum to produce vectorized systems2019-11-19T09:26:46ZAnton Akhmerovupdate continuum to produce vectorized systemsLikely we will need to use the `vectorized=False` keyword argument if we want to keep backwards compatibilityLikely we will need to use the `vectorized=False` keyword argument if we want to keep backwards compatibilityvectorizationhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/309documentation reorganization2019-07-16T13:23:36ZAnton Akhmerovdocumentation reorganizationI'll expand on this, but here's a note from the discussion with @michaelwimmer and @jbweston
![image](/uploads/81a7872e991a37e9f0b716d02bf5b831/image.png)I'll expand on this, but here's a note from the discussion with @michaelwimmer and @jbweston
![image](/uploads/81a7872e991a37e9f0b716d02bf5b831/image.png)https://gitlab.kwant-project.org/kwant/kwant/-/issues/307Speed up Peierls phase calculation2019-07-10T16:58:40ZAnton AkhmerovSpeed up Peierls phase calculationThe following discussion from !300 should be addressed:
- [ ] @cwg started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/300#note_30728): (+7 comments)
> I did some benchmarks (attached), with the foll...The following discussion from !300 should be addressed:
- [ ] @cwg started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/300#note_30728): (+7 comments)
> I did some benchmarks (attached), with the following results:
>
> ```
> cwg@neron:~/work/our/kwant% for f in qhe*.py; do echo '*' $f; time python3 $f; done
> * qhe-highlevel.py
> real 7.28s
> user 7.20s
> sys 0.08s
> * qhe-lowlevel.py
> real 7.00s
> user 6.93s
> sys 0.07s
> * qhe-manual.py
> real 1.46s
> user 1.39s
> sys 0.08s
> ```
>
> The good news is that the new high-level interface is not slower than the low-level interface.
>
> The bad news is that automatic Peierls phase computation dominates the running time.
>
> Is this expected? What could we do about it?
>
> [qhe-manual.py](/uploads/c6aa78e28c9943d95025b86154b5d551/qhe-manual.py)
> [qhe-lowlevel.py](/uploads/00f5efda3c5a360cd2a52f6b4828f16b/qhe-lowlevel.py)
> [qhe-highlevel.py](/uploads/f2f1fc54d7b640e164d95c415021e601/qhe-highlevel.py)https://gitlab.kwant-project.org/kwant/kwant/-/issues/286Plotly backend for streamplot throws NaNs2019-04-23T12:42:42ZKelvin LohPlotly backend for streamplot throws NaNsAt the current moment, the plotly backend for the streamplot is still throwing NaNs for a tutorial. This is fundamentally due to plotly's own implementation of the integrators which I have already made a separate issue there (https://git...At the current moment, the plotly backend for the streamplot is still throwing NaNs for a tutorial. This is fundamentally due to plotly's own implementation of the integrators which I have already made a separate issue there (https://github.com/plotly/plotly.py/issues/1451). Until that is fixed, we cannot merge the streamplot feature request (!273) to master.Plotly Plotterhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/273Use system.parameters in ensuring that there are no unecessary arguments2019-02-12T18:29:53ZJoseph WestonUse system.parameters in ensuring that there are no unecessary argumentsPrior [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23697).Prior [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23697).https://gitlab.kwant-project.org/kwant/kwant/-/issues/271Follow-up from "add system 'parameters'"2019-02-14T14:39:09ZJoseph WestonFollow-up from "add system 'parameters'"The following discussion from !275 should be addressed:
- [ ] @jbweston started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23699): (+1 comment)
> We should consider removing the parameter c...The following discussion from !275 should be addressed:
- [ ] @jbweston started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/275#note_23699): (+1 comment)
> We should consider removing the parameter check in the try/catch block of `kwant.builder._FinalizedBuilderMixin.hamiltonian` now that such a check exists in `hamiltonian_submatrix` (as `hamiltonian` is anyway a low-level API, and we could remove some code duplication this way).
>
> However, there *are* other places in Kwant (operators, though maybe there are others) where we use `hamiltonian` directly and any exceptions bubble up to user code. We would have to ensure that we pass the correct parameters to `hamiltonian`, rather than just everything.Kwant 1.5https://gitlab.kwant-project.org/kwant/kwant/-/issues/268Improving treatment of leads in flux algorithm2019-02-09T22:04:36ZJoseph WestonImproving treatment of leads in flux algorithmCurrently the flux algorithm is limited to leads where a single unit cell is connected. We can this trivially determine if there are any cycles (and hence any gauge contraints imposed by the leads). This limitation is largely due to the ...Currently the flux algorithm is limited to leads where a single unit cell is connected. We can this trivially determine if there are any cycles (and hence any gauge contraints imposed by the leads). This limitation is largely due to the fact that we did not do an extensive literature review to see if the problem has a known solution.
A bit of googling revealed this paper: https://dl.acm.org/citation.cfm?id=28401 (Testing for cycles in infinite graphs with periodic structure). I didn't read it yet, but it may provide a satisfactory solution.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/261Implement an exact Weidenmüller formula2020-01-23T10:09:55ZAnton AkhmerovImplement an exact Weidenmüller formulaD. Dresen and F. Hassler have derived an exact version of Weidenmüller formalism, see [this master thesis](https://www.quantuminfo.physik.rwth-aachen.de/global/show_document.asp?id=aaaaaaaaaaleoib).
Applied to a single energy it is exac...D. Dresen and F. Hassler have derived an exact version of Weidenmüller formalism, see [this master thesis](https://www.quantuminfo.physik.rwth-aachen.de/global/show_document.asp?id=aaaaaaaaaaleoib).
Applied to a single energy it is exactly the same as what we do currently in Kwant (up to issues of efficient order of Gaussian elimination), however having this formalism implemented may allow for more efficient approximate calculations in tunneling regimefuturehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/259Switch discrete symmetry types to Enum2019-02-09T22:04:35ZAnton AkhmerovSwitch discrete symmetry types to EnumThe following discussion from !257 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/257#note_21139): (+1 comment)
> @jbweston I'm wondering if we should ...The following discussion from !257 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/257#note_21139): (+1 comment)
> @jbweston I'm wondering if we should make symmetries also an `Enum` class (probably outside of this MR).futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/253Implement `streamplot`2019-01-14T10:23:40ZJoseph WestonImplement `streamplot`This will require perhaps more sophisticated parts of the plotly API.
We should consider how to make the visualization work in both 2D and 3D in plotly (the matplotlib backend will be limited to 2D).This will require perhaps more sophisticated parts of the plotly API.
We should consider how to make the visualization work in both 2D and 3D in plotly (the matplotlib backend will be limited to 2D).Plotly PlotterKelvin LohKelvin Lohhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/247Avoid unreadable text representations of lattices.2019-02-09T22:04:35ZChristoph GrothAvoid unreadable text representations of lattices.Here's is something that I come accross again and again. What's more, it's a question that it seems will remain relevant even when we redesign systems, so we can as well discuss it here.
The problem is that textual representation of la...Here's is something that I come accross again and again. What's more, it's a question that it seems will remain relevant even when we redesign systems, so we can as well discuss it here.
The problem is that textual representation of lattices are awfully long. The most awful common case is probably:
```
>>> lat = kwant.lattice.honeycomb()
>>> print(lat.neighbors())
[HoppingKind((0, 1), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None)),
HoppingKind((0, 0), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None)),
HoppingKind((-1, 1), kwant.lattice.Monatomic([[1.0, 0.0], [0.5,
0.8660254037844386]], [0.0, 0.0], '0', None), kwant.lattice.Monatomic([[1.0,
0.0], [0.5, 0.8660254037844386]], [0.0, 0.5773502691896258], '1', None))]
```
Trying to explain to someone that hopping kinds are actually very simple is doomed to fail!
This could be resolved by printing names of the lattices instead of the lattices. But for that to be useful, names should be unique inside a session, and also survive pickling and unpickling (so that different nodes in a parallel computation share the same lattice names).
But this already shows the problem: what if I try to unpickle two different lattices that share the same name?
There is no fully satisfactory solution to this problem. There is no way to have a globally unique and nice (compact, human readable) naming scheme. But perhaps we can still improve on the current situation? Here's what I propose:
* Introduce a global (at the level of an interpreter instance) registry of names. That could have the form of two weakref dictionaries:
* One mapping site families to names. It's purpose is to allow automatically assigning names to site families.
* One mapping names to sets of families. It's purpose is to track the multiple use of names.
* Assign names by default, thus enforcing that a site family always has a name. If no name is provided, assign that first one of, say, "square0", "square1", etc. that is unused. If a name is provided, use it, but warn if it is already used for a different family.
* When printing a site family, show only the name, but add a note if that name is not unique, like this: "<site family a (name is not unique!)>"
I would expect that names that are not unique would almost never occur in practice, but I think that we still have to support them to avoid problems in corner cases.
What do you think? Do you have a better idea?futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/246Follow-up from "WIP: automatic Peierls phase calculation"2019-02-09T22:04:35ZJoseph WestonFollow-up from "WIP: automatic Peierls phase calculation"The following discussion from !219 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/219#note_12686):
> With not a lot of extra effort we could also suppo...The following discussion from !219 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/219#note_12686):
> With not a lot of extra effort we could also support non-Abelian gauge fields. To do that we would need:
> * To operate with exponentiated values (so to always compute `scipy.linalg.expm(1j * flux)` if flux-is matrix-valued, and `np.exp(1j * flux)` for scalars).
> * To use multiplication instead of addition in phase computationfuturehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/244hamiltonian_submatrix returns a dense matrix by default2020-10-23T15:37:26ZJoseph Westonhamiltonian_submatrix returns a dense matrix by defaultI think that `hamiltonian_submatrix` should, by default, return a sparse matrix.
Kwant's design is in several places predicated on the fact that tight-binding Hamiltonians are usually local, and hence their matrices are sparse.
If some...I think that `hamiltonian_submatrix` should, by default, return a sparse matrix.
Kwant's design is in several places predicated on the fact that tight-binding Hamiltonians are usually local, and hence their matrices are sparse.
If someone tries to call `hamiltonian_submatrix` for a relatively large system they will get a `MemoryError`. I believe that this is a problem for Kwant's UX.https://gitlab.kwant-project.org/kwant/kwant/-/issues/243Allow operators to act on sequences of wavefunctions (matrices)2019-02-09T22:04:35ZJoseph WestonAllow operators to act on sequences of wavefunctions (matrices)Currently operators can only act on a single vector at a time, but the following is very common (e.g. if you want to get the current that would flow when applying an infinitesimal voltage to a lead):
```
wf = kwant.wave_function(syst, ....Currently operators can only act on a single vector at a time, but the following is very common (e.g. if you want to get the current that would flow when applying an infinitesimal voltage to a lead):
```
wf = kwant.wave_function(syst, ...)
J = kwant.operator.Current(syst)
J_0 = sum(J(psi) for psi in wf(0))
```
This is sub-optimal because of the explicit loop:
+ Users don't expect that they have to do this (at least 2 messages on the mailing list about this)
+ We pay the Python overhead for not vectorizing the loop
### Proposal
Allow operators to allow input of arbitrary rank.
### Challenges
We have to define what the output should be for all possible inputs. In the simplest case this is relatively straightforward:
```
wfs = kwant.wave_function(syst, ...)
rho = kwant.operator.Density(syst, ...)
wfs_0 = wfs(0) # shape: (nmodes, norbs)
rho(wf(0)) # shape: (nmodes, nsites)
all_wfs = np.array([wfs(i) for i in range(num_leads)]) # (nleads, nmodes, norbs)
rho(all_wfs) # (nleads, nmodes, nsites)
```
but what if we provide `bra` as well as `ket`?
```
# (nmodes, nmodes, norbs) ?
# (nmodes, norbs) ?
rho(wfs(0), wfs(0))
```
### Implementation details
Even though the input may be of arbitrary rank, the lowest layers of `kwant.operator` only need to operate on rank-2 quantities, which means that we can still use a fixed number of C loops.
The python layer can simply reshape the input and output to be in the correct format.
In the above example:
```
all_wfs = np.array([wfs(i) for i in range(num_leads)]) # (nleads, nmodes, norbs)
rho(all_wfs) # (nleads, nmodes, nsites)
```
We would internally reshape `all_wfs` to shape `(nleads * nmodes, norbs)`, pass it down to the lower layers, and then reshape the output of the lower layers to `(nleads, nmodes, nsites)` before returning it to the user.futurehttps://gitlab.kwant-project.org/kwant/kwant/-/issues/235Mumps support for Windows conda builds2022-08-03T07:41:24ZJoseph WestonMumps support for Windows conda buildsBlocked by [this upstream MR](https://github.com/conda-forge/mumps-feedstock/pull/28/)Blocked by [this upstream MR](https://github.com/conda-forge/mumps-feedstock/pull/28/)https://gitlab.kwant-project.org/kwant/kwant/-/issues/234Improve html representation of discretizer's builders2019-11-28T14:39:32ZAnton AkhmerovImprove html representation of discretizer's buildersHere is what we have now (as of v1.4.0a1):
![image](/uploads/b4f8ed42c49384a463b71d57586befe7/image.png)
Several improvements come to mind:
- It's already an html representation, we could sparingly apply a couple of tags
- We should me...Here is what we have now (as of v1.4.0a1):
![image](/uploads/b4f8ed42c49384a463b71d57586befe7/image.png)
Several improvements come to mind:
- It's already an html representation, we could sparingly apply a couple of tags
- We should mention that this is a template builder produced by discretization
- We should hide the internal names and expose the parameters that this builder expects, as well as the number of d.o.f.Kwant 1.4.x