Troubleshooting¶
This page collects common installation and runtime failures and the checks that usually identify the cause.
1. MPI stack mismatch¶
MPI components must use the same MPI implementation. A common macOS failure is launching with Homebrew OpenMPI while mpi4py or a compiled executable is linked against conda MPICH.
Typical symptoms include,
Runtime environment uses unsupported PMI version PMIx
or MPI jobs that fail immediately before entering DMFTwDFT, CTQMC, Wannier90, or the DFT executable.
Checks,
which mpirun
mpirun --version
python -c "from mpi4py import MPI; print(MPI.Get_library_version())"
On macOS with Homebrew OpenMPI, linked libraries should resolve to Homebrew OpenMPI, for example libmpi.40.dylib, not conda MPICH libraries such as libmpi.12.dylib.
2. Apple Silicon architecture mismatch¶
On Apple Silicon, keep every compiled component native arm64 unless you intentionally run a complete x86_64 stack under Rosetta.
Checks,
file bin/dmft.x
file bin/ctqmc
file /path/to/wannier90.x
Do not mix x86_64 Wannier90, SIESTA, CTQMC, or MPI libraries with an arm64 Python environment.
3. Harmless stderr messages¶
Some compilers and runtimes print warnings or floating-point status notes to stderr even when the command succeeds. For example,
Note: The following floating-point exceptions are signalling: IEEE_OVERFLOW_FLAG
DMFTwDFT checks command return codes and expected output files instead of treating any stderr text as fatal. If you see this message but the expected output files are created, it is usually diagnostic rather than a failed calculation.
Examples of expected files,
Wannier90 preprocessing:
<seed>.nnkpSIESTA:
<seed>.outDMFT DOS:
dos/G_loc.outBand calculations:
bands/Gk.outAnalytic continuation:
ac/Sig.out
4. SIESTA runs stop after Wannier90 preprocessing¶
For SIESTA workflows, DMFTwDFT first generates wannier90.win, runs wannier90 -pp, then launches SIESTA. A successful preprocessing step writes <seed>.nnkp.
If the workflow stops after wannier90.win generated, check,
ls -l <seed>.nnkp
wannier90.x -pp <seed>
If <seed>.nnkp exists and the command returns success, SIESTA should be able to proceed.
5. DFT calculation hangs¶
If the workflow prints Running Siesta in ..., or the VASP or Quantum Espresso equivalent, and never returns, check that the DFT executable is actually running as a single MPI job with all the requested ranks.
When the launcher and the executable come from different MPI implementations, mpirun -np N starts N independent single-rank processes instead of one N-rank job. Those processes share one standard input, so only one of them receives the input file and the others stall, leaving the launcher waiting.
The DFT output reports the rank count it actually sees. SIESTA prints,
* Running in serial mode (only 1 MPI rank).
If that line appears while para_com.dat requests more than one rank, or the output contains several >> Start of run banners and only one >> End of run, the ranks are not being used. Verify the launcher matches the executable as described in sections 1 and 8, then rerun.
To run only the DFT step on a single rank while keeping the DMFT loop parallel, use para_com_dft.dat,
echo "mpirun -n 1" > para_com_dft.dat
This overrides para_com.dat for the DFT executable alone. dmft.x, ctqmc, and wannier90.x continue to use para_com.dat.
6. Missing or stale shell setup¶
After setup, DMFT.py and postDMFT.py should be runnable from calculation directories.
Check,
which DMFT.py
python -c "import Fileio; print(Fileio.__file__)"
If these fail, restart the shell or source the startup file printed by setup.py.
For zsh this is usually,
source ~/.zshrc
For bash this is usually,
source ~/.bashrc
7. Generated build files¶
The root Makefile.in is the editable build configuration. setup.py regenerates internal build files from it, including sources/make.inc and staged eDMFT makefiles.
If a build fails, update the root Makefile.in and rerun,
python setup.py
Only edit generated files directly when debugging a build and expecting those edits to be overwritten by the next setup run.
8. Checking linked MPI libraries¶
On macOS, use otool to inspect dynamic libraries,
otool -L bin/dmft.x
otool -L bin/ctqmc
python - <<'PY'
import mpi4py, pathlib
print(pathlib.Path(mpi4py.__file__).parent)
PY
For the mpi4py extension, inspect the .so file inside the printed directory. Homebrew OpenMPI builds should link to /opt/homebrew/opt/open-mpi/lib/libmpi.40.dylib or equivalent Homebrew OpenMPI paths.