Make the PyTorch install and model cache survive real-world Windows setups

[JonaRichter]

Four fixes for failures that made an analysis run impossible on some machines. All of them were diagnosed from an actual failing install, not from reading the code — one of them turned out to have a very different cause than the error message suggested.

What is in here

Fall back to CPU when CUDA's kernels do not match the GPU. torch.cuda.is_available() only confirms a CUDA runtime is present, not that the installed build's compiled kernels cover this GPU's compute capability. On a mismatch the first real kernel launch fails mid-analysis. A trivial canary op is not a reliable stand-in — observed on real hardware to succeed after a slow one-time JIT warmup while the model's own conv/batchnorm kernels still failed immediately afterwards. The probe therefore runs the actual model on a dummy input of its expected shape.

Separate a broken model load from a genuinely missing one. Exit code 2 previously covered both "the file is not downloaded" and "loading blew up for some other reason", and the UI always answered with "run the analysis again to trigger a download". For a broken torch install that advice is actively wrong — retrying just repeats the failure. Broken loads now get their own exit code and surface the real exception. Addresses #105.

Pin torch below 2.13 on Windows. torch 2.13 moved to PEP 639 license-file collection, which copies its whole vendored third-party licence tree into torch-<version>.dist-info/licenses/. The deepest path fails Windows installs with WinError 206 whenever site-packages is longer than roughly 86 characters — which a default Slicer install already is. This is an open upstream regression, independently reported by users of other PyTorch-based Slicer extensions and confirmed by a Slicer core developer; the official PyTorch extension has an unmerged fix for it. installTorch() already accepts a version requirement, so this passes <2.13.0 on Windows only. Addresses #108.

Treat a checksum-mismatched cached model as missing. A truncated download left a 21-byte file where a 336 MB model belonged. Nothing checked content — get_missing_models() only tested existence and a zero-byte guard, so the file counted as cached and the failure only surfaced deep inside torch.load() as a confusing unpickling error. The checks now use the verify_checksum() helper that already existed but was never wired into this path, so a corrupted file routes through the normal download prompt. Addresses #107.

Why #107's original diagnosis was wrong

That issue was filed as a checkpoint-format incompatibility with PyTorch's restricted unpickler, with three proposed options centred on weights_only. Measuring the file settled it differently: 21 bytes on disk against 352,517,483 expected, and weights_only=False failed earlier than weights_only=True — not a valid pickle stream at all. It was a corrupted download. No security exception was needed; the blanket rule forbidding weights_only=False in production is untouched.

Verification

pytest tests/ — 521 passed, run against this branch on its own rather than only at the tip of the follow-up work.

Manually verified in Slicer: torch uninstalled and reinstalled from scratch through the real Run Analysis flow. The first attempt resolved 2.12.1+cpu, a second full uninstall/reinstall resolved 2.8.0+cu129 — a different build entirely, confirming the pin holds regardless of which sub-2.13 CPU or CUDA build gets picked. No WinError 206, no missing-torchgen error. A full analysis completes.

Not included

The pin is a workaround for someone else's regression. When the upstream fix lands in the released PyTorch extension, this can be reverted — the version cap sits in one place for that reason.

[JonaRichter]

Opened against the wrong repository. This project's pull requests go from this fork to the upstream extension repository, not to this fork's own main — closing in favour of the upstream ones covering the same commits.