kwant issueshttps://gitlab.kwant-project.org/kwant/kwant/-/issues2024-01-09T20:07:17Zhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/368Using smatrix on a system with a SelfEnergyLead fails2024-01-09T20:07:17ZJoseph WestonUsing smatrix on a system with a SelfEnergyLead failsI don't have time to make an example right now, but if you construct a system that has a `kwant.builder.SelfEnergyLead` as one of the leads, and call `kwant.smatrix` on it Kwant will raise an `AttributeError` because the `SelfEnergyLead`...I don't have time to make an example right now, but if you construct a system that has a `kwant.builder.SelfEnergyLead` as one of the leads, and call `kwant.smatrix` on it Kwant will raise an `AttributeError` because the `SelfEnergyLead` does not have a `modes` method.
IMO this is a bug. As long as you have at least 1 lead that has `modes`, I would expect everything to work.
A naïve fix is simple: simply evaluate the self-energy of the lead and add it to the scattering region Hamiltonian.
What is a bit trickier is how to handle lead numbering. Imagine I had 3 leads attached (0, 1, 2) and lead 1 is a self-energy lead.
When asking for submatrices of the scattering matrix we would be "unable" to use lead index 1, as we have no way of getting the scattering matrix elements to the SelfEnergyLead (because it does not have `modes` defined).
What we could do is raise an exception if `smatrix` is used and there is a `SelfEnergyLead` and no `in_lead` and `out_leads` have been provided, notifying the user that they must specify this, omitting the self-energy lead. AFAICT this would solve the numbering problem.https://gitlab.kwant-project.org/kwant/kwant/-/issues/63Be more consistent in dependency specification2020-12-14T10:37:35ZAnton AkhmerovBe more consistent in dependency specificationKwant >=1.2 depends on python v3.4 released March 16th, 2014. At that time the following versions of scipy libraries already existed:
* matplotlib v1.3.1 (but we don't support it due to bugs).
* scipy v0.13.3.
* numpy v1.8.1.
The...Kwant >=1.2 depends on python v3.4 released March 16th, 2014. At that time the following versions of scipy libraries already existed:
* matplotlib v1.3.1 (but we don't support it due to bugs).
* scipy v0.13.3.
* numpy v1.8.1.
The dependencies we list in setup.py are:
* mpl >=1.2.
* scipy >=0.11.0
* numpy > 1.6.1.
An obvious improvement would to bump all of these versions, but we can also consider being more proactive in increasing the dependencies if there is something to be gained.
EDIT: fixed the version numbers (I wasn't thorough enough checking them initially), and slightly rephrased the description.https://gitlab.kwant-project.org/kwant/kwant/-/issues/302Minimally invasive vectorization of Kwant2020-10-23T15:46:27ZChristoph GrothMinimally invasive vectorization of KwantHere's a plan to vectorize Kwant with a minimal amount of changes. The idea is that this is something that can be coded quickly, but is still very useful, and comprises a useful step forward towards more generalized systems/operators.
...Here's a plan to vectorize Kwant with a minimal amount of changes. The idea is that this is something that can be coded quickly, but is still very useful, and comprises a useful step forward towards more generalized systems/operators.
In the following, I only speak about finite systems. Infinite systems should be a straightforward generalization.
Vectorization of low-level systems
----------------------------------
A kwant (low-level) system provides two things:
(1) A graph whose nodes (=sites) and edges (=hoppings) are densely numbered, each starting with zero.
(2) A way to obtain an element of the Hamiltonian matrix that is identified by two site indices and may further depend on system parameters.
I propose to extend the low-level system API in the following way:
- We introduce numbered "value kinds". (I'm looking for a better name, how about "part"? I don't want to say "term", because of the limitation that each site/hopping belongs only to one value kind.) Each site and each hopping has exactly one value kind associated with it. This association is exposed by the API in two ways: two arrays that store the value kind index for each site and hopping, and for each value kind, a sequence of the associated site/hopping indices.
(We probably want to restrict a given value kind to either sites or hoppings. We even might have two separate numberings, one for site value kinds and one for hopping value kinds, but then, we may also have a single common numbering. This is a detail to be discussed.)
- We add a new method that allows to query a single value kind in a vectorized way for all the associated sites/hoppings at once. That method takes the value kind index, and system parameters. It returns a dense 3D array of the shape (n, a, b) where n is the number of sites/hoppings that share the value kind, and (a, b) is the size of the matrix element. Obviously this implies that all values that share the same kind have the same matrix shape (for the same parameters).
- For each value kind, we list the necessary parameters.
Observe that the above allows to implement `hamiltonian_submatrix` efficiently. It also preserves the numbering of sites and hoppings, so that existing user scripts continue to work unchanged.
Still, to simplify our lifes, we might want to deprecate `hamiltonian_submatrix`, and even break support for calling it in the fully general way. In practice, `hamiltonian_submatrix` is either called for the full system, or for the unit cell and the inter-cell hopping of a lead.
Vectorized finalized builders
-----------------------------
How to implement the above API for finalized builders?
We introduce a new `SiteArray` class that associates multiple tags with a single site family. It's API is like the one of `Site`, but in plural (except for `family`). So, there's `tags`, and `positions` that each return a sequence. Note that for the common Bravais lattices, both `tags` and `positions` can return a single dense 2D array of numbers.
From the user's perspective, vectorized builders are created in exactly the same way. The only difference is that value functions receive `SiteArray` instances instead of `Site`, and return arrays of values. In addition, vectorization needs to be enabled somehow. This could be done with a global switch, e.g. by calling `kwant.vectorize()`.
Of course finalized builders have to provide the new vectorized low-level system API as well as the old one. Observe that providing the old one, i.e. the `hamiltonian` method poses no problem. We can keep the old code and only adapt it very slightly to call vectorized value functions with site arrays of length one.
The vectorized evaluation interface can be also provided efficiently. Note that builder is free to classify values as value kinds within the constraints imposed by the low level system API (i.e. compatible matrix sizes). So, it makes sense to classify as one value kind all sites or hoppings that share the same value function *and* in addition share the same site family (pair). For example, for graphene with one kind of onsite value function and one hopping value function, there will be two kinds of onsite values (one for each site family), and one or two types of hopping kinds. (That depends on whether the user has specified only A->B kind of hoppings or also B->A hoppings. IIRC builder will remember the one that has been set.) The Hermitian conjugate opposite hoppings can be treated with the same approach as currently.
Constant values of the same shape that are defined on the same site families should be probably also classified as a single kind of value. If we want, we can treat the case where all of the matrices are equal specially, for example by adopting a storage convention that is similar to NumPy's broadcasting, i.e. instead of storing 100 times the same onsite matrix (`[M, M, M, ...]`) we store it just once (`[M]`) in a sequence of length 1.
Vectorized low-level systems should expose a `site_arrays` attribute that contains a sequence of `SiteArray` instances, that contains the same information as `sites` today, but using drastically less Python objects. The old `sites` attribute will continue to exist for backwards compatibility, but it could be made to create site objects on-demand, so that they don't have to be stored.
So, when the request arrives (by the low-level API) to evaluate the Hamiltonian for a given value kind, the finalized builder has to get hold of the necessary site arrays before it can call the user-provided value function. These can be built on-demand efficiently by a piece of Cython code or perhaps even by clever usage of NumPy.
Comments
--------
The above does not include any vectorization of the `Builder` class, that still contains a dictionary with individual sites as keys. So construction and finalization of builders won't be any faster. Speeding up builders is a separate project.
I wrote here previously:
> We can consider making `Site` a derived class of `SiteArray`.
I no longer think that this is a good idea. Instead, it seems much more natural and useful if site arrays are (fancy-indexable) sequences of sites. (However, exposing the sequence API is something that is optional and can be postponed.) This means, that unlike sites, site arrays should not be two-tuples of family and tag(s).
`SiteArrays` and `Sites` could be moved to `kwant.system` at this occasion.
If we want to implement the code that assembled the `SiteArrays` upon evaluation of a finalized builder in Python using NumPy, we may have to modify the internals of `graph.CGraph`, at least such that it exposes the arrays it stores as NumPy arrays. Currently the arrays are simply C pointers to memory. That was not done initially, because of limitation of Cython that have disappeared since. It can well be that the `graph` submodule can be drastically simplifed or even replaced by something else.https://gitlab.kwant-project.org/kwant/kwant/-/issues/379Remove link to INAC website2020-05-13T15:37:22ZJoseph WestonRemove link to INAC websiteThe link to @waintal's homepage is [causing the linkcheck build step to fail](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/120706).
It seems that http://inac.cea.fr is down and has been for a few weeks. We should either point to ...The link to @waintal's homepage is [causing the linkcheck build step to fail](https://gitlab.kwant-project.org/kwant/kwant/-/jobs/120706).
It seems that http://inac.cea.fr is down and has been for a few weeks. We should either point to Xavier's actual homepage or remove the link.https://gitlab.kwant-project.org/kwant/kwant/-/issues/249Design for Plotly plotter2019-12-20T09:56:34ZJoseph WestonDesign for Plotly plotterThis issue is a summary of the discussions had between @kel85uk and @jbweston, @anton\-akhmerov, and @michaelwimmer.
Any interested parties should comment on the appropriate threads belowThis issue is a summary of the discussions had between @kel85uk and @jbweston, @anton\-akhmerov, and @michaelwimmer.
Any interested parties should comment on the appropriate threads belowPlotly PlotterKelvin LohKelvin Lohhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/190Add Kwant to Zenodo2019-03-01T16:37:02ZJoseph WestonAdd Kwant to Zenodo[Zenodo](https://zenodo.org/) allows us to get DOIs for Kwant releases.
Publishing Kwant releases there will be helpful for reproducible computing, as people may cite the exact Kwant release that they used.
It is a bit of manual work t...[Zenodo](https://zenodo.org/) allows us to get DOIs for Kwant releases.
Publishing Kwant releases there will be helpful for reproducible computing, as people may cite the exact Kwant release that they used.
It is a bit of manual work to fill in all the fields, but the only unanswered question is whether to open a new account on that platform (and then somehow share the credentials between the authors).Kwant 1.4https://gitlab.kwant-project.org/kwant/kwant/-/issues/241Make system parameter names a public API2019-02-14T16:17:07ZAnton AkhmerovMake system parameter names a public APIParameters are great, let's have more of them!
Specifically, we could make the system parameters more discoverable by considering the parameters that the system depends on a public property. The implementation would be as easy as loopin...Parameters are great, let's have more of them!
Specifically, we could make the system parameters more discoverable by considering the parameters that the system depends on a public property. The implementation would be as easy as looping over the `onsites` and `hoppings` and doing a set join on these.
We could then use those to provide a rich representation, e.g. `system with 2 leads and 100 sites that depends on ('mu', 't')`.Kwant 1.4Joseph WestonJoseph Westonhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/242Improve symmetry interface2018-11-26T13:07:38ZAnton AkhmerovImprove symmetry interfaceRight now verifying that the discrete symmetry is broken requires some low-level code:
```python
sym = syst.discrete_symmetry(params=params)
h = syst.hamiltonian_submatrix(sparse=True, params=params)
# replace with "h = syst.cell_hamilt...Right now verifying that the discrete symmetry is broken requires some low-level code:
```python
sym = syst.discrete_symmetry(params=params)
h = syst.hamiltonian_submatrix(sparse=True, params=params)
# replace with "h = syst.cell_hamiltonian(...); t = syst.inter_cell_hopping(...)"
# if the system is infinite
sym.validate(h)
```
Because this is one of the important operations, we should probably simplify it.https://gitlab.kwant-project.org/kwant/kwant/-/issues/237name of Builder.substitute2018-10-12T17:55:55ZAnton Akhmerovname of Builder.substituteThe method name `Builder.substitute` may give an impression that the parameter name substitutions are done in-place. Instead this operation returns a copy (as it probably should).
We should *consider* if there is a less ambiguous name b...The method name `Builder.substitute` may give an impression that the parameter name substitutions are done in-place. Instead this operation returns a copy (as it probably should).
We should *consider* if there is a less ambiguous name before %"Kwant 1.4".Kwant 1.4Anton AkhmerovAnton Akhmerovhttps://gitlab.kwant-project.org/kwant/kwant/-/issues/141Color sites by family by default in 'kwant.plot'2017-09-14T10:32:59ZJoseph WestonColor sites by family by default in 'kwant.plot'This will provide more information in the default plot.
This could be implemented in 2 ways:
1. Assign site families colors in the order that they come out of the system (i.e. the first time a new site family is seen
it is assigned ...This will provide more information in the default plot.
This could be implemented in 2 ways:
1. Assign site families colors in the order that they come out of the system (i.e. the first time a new site family is seen
it is assigned the next color in some sequence)
2. First sort the site families, then assign them colors
The advantage of first sorting is that identical systems constructed in 2 different ways (imagine adding sites from family A before those from B, then another system doing the reverse)
will have the same site coloring, however we would have to iterate over the sites first (`O(N)`) in order to get all the site families.https://gitlab.kwant-project.org/kwant/kwant/-/issues/148Polyatomic lattices could automatically create attributes (a, b, c, etc.) for...2017-07-20T15:22:44ZChristoph GrothPolyatomic lattices could automatically create attributes (a, b, c, etc.) for all of their sublatticesSo far, this feature is only provided by the likes of `kwant.lattice.honeycomb()`, but I guess it would be useful generally, and probably it wouldn't hurt. It would be also easier to explain. Does anyone see any problems with this? If...So far, this feature is only provided by the likes of `kwant.lattice.honeycomb()`, but I guess it would be useful generally, and probably it wouldn't hurt. It would be also easier to explain. Does anyone see any problems with this? If, for example, there is some lattice whose sublattices are habitually called X and Y, this could be confusing.https://gitlab.kwant-project.org/kwant/kwant/-/issues/108Interface compatibility between Lattice.shape and Builder.fill2017-05-11T15:20:59ZViacheslav OstroukhInterface compatibility between Lattice.shape and Builder.fillThere were two minor changes in interface:
- `lat.shape` accepts real-space position in shape function, `builder.fill` accepts site. This is a good change, as for me, and allows shorter code in some cases. However, it may be reasonable t...There were two minor changes in interface:
- `lat.shape` accepts real-space position in shape function, `builder.fill` accepts site. This is a good change, as for me, and allows shorter code in some cases. However, it may be reasonable to keep backward compatibility and check type of an argument for the purpose of not annoying users (at least before issuing Kwant 2).
- `lat.shape` accepted real-space position of an origin for flood-fill, `builder.fill` accepts site tag. When (0, 0) can't be chosen as an origin, user has routinely to use something like:
```python
lat = next(iter(proto.sites())).family
start = lat.closest((x0, y0))
```
I don't see any good reason for not doing this automatically in `kwant.Builder.fill` method and keep old-style interface.Kwant 1.3