Wannier90 import

[pablosanjose]

Closes #4

This adds support for importing Wannier90 tight-binding models from a file. By constructing an intermediate WannierBuilder object (building on #261), we can hook into the full Modifier machinery, and also combine Quantica.jl models and Wannier90 models, with or without parameters. We can then obtain an AbstractHamiltonian or a position operator (of type BarebonesOperator)

Quick example: add a Wannier90 model in a file to a @onsite((; k = 1) -> k*o) parametric model. (The latter could be omitted, of course).

julia> w = wannier90("wannier_tb.dat", @onsite((; k = 1) -> k*o); dim = 2)
WannierBuilder{Float64,2} : 2-dimensional Hamiltonian builder of type Float64 from Wannier90 input
  cells      : 151
  elements   : 7560
  modifiers  : 1

julia> h = hamiltonian(w)
ParametricHamiltonian{Float64,2,2}: Parametric Hamiltonian on a 2D Lattice in 2D space
  Bloch harmonics  : 151
  Harmonic size    : 10 × 10
  Orbitals         : [1]
  Element type     : scalar (ComplexF64)
  Onsites          : 10
  Hoppings         : 7540
  Coordination     : 754.0
  Parameters       : [:k]

julia> R = sites(w)
BarebonesOperator{2}: a simple collection of 2D Bloch harmonics
  Bloch harmonics  : 151
  Harmonic size    : 10 × 10
  Element type     : SVector{2, ComplexF64}
  Nonzero elements : 7550

julia> R[cellsites(SA[0,0], 1), cellsites(SA[0,0], 4)]
2-element SVector{2, ComplexF64} with indices SOneTo(2):
  2.4885857e-5 + 0.018543702im
 -0.0053425408 + 1.8808481e-5im

We can now build a new Hamiltonian that includes an electric field, coupled through the actual R operator

julia> hE = h |> @onsite!((o, i; E = SA[0,0]) --> o + E'*R[i,i]) |> @hopping!((t, i, j; E = SA[0,0]) --> t + E'*R[i,j])
ParametricHamiltonian{Float64,2,2}: Parametric Hamiltonian on a 2D Lattice in 2D space
  Bloch harmonics  : 151
  Harmonic size    : 10 × 10
  Orbitals         : [1]
  Element type     : scalar (ComplexF64)
  Onsites          : 10
  Hoppings         : 7540
  Coordination     : 754.0
  Parameters       : [:E, :Δ]

Note the use of the new --> syntax for nonspatial models and the use of R indexing (since we don't want to couple to r and dr as we'd do with point-like orbitals)

CC: @BacAmorim

[pablosanjose]

A somewhat inelegant part of this PR is the introduction of a second Operator type. We have Operator, which is essentially a wrapped Hamiltonian, and now BarebonesOperator, which is essentially a bunch of sparse Bloch Harmonics of arbitrary eltype. The second is not a subset of the first, and viceversa. Element types of Operators are only scalars or matrices over orbitals (for multiorbital systems), just as Hamiltonians. A BarebonesOperator on the other hand is decoupled from a Lattice and all the multiorbital machinery, but in exchange it can have an arbitrary element type. Here, for example, it can be an SVector.

A case could be made that Operator should not exist, only BarebonesOperator. Something like current(h; direction = 1), which is now an Operator, could just as well become a BarebonesOperator, and would at the same time allow it to be a current vector on each hopping. If we were to do this, BarebonesOperator would be renamed to Operator (perhaps including also the Lattice inside it), and the oldOperator as a Hamiltonian wrapper would disappear.

[pablosanjose]

Some changes are required here

• Move wannier90 to ExternalPresets.wannier90, to allow other importers in the future
• fix Documenter pass so that the submodule docstrings get inserted in manual
• change sites(w) to position(w), and have position be analogous to current in the future (both should produce an Operator -> but that's for another PR)
• fix a path in failing test
• consider allowing different dim = E and latdim = L in importer

Some caveats

• supercell(r, ...) doesn't work, of course. If we do supercell(h, ...) then we cannot use it with the same r.

The caveat could be solved if we refactor Operator to be a container of harmonics with any matrix type, and then make it the core of Hamiltonian (for HybridSparseArrays as special matrices). Then make supercell operate on any operator. This would be a fairly major refactor.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.96403% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 92.44%. Comparing base (526cb05) to head (6b8bbdf).
Report is 3 commits behind head on master.

Files	Patch %	Lines
src/presets/external.jl	95.78%	4 Missing ⚠️
src/types.jl	88.00%	3 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
+ Coverage   92.29%   92.44%   +0.14%     
==========================================
  Files          36       37       +1     
  Lines        5931     6059     +128     
==========================================
+ Hits         5474     5601     +127     
- Misses        457      458       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.