fix(ler): force num_workers=0 when torch.compile is active to prevent segfault

[ivanbasov]

Summary

• torch.compile(model) is applied at line 924 of code/evaluation/logical_error_rate.py, before the DataLoader is created at line 1057 with num_workers=16 and multiprocessing_context="spawn".
• Spawning new processes after torch.compile creates a CUDA context conflict in the child processes → segfault + ~20 leaked semaphores.
• The SDR evaluation path is not affected because its DataLoader is created prior to calling torch.compile.

Fix: immediately after the existing container/worker-override logic block (line 1048), check whether _applied_compile is True and num_workers > 0. If so, force num_workers=0 so data loading runs in the main process, avoiding the fork/spawn-after-compile hazard entirely. No workflow YAML changes are needed; the previous CI workaround (commit 7f0f6c8) was already reverted (9d3fa08) in favour of this proper code fix.

Failed CI run that motivated this fix: https://github.com/NVIDIA/quantum-predecoder/actions/runs/23924233265/job/69777476304

Test plan

• Run LER evaluation with torch.compile enabled and num_workers > 0 configured — confirm no segfault and no semaphore leaks.
• Confirm num_workers is forced to 0 in logs when _applied_compile=True.
• Run SDR evaluation to confirm it is unaffected.
• Run existing CI suite to confirm no regressions.

🤖 Generated with Claude Code

[bmhowe23]

What was the first PR on main that seems to have introduced this problem?

[ivanbasov]

What was the first PR on main that seems to have introduced this problem?

It seems that the problem is with my fork's main not with the upstream/main. So, I somehow missed the fix I made in a branch and already merged into the upstream main. It just prevented me to run long-runnintests againt my branch not affected globally.