[dmftproj] build fromfile basis representation in double precision#6
Closed
krystophny wants to merge 1 commit into
Closed
[dmftproj] build fromfile basis representation in double precision#6krystophny wants to merge 1 commit into
krystophny wants to merge 1 commit into
Conversation
The fromfile angular basis (case with a "fromfile" harmonics choice, e.g. a |j,m_j> basis) is read and represented in single precision, so case.symqmc and case.sympar carry a ~1e-7 error there. Two causes in set_ang_trans.f / setsym.f: - CMPLX(rtrans, itrans) and EXP(CMPLX(0.d0, factor)) construct complex values from REAL(KIND=8) arguments without a KIND, so the constructor evaluates in default (single) precision before widening to the COMPLEX(KIND=8) targets. Add KIND=8 to the basis-read and spinor-phase casts. - the basis lines are read through a 250-column buffer (buf1) with an explicit buf1(2:250) slice, which truncates a higher-precision basis file mid-line. Widen the buffer and read the full line. Everything around these casts (the transmat/rotrep/rotl storage, the MATMULs, the read buffers) is already double precision; only the constructor intermediates leaked. The change matches them to the surrounding code. Effect: with a full-precision |j,m_j> basis, the d-shell case.symqmc now agrees with an independent double-precision reference to 1.9e-14 (was 6.0e-8), and the spinor matrices are unitary to 4e-16 (was 9e-9). The single-precision path is the one discussed on #148. No test regenerates from dmftproj (the converter tests read committed fixtures), so existing output is unaffected. ## Verification cmake + make + ctest (TRIQS, Build_Tests=ON): 100% tests passed, 0 tests failed out of 18 dmftproj on a full-precision |j,m_j> d-basis (16 ops, 8 time-reversal), vs an independent double-precision generator: before: max|fortran - ref| = 6.0e-8, unitarity dev = 9e-9 (single precision) after: max|fortran - ref| = 1.9e-14, unitarity dev = 4e-16 (double precision) Relates to #148.
This was referenced Jun 15, 2026
Author
|
Superseded by #14, which extends this fromfile-only fix to every single-precision |
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Part of #7 (dmftproj Fortran-to-Python port).
The fromfile angular basis (a
fromfileharmonics choice, e.g. a|j,m_j>basis) is read and represented in single precision, socase.symqmc/case.symparcarry a ~1e-7 error there. Two causes inset_ang_trans.fandsetsym.f:CMPLX(rtrans, itrans)andEXP(CMPLX(0.d0, factor))build complex values fromREAL(KIND=8)arguments without aKIND, so the constructor evaluates in default (single) precision before widening to theCOMPLEX(KIND=8)targets. AddedKIND=8to the basis-read and spinor-phase casts.buf1(2:250)slice, which truncates a higher-precision basis file mid-line. Widened the buffer and read the full line.The surrounding code (the
transmat/rotrep/rotlstorage, theMATMULs, the read buffers) is alreadyKIND=8; only the constructor intermediates leaked. The change makes them consistent.No test regenerates from dmftproj (the converter tests read committed fixtures), so existing output is unaffected.
This is the single-precision path discussed on #148; it is a precision fix, not a fix for the symmetrization symptom reported there.
Verification
cmake+make+ctest(TRIQS,Build_Tests=ON):dmftproj on a full-precision
|j,m_j>d-basis (16 operations, 8 time-reversal), against an independent double-precision generator:Relates to #148.