I am trying to get eddy cuda to work in my processing pipeline. I am using a virtual machine with a linux environment, via ubuntu 16.04 and have installed cuda 9.1. Upon checking this, cuda is here: I also have FSL version 6.0 and MRtrix3 version 3.0.2 installed.
So, running FSL’s command eddy_cuda9.1 is working fine, and there is a symlink on ‘eddy_cuda’, which points to eddy_cuda9.1. However, upon running dwifslpreproc, eddy cuda fails, and it proceeds to run eddy_openmp instead.
When you say eddy_cuda, can I just check that you’ve confirmed this by running a full run of eddy_cuda to completion? It looks like you’ve only checked whether the executable is present. The reason I ask is that the most likely reason for the failure is that you’re running within a virtual machine, and depending on the exact specifics of your setup, applications running in the virtual machine may not have access to the host’s GPU, in which case you would get a runtime failure when the application (in this case eddy_cuda) tries to access the hardware it needs (and just to check, the host system also needs to run an Nvidia GPU). dwifslpreproc will try to run eddy_cuda first, but fall back to eddy_openmp if that fails.
Ah, okay, I will check this with our IT, who look after the vm. Yes, I was only able to check whether the executable of eddy_cuda was present, and so I will also try running eddy_cuda from fsl on its own, and see if this problem persists there. Thank you
Even if not specifically relevant to your case, I’ll mention here for anyone that comes across this thread based on search terms:
On an up-to-date MRtrix3, if you run dwifslpreproc with the -nocleanup option, then within the retained scratch directory, you will find a file eddy_cuda_failure_output.txt. This contains whatever information eddy_cuda wrote as its output but did not appear on the terminal due to its having been executed within MRtrix3’s dwifslpreproc (which superseded it by running eddy_openmp as a backup). So if eddy_cuda fails but eddy_openmp succeeds, that’s where to look.
(The superseding with eddy_openmp is necessary because some people may install FSL but never set up CUDA, and I don’t think that dwifslpreproc should fail in that case)
Thank you Dr. Tournier and Dr. Smith for all of your information.
Just an update on my end in case others might run into something similar - we got eddy cuda to work on both MRtrix and FSL, and I think the main problem was that the GPU was not set up properly on the virtual machine (VM), and so an ‘extra step’ was implemented to fool NVIDIA from knowing it’s running in a VM. I am not too sure on what was exactly done though, as this was done by the VM support staff; I am using something called the ‘Nectar Research Cloud’ from our University for this
I also have FSL version 6.0 and MRtrix3 version 3.0.2 installed.
