kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2019-02-14T14:39:09Zhttps://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/220expose monomials and make_commutative as part of public API2018-09-20T07:55:28ZRafal Skolasinskiexpose monomials and make_commutative as part of public APIThese two functions are very useful in context of many continuum-related projects, e.g. Lowdin.
Making them part of public API will assure that other projects can rely on them.These two functions are very useful in context of many continuum-related projects, e.g. Lowdin.
Making them part of public API will assure that other projects can rely on them.Kwant 1.5Rafal SkolasinskiRafal Skolasinskihttps://gitlab.kwant-project.org/kwant/kwant/-/issues/193Follow-up from "WIP: Lazy imports"2020-10-22T09:10:54ZAnton AkhmerovFollow-up from "WIP: Lazy imports"The below discussion got lost because we chose !207 instead of !192.
The following discussion from !192 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/192#n...The below discussion got lost because we chose !207 instead of !192.
The following discussion from !192 should be addressed:
- [ ] @anton-akhmerov started a [discussion](https://gitlab.kwant-project.org/kwant/kwant/merge_requests/192#note_10301):
> After this issue is merged, we should also fix the tutorials to not emphasize importing pyplot if it isn't necessary for direct calling by the user.Kwant 1.5https://gitlab.kwant-project.org/kwant/kwant/-/issues/136plotter.spectrum: better compute bands2020-10-22T08:30:47ZAnton Akhmerovplotter.spectrum: better compute bandsThere are several things we could consider:
* Allowing to select a sub-range of bands and to use sparse diagonalization (appropriate for large unit cells of a lead or spectra of closed systems).
* Do a better job resolving level crossing...There are several things we could consider:
* Allowing to select a sub-range of bands and to use sparse diagonalization (appropriate for large unit cells of a lead or spectra of closed systems).
* Do a better job resolving level crossings once we depend on Debian stretch (see the [blog post](https://quantumtinkerer.tudelft.nl/blog/connecting-the-dots/) outlining the algorithm). This one especially leads to better quality plots.
* Perhaps utilize conservation laws if present (both for computation and representation of the bands).Kwant 1.5Anton AkhmerovAnton Akhmerovhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/127fill() is not atomic2018-09-20T08:12:06ZChristoph Grothfill() is not atomicWhen `fill` fails, because `max_sites` is reached or because the shape function raises an exception (this happens in `attach_lead()` when the scattering region does not interrupt the central builder), the graph of the target builder is i...When `fill` fails, because `max_sites` is reached or because the shape function raises an exception (this happens in `attach_lead()` when the scattering region does not interrupt the central builder), the graph of the target builder is in an inconsistent state and is currently erased.
`fill` should be atomic: either it suceeds, or it leaves `self` untouched.Kwant 1.5Christoph GrothChristoph Grothhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/122Emancipate sites from `builder`2020-10-23T15:58:20ZChristoph GrothEmancipate sites from `builder`Kwant is moving in a direction where sites and the associated families and symmetries are becoming first-class concepts that are independent of the builder module.
As a first step in this direction, let's move `Site`, `SiteFamily` and `...Kwant is moving in a direction where sites and the associated families and symmetries are becoming first-class concepts that are independent of the builder module.
As a first step in this direction, let's move `Site`, `SiteFamily` and `Symmetry` from `builder` into `system`. (the old names will have to remain usable for backwards compatibility.) `SimpleSiteFamily` can be also moved and perhaps renamed.
This will allow to make the `lattice` module independent of `builder`. This in turn will allow the use of concepts like `TranslationalSymmetry` inside the builder module (currently this is impossible due to circular imports.)
With site families independent of builders `VerySimpleSymmetry` can be replaced by `TranslationalSymmetry` in the builder tests.Kwant 1.5https://gitlab.kwant-project.org/kwant/kwant/-/issues/29Factor out MUMPS2019-02-08T16:28:52ZAnton AkhmerovFactor out MUMPSMost of the work we've done in porting MUMPS makes more sense as a standalone MUMPS wrapper. [pymumps](https://github.com/bfroehle/pymumps) is a related project, that implements a smaller subset of MUMPS interface. We could also consider...Most of the work we've done in porting MUMPS makes more sense as a standalone MUMPS wrapper. [pymumps](https://github.com/bfroehle/pymumps) is a related project, that implements a smaller subset of MUMPS interface. We could also consider using the way scipy wraps BLAS and LAPACK a model approach.Kwant 1.5https://gitlab.kwant-project.org/kwant/kwant/-/issues/23Consistent separation of left-, right-propagating and evanescent modes2020-09-29T18:54:10ZAnton AkhmerovConsistent separation of left-, right-propagating and evanescent modesRight now if a new propagating mode opens, Kwant may count one mode out of the pair as propagating, another one as evanescent due to numerical errors. It should be relatively easy to enforce consistency by using that evanescent modes alw...Right now if a new propagating mode opens, Kwant may count one mode out of the pair as propagating, another one as evanescent due to numerical errors. It should be relatively easy to enforce consistency by using that evanescent modes always come in pairs `λ` `1/λ^*`.
The relevant code is in the `make_proper_modes` function [over here](kwant/physics/leads.py#L405).Kwant 1.5Anton AkhmerovAnton Akhmerovhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/8Consistent linking/naming in documentation2018-09-20T07:55:28ZAnton AkhmerovConsistent linking/naming in documentationWe could adopt the scheme that is used in Python's stdlib. See for example
http://docs.python.org/3/library/threading.html
This would mean:
- When referring to functions, we always append "()" to their name.
- Names of objects (...We could adopt the scheme that is used in Python's stdlib. See for example
http://docs.python.org/3/library/threading.html
This would mean:
- When referring to functions, we always append "()" to their name.
- Names of objects (types, functions, ...) that are a documented part of
Kwant are always hyperlinks _when_ the object itself is meant.
- Concepts that are meant in a more general sense are not hyperlinked, even if
there exists an object of the same name in Kwant. (Consider the usage of
linking for the term "Thread" in the document linked above.)
Kwant 1.5