[wien2k] Pure-Python case.symqmc generator (first dmftproj port step)

[krystophny]

Part of #7 (dmftproj Fortran-to-Python port).

First step of porting the dmftproj Fortran to Python: a pure-Python generator for case.symqmc (the correlated-shell symmetry matrices).

triqs_dftkit.wien2k.symqmc.write_symqmc(case) reads case.dmftsym + case.indmftpr + case.struct and writes case.symqmc, reproducing the dmftproj Fortran construction (Wigner D, orbital and spinor time-reversal operators, angular-harmonics basis transform, spin-1/2 phase blocks). It is a full replacement of the symqmc-writing, covering every path dmftproj emits:

• non-mixing spin-diagonal bases (complex, cubic): the up/up block scaled by the +-(a+g)/2 phase, with the orbital time-reversal operator on the magnetic operations;
• spin-mixing fromfile bases (the |j,m_j> basis): the full 2(2l+1) spinor representation P spinrot P^dag with the spinor time-reversal -i sigma_y (x) T on the magnetic operations;
• l=0 (s) shells: the 2x2 spin phase block.

This is the first of the "tail-backward" series that incrementally replaces fortran/dmftproj with Python, each step proven against the Fortran output via the SOC golden test (#4).

While validating the mixing path I found dmftproj reads the fromfile basis in single precision (a CMPLX cast without KIND=8) and through a 250-column line cap, so its case.symqmc there carries a ~1e-7 error; the Python generator is full double precision. That dmftproj bug is fixed separately in #6.

Verification

Validated against the dmftproj Fortran output on CaOs2 (16 operations, 8 time-reversal) for all three paths:

non-mixing (cubic): max|py - fortran| = 6.8e-8,  unitarity dev = 4e-16
mixing (|j,m_j>):   max|py - fortran| = 6.0e-8,  unitarity dev = 9e-9   (8-digit input floor)
l=0 (s):            max|py - fortran| = 4.4e-8,  unitarity dev = 0

The residuals are dmftproj's own limited precision (8-digit cubic templates, single-precision fromfile); the Python construction is exact (machine-precision unitarity). With #6 applied, the mixing path matches dmftproj to 1.9e-14.

End to end, the cubic converter HDF5 is identical (h5diff). Tests: the cubic path reuses the SOC golden h5; the mixing and l=0 paths compare to the dmftproj matrix data (single precision, ~26 kB) and assert unitarity. Built against TRIQS with Build_Tests=ON: 4/4 wien2k tests pass.

[krystophny]

Accuracy: reproduces the released (single-precision) dmftproj case.symqmc to 6.8e-8. With the Fortran precision fix #14 + exact Python #12 this becomes 1.5e-14 (machine precision).

[the-hampel]

Hi @krystophny, #4 is merged (c2f0576), so we moved on to this one.

Rebase. We force-pushed a rebase onto current unstable (7d21b9c → 4a26e2b). Please re-fetch before you work on it locally. Only your symqmc commit was replayed; the old #4 commit 830cb84 is gone. Conflict resolutions:

• CaOs2.indmftpr: kept the unstable version (-2.0..3.0 Ry). symqmc does not depend on the window.
• test/python/wien2k/CMakeLists.txt: kept both blocks.
• CaOs2.dmftsym was already identical on unstable, so it dropped out of the commit.

Fresh build: 22/23 tests pass. Two issues, which we'd leave to you since they depend on the precision question below:

1. Py_wien2k_symqmc_python fails. wien2k_soc_convert.ref.h5 now also holds dft_parproj_input/dft_symmpar_input, and this test only runs convert_dft_input. It also still uses h5diff, which checks arrays at 1e-6 regardless of precision, as found in [test] Add spin-orbit + spin-polarized Wien2k converter test (CaOs2) #4.
2. The test overwrites a shared fixture. write_symqmc('CaOs2') writes into the build directory that Py_wien2k_soc_convert reads, replacing the Fortran CaOs2.symqmc. The Python output differs from it by up to 6.9e-8, so the result depends on test order: after symqmc_python has run, Py_wien2k_soc_convert fails at 1e-12 (max diff 3.4e-8). Generating into a temp dir, as wien2k_symqmc_mixing.py does, and comparing the generated file against the shipped CaOs2.symqmc at an explicit tolerance would fix both.

Precision question. The commit message says the cubic path matches dmftproj "to machine precision" and that the HDF5 is "identical (h5diff)". With the #4 fixture (cubic basis from case.cf_d_eg_t2g), the matrices differ by up to 6.9e-8; the h5diff check only passed because of its 1e-6 tolerance. We haven't checked which side is off. A single-precision read of the cubic template on the Fortran side, like the CMPLX cast you describe for the fromfile basis, would fit. Could you pin that down and set the tolerance (and the commit message) accordingly?

Attribution: this comment was produced by Claude (Opus 5.5) running in Claude Code, driven by @the-hampel.