There is clearly something going on and I don’t know what it is. Thoughts?
In another context I’d suggest running an MRtrix3 script with the -debug flag, as this takes the text outputs of the underlying commands being invoked and raises them to the terminal. However I’m pretty sure that eddy writes its progress information to stdout rather than stderr, which prevents this from working. If you were to instead go into the scratch directory and manually run that eddy command, perhaps also with the --verbose flag, there’s a chance it might tell you something.
Furthermore, there’s a chance you might be running the single-threaded version of eddy, which will be slower again than the (multi-threaded) openMP version (I’d expect to see the command name as eddy-openmp normally – but I might be wrong here).
I would note that in some instances myself I’ve observed eddy_openmp running single-threaded. It’s entirely possible it’s something specific to one of my own systems and not an issue for anyone else, but it’d be worth running top for a period of time to see if it’s succeeding in multi-threading (I think it will always run in a single thread at certain points during its execution, but it should change back to multi-threaded at some point).
How can I instruct fsldwipreproc to run eddy in the GPU version or at least the multi-threaded one?
dwifslpreproc has already attempted to run the GPU version of eddy. It was only after its failure that the CPU version was instead executed. There isn’t any way to “instruct” it to use CUDA: dwifslpreproc will attempt this version first if it’s present on your system. Since eddy_cuda is compiled for different CUDA versions, currently dwifslpreproc will select the version with the most recent CUDA version; unless your system also has a command called “eddy_cuda” with no CUDA version in the name (which e.g. might be a softlink to the version that works on your system), in which case that will instead be invoked.
As far as why it failed, you will find some information in the scratch directory in file “eddy_cuda_failure_output.txt”, which contains whatever eddy_cuda printed before it terminated.
Cheers
Rob
