Ensure ordering of band vertices for 1D bands and cuts about quantica.jl HOT 7 CLOSED

@pablosanjose said in #64:

In general the band-extraction algorithm returns vertices in the order resulting from an adjacent neighbor search

So the band-exctration algorithm does not use the adjacency matrix in a mesh?

from quantica.jl.

Yes, it uses the adjacency matrix of the mesh to search for the next possible vertex. When the first vertex has two neighbors (closed mesh) this launches two search directions, forward and backward, which is the reason why you see bands in a zig-zag pattern

from quantica.jl.

I was trying the sort idea, but came across a problem that could be more complicated that anticipated. When extracting bands in dimensions higher than one, the search algorithm explores the k mesh, back and forth, connecting any point in any subband into the same band, if they are connected. That results in graphene's bandstructure, for example, to end up with a single band (because valence and conduction are actually linked at the Dirac point). In 1D a similar thing happens if we use a closed LinearMesh, since a band can connect with other bands at the Brillouin zone boundary. Hence, a folded 1D band of a single orbital 1D lattice h = LatticePresets.linear() |> hamiltonian(hopping(1)) |> unitcell(3) , for example ends up with 3 bands if we use bandstructure(h, linearmesh((0,0), (2pi, 0))) but only one if bandstructure(h, linearmesh((0,0), (2pi, 0), closed = true))

This is all fine and well, and works as expected. The problem comes when plotting. In the former case we have this

In the latter case the single band is not a biyection between momentum and energy, but actually includes all 3 energies for a given momentum. There is no way to plot that as a continuous line by sorting the momenta.

In 2D we don't have this problem because we just plot simplices, which in 1D would be segments between adjacent momenta. We could do the same in 1D, but perhaps a nicer approach can be found that is compatible with the typical plot workflow, as exemplified by @BacAmorim in #64

from quantica.jl.

Do we actually need closed 1D paths? The only case where a closed path might be relevant is for the evaluation of Zak phases maybe (I have never done that, so I am guessing a bit).

But, certainly we do not need closed paths for plotting, which was my initial motivation for proposing what became linearmesh. With open paths, ploting works just fine (am I missing something?). So maybe it is only necessary to document that for plotting open paths should always be used.

from quantica.jl.

Well, to be honest, I only included that because you were using it :-D. In any case, it doesn't hurt having it, and I wanted to generalize it at some point to D>1. The default is closed=false anyway.

from quantica.jl.

Well, I don't actually have a use for closed paths :p But you are correct. Since it defaults for false we can leave it there.

from quantica.jl.

I guess that, since the current behavior for open 1D paths where ordering can be defined unambiguously is already working as expected, and since the other case of closed 1D paths doesn't seem to have a well-defined answer, I'm going to close this issue as currently non-actionable. We can reopen it later if we define the expected goal better.

from quantica.jl.