Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • kwant kwant
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 142
    • Issues 142
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 19
    • Merge requests 19
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • kwant
  • kwantkwant
  • Issues
  • #378
Closed
Open
Created May 08, 2020 by Anton Akhmerov@anton-akhmerovOwner

support finalization and attaching of ND systems

Current status

  • Vectorized low level systems store similar sites in SiteArrays, and similar terms of the Hamiltonian in syst.terms.
  • With respect to translation symmetries, the data format of terms is correct (each term stores the associated symmetry element),
  • Finalization uses site ordering enforced by the interface. This is impossible or hard to generalize symmetries that are more than 1D.
  • When attaching a lead we compute the interface—sites that are connected to the lead by a hopping.
  • A finalized system stores lead_interfaces—the indices of its low level sites that match the indices of the extra sites of the lead in the same order.

Goals

  • We want to be able to finalize systems with ND translations, and therefore we won't be able to enforce a specific ordering on the sites.
  • We still want to be able to attach the leads (duh).
  • At this point we want to keep the logic of builder the same (attaching leads by flood fill).

Proposal

I think the apparent incompatibility between the goals is achieved by this format change:

Change lead_interfaces to be a mapping between the scattering region sites and the lead sites that only includes the sites that are connected by a hopping, instead of relying on the ordering of the sites in the infinite system.

Change lead_interfaces to be a 2D array of site numbers in the scattering region that correspond to specific sites in the lead unit cell upon translation by k symmetry vectors of the lead. In other words if interface[n, k] == i, that means that i'th site of the scattering region corresponds to the n'th site of the lead upon translation by k+1 lead symmetry vectors that aren't shared by the system. A value of -1 in the interface indicates that there is no site in the system that corresponds to the n'th site of the lead upon translation by k+1 lead symmetry vectors. Finally, interface.shape == (N_lead_sites, max_hopping_range).

  1. This means that we finalize the systems without taking the interface into account (already a simplification), and have the same ordering of sites regardless of how the lead was attached.
  2. When computing the new format for the lead_interfaces we only need a single lookup (something like searchsorted).
  3. In principle this means that attaching a 2D lead to a 1D scattering region becomes legal (although we must specify which generator to use for the remaining 1D symmetry).
Edited May 08, 2020 by Anton Akhmerov
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking