Avoiding dangling bonds about quantica.jl HOT 4 CLOSED

Actually, it might be easier than we said. It might be possible to support a neighbors kwarg in SiteSelectors.

Currently, a s::SiteSelector undergoes a resolve process that combines s with a Lattice to find out the indices of sublattices passed by name. That produces a rs::ResolvedSelector{<:SiteSelector} that bundles the lattice with it, which is needed to compute in((siteindices, dns), rs). What we could do is generalize ResolvedSelector to bundle either a lattice or a Hamiltonian, so that neighbors = not(1) could work (using the Hamiltonian's connectivity) as long as we have bundled a Hamiltonian, not a Lattice (i.e. as long as the selector was passed to a unitcell(h::Hamiltonian,...) instead of a unitcell(l::Lattice,...)).

EDIT: when working with a Lattice I would say neighbors should never restrict the selector, regardless of its value.
EDIT2: Actually, it might even be better to emit an error if the user specifies any neighbors in a selector when using it with a Lattice instead of a Hamiltonian.

from quantica.jl.

Upon further reflection I'm starting to think that your original proposal (i.e. have neighbors be a kwarg specific to unitcell(::Hamiltonian,...;...)) is actually best. The very fact that putting neighbors into SiteSelectors forces the feature to work only in certain cases is a strong hint of a wrong design. SiteSelectors should select only based on properties of sites, i.e. their position and sublattice, nothing else. Given that SiteSelectors drive so much functionality throughout Quantica, their behaviour should remain highly composable, so exceptions are bad.

Note that the method unitcell(::Hamiltonian,...) already has a specific kwarg (modifiers) that is not present in any other unitcell method (because it only makes sense when transforming a Hamiltonian). Adding neighbors also as an additional kwarg, as @fernandopenaranda suggests, would keep this functionality localized to where it makes sense.

from quantica.jl.

It turns out this does not always have the solution one might expect.

If I say, unitcell(h, neighbors = not(1)) in a 2D lattice, this has a well defined solution, since removing a dangling site does not produce (typically) another dangling site (unless there is an open 1D subchain in the lattice). However, if I say unitcell(h, neighbors = not(2)) in a 2D lattice, for example, each 2-neighbor site removed will often produce new sites with 2 neighbors. So solving this in general, as posed, requires some iterative passes over the lattice, removing matching sites on each pass. The end result, doing it this way, is unique, but is probably difficult to predict. However, since the code for neighbors = not(1) and the general neighbors = ... is very similar, it makes sense to support the full range of possibilities (not just a removedanglingbonds = true)

from quantica.jl.

I concluded that having arbitrarily complex neighbors values (like neighbors = (1, not(2), 4:6)) was pointless, since the resulting lattice is impossible to anticipate in practice. The PR #131 focuses on just reducing the number of dangling sites on surfaces, so it just accepts a mincoordination::Int kwarg. While simpler, this is still more powerful than simply neighbors = not(1), and I expect it covers better the typical usecase. If somebody needs something more general than #131 do reopen this issue or open a new one.

from quantica.jl.