Add 32bit support for GreenFunctions #238
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes JuliaLang/julia#236
Although Quantica is coded for a generic
T<:AbstractFloat
, the GreenFunction part was not tested forT == Float32
, only forT == Float64
. Doing so revealed a number of issues, which are fixed in this PRGreenSolvers.SparseLU
, which relies on UMFPACK, does not supportComplexF32
eltypes yet, so we must internally work withComplexF64
, taking care to returnComplexF32
if needed without making extra copies. Tim Davis mentioned on slack thatComplexF32
support is in the short-term to-do list for UMFPACK. At that point, the corresponding part of this PR could be simplified and generalized.GreenSolvers.Schur
builds onSparseLU
for some of its internals, so it needs adjustmentsGreenSolvers.Bands
needed a conversion of the Brillouin zone mesh to the Hamiltonian eltype to properly propagate the ComplexF32 typeGreenSolvers.Bands
relied on a random choice of dual numbers for degeneracy resolution. This randomness exactly cancelled out in all our tests at 64bit precision, so the results were deterministic. But on 32bit, the lower precision made the cancellation inexact, and the result would vary from run to run, or even yield divide-by-zero errors. In collaboration with Adrián Prada we devised a new algorithm to choose the optimal dual number that is deterministic and retains maximal precision