Eddy_cuda fails despite sufficient mask voxel count

I’m running eddy_cuda10.2 (from FSL 6.0.X) inside WSL2 with a GTX 1050 Ti, and I’m encountering a consistent error even though my input mask has enough non-zero voxels.


System Info:

  • OS: WSL2 (Ubuntu 20.04)
  • GPU: NVIDIA GTX 1050 Ti
  • CUDA Version: 12.6
  • FSL Version: [e.g., 6.0.7]
  • eddy version: eddy_cuda10.2

Command used:

eddy_cuda10.2 \
--imain=eddy_in.nii \
--mask=newtest_mask_dilated_final.nii.gz \
--acqp=eddy_config.txt \
--index=eddy_indices.txt \
--bvecs=bvecs \
--bvals=bvals \
--slm=linear \
--nvoxhp=500 \
--out=dwi_post_eddy \
--verbose

Error message:

EDDY::DataSelector::common_constructor: rnvox greater than number of non-zero voxels in mask.
Exception thrown
...
EDDY failed with message ...

What I’ve verified:

  • The mask is in the same directory as eddy_in.nii
  • The mask is a float32 NIfTI file with 32,654 non-zero voxels, confirmed via mrstats
  • The same mask worked previously in dwifslpreproc (with fallback to CPU eddy)
  • Using --mask newtest_mask_dilated_final.nii.gz (also tried .nii)
  • GPU is recognized via nvidia-smi, and eddy_cuda10.2 is in $PATH

What I tried:

  • Lowering --nvoxhp to 100, 50, 30 → Same error
  • Rebuilding the mask using dwi2mask, mrfilter smooth, and mrcalc
  • Tried .nii.gz and uncompressed .nii format
  • Confirmed file integrity, header, and that the mask and input image have matching dimensions

Question:

What could be causing this mismatch between --nvoxhp and the mask voxel count, even when the count is clearly sufficient?
Are there known bugs, data type sensitivities, or internal mask compatibility checks that could trigger this error?

Any help or suggestions are greatly appreciated!

++ With the same data and system, eddy_cuda10.2 has previously succeeded, but only when I manually tuned the mask (e.g., more dilation, different smoothing/threshold combinations).

However, the logic behind why it worked then — and fails now — remains unclear, even though voxel counts are more than sufficient in both cases.