It seems dwipreproc goes with the highest eddy_cuda it finds, and if it fails then it tries eddy_openmp. Is that correct?
Problem is that FSL 6.0.1 provides eddy_cuda8.0 and eddy_cuda9.1. Our cluster can run the former, but not the latter. Dwipreproc only tries the latter before moving onto eddy_openmp. Can someone show me how to edit dwipreproc so it can choose eddy_cuda8.0? Any suggestions would be appreciated!
PS- Alternatively, if there’s no simple solution on this end, I can ask our cluster admins to delete eddy_cuda9.1, but they may be hesitant to modify and deviate from what is provided in the FSL download.
Probably the best solution is to create a soft-link “eddy_cuda” that links to the working version (maybe I need to document this better…). Beyond that I would need to modify the code so that dwipreproc attempts to execute all versions found within PATH, which would be very clunky.
Thanks Rob. Okay that’s what I figured (clunky modification of the code). I’ll try with a symlink (will dwipreproc look for an “eddy_cuda” ? That is, without any numbers after it?). If that doesn’t work, I’ll get our cluster admin to remove the non-working version for me.
As an aside, I believe the new FSL release (6.0.2) includes the creation of an eddy_cuda symlink during the install process, so that could avoid any future issues here.