Roughly in order of importance. -*-org-*- * Fix lattice.neighbors() when lattice has lower dimensionality than the space. * Document the order of sites/orbitals in finalized builders * Add calculation of current density * Re-design the interface of low level systems considering the following - We want support for multiple symmetry directions - Consider making System.hamiltonian a vectorized function. Value functions should be vectorizable as well (when marked with a decorator?) - Consider using two-way-compressed uni-directional graphs in systems advantages: - The number of edges gets reduced by 1/2. - The Hermicity of the Hamiltonian is enforced in a more obvious way. - It's clear at system level which Hamiltonian elements are defined directly. - Verify that the graph slicing algorithm continues to work. * Improve experience when working with sites in a finalized builder (It should be possible to map sites to nodes efficiently. Probably, the best way to do it is to sort the sites in finalized builders.) One could then also RLE compress sites in finalized builders. * Make Kwant objects pickleable * Implement "inhomogeneous arrays" for ldos and wavefunc The point is to have ldos or wavefunc return objects that behave like 2d arrays, where the site index and orbital index are separate. However, this must work in the general case where the number of orbitals per site varies. * Go through the documentation and apply consistent linking/naming practice: We could adopt the scheme that is used in Python's stdlib. See for example http://docs.python.org/2/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.) * Plotter: show site upon click * fix physics.noise (docstring, __all__, etc.) * Verify that selective plotting works. * Write an RGF solver that uses graph/slicer. * Add support for easily adding magnetic field to a system. * Allow plotting of infinite systems * Use sparse linear algebra to calculate bands However, SciPy's sparse eigenvalues don't seem to work well. * Allow attaching leads with further than nearest lead unit cell hoppings. The most easy way to do this is increasing the period of the lead. Alternatively, generalize modes and InfiniteSystem format. * In finalized leads, only keep the sites of a single lead unit cell. * Add support for optimization of lead fundamental domains. * Incorprorate efficient correlated disorder using scipy.spatial. * Implement the C solver interface. * Wrap TB_SIM as a solver. * Benchmark MUMPS and check whether nested dissection would be useful. If yes, implement it. * Consider implementing "models" module, incorporate units into it. - It is potentially related to vectorized value functions (since modesl are spatially homogeneous) - It may also be related to units, which we may borrow from somewhere, or implement on our own. * Improve handling of s-matrices with important additional degrees of freedom. i.e. spin, or electron-hole. Currently, one needs to manually process lead modes and to perform a basis transformation of the scattering matrix. * Implement automatic search for discrete symmetries of a tight binding model and of conservation laws. * Revisit Symmetry, make it more general. I.e. allow for description of other discrete symmetries, possibly also symmetries which change site and hopping values (=gauge symmetries). * Make an option for plotting hoppings as arcs, in order for overlapping hoppings to be distinguishable. Also potentially add arrows to the hoppings. * Adopt mincut/maxflow algorithm from networkx or python-graph to find the best representation of a lead unit cell. * Speed up kwant.digest by using SipHash and Ziggurat algorithm in C/Cython * Improve finding of modes with zero velocity or infinite decay length Right now a mode with truly zero velocity may be incorrectly identified as propagating or evanescent. * Remove sphinxext and use an external numpydoc once it is available