I have a question regarding the time it takes for dwipreproc to run.
I’ve been trying to run this command locally on two different computers (both relatively new iMacs), and I’m really confused as to why one takes hours to run while the other takes days. I enlisted the IT department at my institution; however, they were also not sure what was going on. I’ve installed mrtrix3 and the corresponding dependencies using homebrew. I did the same thing on both computers. Just in case this helps, here are some of the specs…
I would expect computer B to be faster; however, it is actually computer A that is much faster. Has anyone else encountered this issue? I’m happy to provide more information if needed. Thank you in advance to anyone who took the time to read this post .
This is surprising indeed. First check if the processes are running single- or multi-threaded. I expect that you are most likely running a different version of FSL Eddy on both machines, where the one on Computer A runs in parallel thanks to CUDA or OpenMP support. Running dwipreproc with the -debug flag should tell you which FSL commands are invoked. Check if it is calling eddy, eddy_openmp, or eddy_cuda.
I will go out on a limb and assume that the difference will be in your OpenMP setup (I think there are no iMac 2017 models with a Nvidia GPU). Since you are already using Homebrew, you can run brew install libomp on Computer B to fix the discrepancy. Also check which eddy_openmp to confirm that it is indeed in your path.
Thanks for the response. Based on the activity monitor, it appears computer B is running more threads whereas computer A is only running one. This also seems counterintuitive to me. Additionally, both are using eddy. I’ve attached a copy of what my terminal outputs for your reference. Also, neither computer has eddy_openmp in its path.
Beats me. Your data does seem to be of exceptionally high in-plane resolution, which may be a reason why eddy is unusually slow, but of course that does not explain the difference you observe between both machines…
Can you run eddy --help on both machines to make sure that you are using the same FSL version on both systems? How about your MRtrix versions (first line in dwipreproc -help)? Did you test with the exact same dataset (same subject and protocol) on both computers?
A potential way to improve run time for your data, may be to crop the input data in plane. Seeing you have 256 x 256 voxels at ~1mm, I think you may be able to crop to 150 x 200 voxels in plane (assuming you are working with adult brain images), hence saving some 50% of the data. You should do this after mrdegibbs and before dwipreproc to be effective and save run time.
eddy --help returns the same (Part of FSL - ID: 5.0.11) for both machines.
As for dwipreproc -help, there was a discrepancy (bin version: 2b8e7d0c vs 5d6b3a6f); however, I am not entirely sure what this means?
For now, I can continue processing on my colleagues computer but it would be great if I could get the same speed on my computer. And yes, both protocols and datasets were the same.
As far as I can tell, neither dwipreproc or dwi2mask has changed between the two commits you mentioned, so we would indeed expect identical behaviour and timings. I have run out of ideas about why this is not the case or how to debug it. I still think cropping the data could be useful to speed up the processing (on both machines).
eddy --help returns the same (Part of FSL - ID: 5.0.11) for both machines.
I’ve seen multiple versions of eddy labelled as “5.0.11”; it seems to indicate the version of FSL that the command is intended to “reside with”, rather than being an identifier of the command itself. A better check would be to print the contents of the help pages and compare them: updates to eddy have come with new capabilities which have corresponding command-line options.
Though if, as you state, eddy is in fact running single-threaded on both systems, that would suggest that running single-threaded vs. multi-threaded is not the source of the discrepancy. Note however that I believe there are some “stages” of eddy that collapse back to single-threaded, so you need to monitor the thread usage at more than one time point to know for certain whether the command is running single-threaded throughout.
.