Skip to content

Generalize implementation to treat non-Hermitian models#106

Merged
thchr merged 12 commits into
mainfrom
nonhermitian
May 22, 2026
Merged

Generalize implementation to treat non-Hermitian models#106
thchr merged 12 commits into
mainfrom
nonhermitian

Conversation

@thchr

@thchr thchr commented Apr 10, 2026

Copy link
Copy Markdown
Collaborator

This allows us to build non-Hermitian tight-binding models via tb_hamiltonian(cbr, Rs, Val(NONHERMITIAN)).

There's some restructuring of the various structs here to encode the kind of hermiticity a model has in the type domain, so that we can be guaranteed that spectrum type-stably returns Float64 in the Hermitian case. Aside from that, it's actually mainly a matter of removing assumptions about hermiticity.

Pushing early (WIP; docs e.g., are not yet done), to see what docs and CI look like.

Copilot AI review requested due to automatic review settings April 10, 2026 14:49

This comment was marked as resolved.

@codecov

This comment was marked as resolved.

thchr added 2 commits April 12, 2026 22:53
- also a fix for an error in the docs CI (add a docstring for `TightBindingTerm`)
thchr added 2 commits April 14, 2026 16:43
…k` for multiple/single **k**-points

- `spectrum_single_k` now handles case where a *single* **k**-point is provided and `spectrum` is strictly for *multiple* of **k**-points
- by splitting up like this, we also enable the introduction of convenience method for 1D models, using `spectrum(..., ks)`  with a plain (abstract) vector of real numbers; this is just much nicer in day-to-day use.
@thchr thchr force-pushed the nonhermitian branch 3 times, most recently from a6b4e52 to 9cb8eea Compare April 17, 2026 09:38
@thchr

thchr commented Apr 17, 2026

Copy link
Copy Markdown
Collaborator Author

Seems to work well now; there's some examples in the preview docs.

A few things that would still be good to do before merging:

  1. The WIP SSH chain example in the docs should get some more explanation / tidying up.
  2. More docs examples: especially anything nontrivial at the intersection of symmetry and non-hermiticity.
  3. Maybe supplying Rs should be automatically supplemented with -Rs in the non-Hermitian case. Basically, even though the orbits are not necessarily related without hermiticity, it's strange to return terms that might only include one element of a pair of hermiticity related terms. An example is the 6th term of tbm_NH in the p4 docs section.

This comment was marked as resolved.

@thchr thchr force-pushed the nonhermitian branch 3 times, most recently from 0824582 to ecc22df Compare April 20, 2026 12:28
thchr added 6 commits April 21, 2026 16:53
- mainly, this is a matter of lifting 1D properties (points and unit cell boundaries) to 2D points

- while there, we also fix a few old bugs (e.g., the fact that `context.limits` was not properly propagated, which made visualization of model terms with different extents display in a way where their overall extent was not comparable)

- co-developed with Claude
- also fix some writing that referenced terms hopping the opposite way relative to what they actually did

- extend non-Hermitian SSH  example a bit
…ired"

- This ensures that every term in a nonhermitian TB model has a counterpart that
  it would be mapped to under Hermitian conjugation. This is just much more natural
  and aligned with what a user would expect. The issue only arose for diagonal
  blocks of a Hamiltonian, with the canonical case being e.g., a (2c|A) EBR model
  in p4.

- This also fixes a related issue, arguably a bug, in the (ANTI)HERMITIAN case,
  where some orbits weren't sufficiently "wide" (not enough hopping terms) to
  close under (anti-)Hermiticity, unless `Rs` was provided in such a way that for
  every positive element `R` there was also a negative element `-R`.
  We fix this by explicitly checking in `add_reversed_hoppings!` whether
  for every a→b+R term of separation δ, there is a corresponding b→a-R term at
  separation -δ.
@thchr

thchr commented May 22, 2026

Copy link
Copy Markdown
Collaborator Author

I will merge this as-is now Antonio: I've tested the new functionality in a number of ways and I'm confident it's sound.

There are also a few fixes and improvements that aren't related to the non-Hermitian aspect: but they're all in their own separate commits. So I'll merge without squashing.

@thchr thchr changed the title WIP: Generalize implementation to treat non-Hermitian models Generalize implementation to treat non-Hermitian models May 22, 2026
@thchr thchr merged commit 2c0990d into main May 22, 2026
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants