Dwifslpreproc discrepancy when running eddy vs eddy_cuda9.1

10

Hi @rsmith!

Welcome back! I hope you a happy new year!

Thank you for your insights. Below are my comments and some more questions if you don’t mind.

  1. Regarding the -scratch directory, it was already an existing directory. I have just named the folder “test” to test some of the pipelines that I am building. I thought of structuring the folders such that there is an individual subject folder where all the DWI preprocessing is done, which includes the both scratch and eddy QC directory to be the same. It’s good to know that it’s NOT advisable to have the two the same. I will make that adjustment. Then, I expect that this issue would be resolved. If not, I will come back to this post. :stuck_out_tongue_winking_eye:

  2. On the note of “SliceEncodingDirection”, I want to check with you whether this is the same as the -axes indicated for the mrdegibbs command? or are they two different things? I have checked that it is acquired in the axial direction for the mrdegibbs correction. It would be great to check with you whether they are referring to the same thing.

  3. I can feel your uneased tension on the dwifslpreproc command from all the comments/requests from the community! I won’t ask you to convert the dwifslpreproc command to be “fool-proof”. Perhaps, when I or someone else have extra free time and up for a challenge, this would be a nice task to add the conversion and checkpoints for the SliceEncodingDirection, non-axial direction data, etc.

  4. I understand why DWI data had to be padded when it didn’t have an even-numbered matrix dimension. Now with FSL6, this is not the case as they have allowed preprocessing using their new config file list that can handle by units 1, 2, and 4 as you have also kindly mentioned (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=FSL;6c4c9591.2002). I can see that you can specify the appropriate for your own case. Here for me, it would be for DWI data with an odd-numbered dimension.

Now, you have provided two possible solutions. However, I don’t think these options are already implemented in the dwifslpreproc command. To me, it seems like option 1 may be easier since I would just need to simply specify the “correct” config file that is appropriate for an odd-numbered dimension at least in one direction. However, from looking at the dwifslpreproc, the padding invariably happens prior to the topup step if it contains at least one direction that is an odd number. In addition, I am already using FSL6 and the dwifslpreproc did not find the appropriate file. I guess these two options are for me to try on my own? I have found the following on the forum from https://community.mrtrix.org/t/how-to-pad-a-slice-to-data-for-topup/4195/3?u=jottoy.

I guess such changes are meant for a future release? If these two options are for me to try, I would like to ask for some more details/guidance as I am not too familiar with python and its syntax. a) If I were to try option 1, then would simply commenting out the padding portion of the code suffice https://github.com/MRtrix3/mrtrix3/blob/c838731033331f9e3f2afe451b8a5768e2f83b78/bin/dwifslpreproc#L738-L782? I want to check with you whether the variables that are passed onto the next step depends on this. If so, then I would need to fix/change the variable name, I assume.

You mentioned that topup will take longer for this option. How much longer do you expect? When I ran these tests, with eddy_cuda, the whole preprocessing took ~3-4 hours, which I think is not too bad considering without cuda, it took nearly 9 hours for some subjects. b) If I were to try option 2, then would you kindly provide a list of files that I need to change? If this is too cumbersome, is there an easy way to get a list of all the files that should be changed? It would be very helpful!

  1. Last but not least, I want to double-check what you’ve said. Despite all these warning and errors messages, at the end of the day, my eddy_cuda run with the slice-to-volume correction was executed and finished correctly and successfully, is this correct? If so, I could live with these warning messages for the time being and move forward while testing the two options/solutions that you have provided since there is a timeline for me to meet. haha. Also, I want to check your last comment whether it was a typo or not.

So, you never don’t use it? meaning you always use it? Sorry for being too careful but communication via text can be misleading at times!

Thank you again for your help and expertise! It’s very much appreciated.
Best regards,
Julie