Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internalized Bloch matrix #105

Closed
wants to merge 2 commits into from
Closed

Internalized Bloch matrix #105

wants to merge 2 commits into from

Conversation

pablosanjose
Copy link
Owner

This change removes all the similarmatrix API. Having to allocate a matrix before being able to have a reusable bloch! is cumbersome. This PR partially restores the older design changed in pablosanjose/Elsa.jl#28

The similarmatrix is allocated upon creating a hamiltonian and its type can now be controlled with the keyword blochtype. We can thus have a multiorbital h::Hamiltonian that carries inside a flat blochmatrix to be returned when calling bloch!(h, ...). To avoid allocating such a matrix at each step of any transformation, we carry over the same matrix at any transformation step that preserves its size and eltype.

We can then now do

h = LatticePresets.honeycomb() |> hamiltonian(hopping(I), orbitals = (Val(2), Val(1)), blochtype = Matrix{ComplexF64})
bloch!(h, (1,2)) # returns a flattened 3x3 Matrix{ComplexF64}

We have also the special syntax

h = LatticePresets.honeycomb() |> hamiltonian(hopping(I), orbitals = (Val(2), Val(1)), blochtype = flatten)
bloch!(h, (1,2)) # returns a flattened 3x3 SparseMatrixCSC{ComplexF64}

Together with this we can also change the blochtype of a Hamiltonian or ParametricHamiltonian h with

hamiltonian(h; blochtype = newtype)

Another benefit is that we get rid of the pesky optimize! function. The (Parametric)Hamiltonian harmonics don't need to pre-store any structural zeros to avoid sparse splicing. We just optimize the internalized blochmatrix upon creation, in accordance with the elements of all harmonics (function _similar_merged_sparse now).

This opens the door to having h(ϕs; params...) as a shorthand for bloch(h(; params...), ϕs), or even bloch!(h(; params...), ϕs). This is not implemented here yet, but could be used to even stop exporting bloch and bloch!. Even further, h(not_all_phis; params...) could even replace wrap, but that's another issue.

@codecov-commenter
Copy link

codecov-commenter commented Sep 29, 2020

Codecov Report

Merging #105 into master will decrease coverage by 0.04%.
The diff coverage is 86.11%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
- Coverage   62.37%   62.32%   -0.05%     
==========================================
  Files          16       16              
  Lines        2708     2734      +26     
==========================================
+ Hits         1689     1704      +15     
- Misses       1019     1030      +11     
Impacted Files Coverage Δ
src/Quantica.jl 100.00% <ø> (ø)
src/greens.jl 0.00% <ø> (ø)
src/model.jl 72.66% <ø> (ø)
src/plot_vegalite.jl 0.00% <0.00%> (ø)
src/tools.jl 56.54% <75.00%> (-0.91%) ⬇️
src/diagonalizer.jl 52.71% <81.81%> (-1.43%) ⬇️
src/hamiltonian.jl 74.76% <84.55%> (-0.20%) ⬇️
src/KPM.jl 64.80% <100.00%> (ø)
src/bandstructure.jl 91.15% <100.00%> (-0.06%) ⬇️
src/lattice.jl 81.59% <100.00%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 743b928...28e52f1. Read the comment docs.

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