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

Add 32bit support for GreenFunctions #238

Merged
merged 1 commit into from
Jan 27, 2024
Merged

Add 32bit support for GreenFunctions #238

merged 1 commit into from
Jan 27, 2024

Conversation

pablosanjose
Copy link
Owner

@pablosanjose pablosanjose commented Jan 26, 2024

Closes JuliaLang/julia#236

Although Quantica is coded for a generic T<:AbstractFloat, the GreenFunction part was not tested for T == Float32, only for T == Float64. Doing so revealed a number of issues, which are fixed in this PR

  • In general, the ω argument of calls to GreenFunctions needed to be cast to the appropriate T or Complex{T} type at the beginning of the call chain.
  • GreenSolvers.SparseLU, which relies on UMFPACK, does not support ComplexF32 eltypes yet, so we must internally work with ComplexF64, taking care to return ComplexF32 if needed without making extra copies. Tim Davis mentioned on slack that ComplexF32 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 on SparseLU for some of its internals, so it needs adjustments
  • GreenSolvers.Bands needed a conversion of the Brillouin zone mesh to the Hamiltonian eltype to properly propagate the ComplexF32 type
  • GreenSolvers.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
  • Detailed testing of the above revealed that Apple Silicon processors would not handle BLAS operations of 32-bit numbers deterministically, due to a subtle bug in the OpenBLAS bundled in Julia 1.9 and 1.10. This was fixed in OpenBLAS 0.3.24, so Julia 1.11 does not have the issue. A backport of the fix to Julia 1.10 will land soon.

fix omega coversion

cleanup

sanitize_eigen also on vectors; allow non-BlasComplex

test new deterministic dual phi algorithm

tighten version for 32-bit test skip

skip ci cache for the moment

ci fix?

remove ubuntu-latest x86 from ci matrix

exclude x86 altogether (broken on nightly due to new Memory)

ComplexF32 fixes to rest of GreenSolvers

type-stability fixes

fix graphene model

fix graphene (redo)
@codecov-commenter
Copy link

codecov-commenter commented Jan 26, 2024

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (dbd1501) 92.78% compared to head (ba36bed) 92.66%.

Files Patch % Lines
src/solvers/green/bands.jl 93.75% 2 Missing ⚠️
src/solvers/green/schur.jl 84.61% 2 Missing ⚠️
src/bands.jl 80.00% 1 Missing ⚠️
src/solvers/green/sparselu.jl 95.83% 1 Missing ⚠️
src/tools.jl 0.00% 1 Missing ⚠️

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

Additional details and impacted files
@@            Coverage Diff             @@
##           master     JuliaLang/julia#238      +/-   ##
==========================================
- Coverage   92.78%   92.66%   -0.12%     
==========================================
  Files          34       34              
  Lines        5500     5538      +38     
==========================================
+ Hits         5103     5132      +29     
- Misses        397      406       +9     

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

@pablosanjose pablosanjose merged commit 27a7e97 into master Jan 27, 2024
9 checks passed
@pablosanjose pablosanjose deleted the typestable_g branch January 27, 2024 08:38
@pablosanjose pablosanjose mentioned this pull request Apr 25, 2024
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.

binary installers
2 participants