[feat] configurable QE executables with core mapping support

[hmenke]

• Move dft_exec to dict structure for per-executable configuration
• Support number_cores placeholder in executable paths
• Update qe_manager to handle both string and dict dft_exec formats
• Add backward compatibility for legacy string configuration
• Showcase in Ce2O3 CSC tutorial

[hmenke]

Another idea that came to my mind was to allow interpolation of the entire environment. That would provide maximum flexibility.

Suggested change

	qe_exec = qe_exec.format(number_cores=number_cores)
	qe_exec = qe_exec.format(**{**os.environ, "number_cores": number_cores})

Not sure whether this is fragile, though. At least in a couple of manual tests I was not able to break it.

[the-hampel]

I think this could be potentially a bit dangerous if someone misuses this? What do you think? I mean this interpretes whatever is in the os.eniron? But I am not an expert.

[hmenke]

The idea was to allow something like

[dft.dft_exec]
path = "{HOME}/Code/q-e/install/bin"
pw = "pw.x -nk {SLURM_NTASKS_PER_NODE}"

[the-hampel]

Okay I think I am convinced this is very handy. I made a little commit to allow for this with a safety net. Can you check if this makes sense? If this all works ( I did not explicitly test this again with QE) I am happy to merge this. Maybe if you find it okay I will give the tutorial a try again before merging.

[hmenke]

LGTM 👌

[the-hampel]

Hi @hmenke ,
just had a first look at this and mainly updated the documentation.txt file for this new option. And also made some minor tweaks. Thank you for this addition - I think for qe users this is very helpful!

P.S. unfortunately the CI is a bit broken currently on Unstable because of changes made to the default tailfit in triqs/unstable and I am currently discussing with @Wentzell and @Thoemi09 how to resolve this.

[the-hampel]

Hi @hmenke ,
I did rerun the Ce2O3 tutorial and made some minor changes to the tutorial. Most notably I added the path keyword to the dft_exec part in the dmft_config.toml file. If you do not have any further suggestions or changes in mind I am happy to merge this tomorrow.

[the-hampel]

Ce2O3 tutorial: simplified f-orbital ordering in ce2o3.win

The projections card listed the 7 Ce-f orbitals in a hand-picked Wannier90 mr order 4,3,5,2,6,1,7, which matches neither the TRIQS f-cubic order (mr=6,4,2,1,3,5,7) nor the QE/Wannier90 order (mr=1..7). It was a workaround from before spherical_to_cubic supported l=3 for the qe/wannier90 basis.

Now that l=3 is supported, the block simplifies to the natural order:

begin projections
Ce1:l=3
Ce2:l=3
end projections

which gives mr=1..7 — exactly the convention h_int_basis="qe" assumes.

This is physics-neutral for the tutorial. I ran two full CSC calculations (5 DMFT iters, HubbardI, same QE build) with the old scrambled order vs the new natural order — the total energies agree to ~4×10⁻⁴ eV (iteration 0 is bit-identical). The reason is the integer f¹ filling of Ce³⁺ (verified imp_occ = 1.0): with one electron the inter-orbital density–density energy Σ U_ij⟨n_i n_j⟩ ≈ 0, so the result is insensitive to the ordering. (In general, and for higher/non-integer fillings, keeping h_int_basis consistent with the projector convention does matter — solid_dmft also rotates into the hloc_diag eigenbasis, which further reduces the sensitivity here.)

E_tot − min(E_tot) (eV), old scrambled+qe vs new natural+qe vs shipped reference:

iter	reference (21 it)	natural qe	scrambled qe
0	0.000	0.000	0.000
1	0.613	0.343	0.343
2	0.612	0.345	0.345
3	0.611	3.154	3.154
4	0.657	2.323	2.323
5	0.685	1.755	1.755

natural and scrambled overlap exactly. The offset from the reference at iter ≥ 3 is not the ordering — it's the quick tutorial config (n_iter_dmft_first=2, 5 iters) vs the longer converged reference (n_iter_dmft_first=3, 21 iters); the ~36 eV absolute-energy gap is a DFT/QE-build offset that cancels in E−min.