Dwipreproc run for too long time

Hi,

I’m writing to ask about the dwipreproc the -pe_dir input. (-pe_dir is needed if I don’t have the header information in the up to date MRtrix3 version)

dwipreproc -rpe_none -fslgrad bvecs bvals -export_grad_fsl bvecs_Eddy bvals_Eddy -pe_dir j -readout_time 0.030115 dTI_denoised.nii DTI_Eddy.nii -force

I used the notation of i, j an k. (which I think it means 1st, 2nd and 3rd dimension of the volume, am I right?) But it takes forever to run the code. (More than 12 hours, does it mean that I miss some parameters and make it unable to converge?)

How important is to give correct PE direction, because if I give a wrong PE direction of k, the code won’t run for that long time. Is there any way to not to specify phase encoding direction?

Thanks a lot for your help. Sincerely,

Yixin

Yes, but if you’re in doubt, you can always use the anatomical labels such as AP instead.

This might be due to there being lots of b =0 images, which topup takes ages to process – see this recent thread on this issue.

Very. The distortion correction assumes the distortions are along that direction only. If you correct along the wrong direction, you’ll get the wrong correction.

Only if your data contain enough information in the right format for MRtrix3 to figure out the phase-encoding direction by itself. Otherwise, you’ll need to know. But the distortions are typically obvious enough that you figure out by simple looking at the data, right?

Thanks for your reply. I appreciate it a lot. Now I know understand the importance of correct PE direction. I think the problem I had is that: In eddy current correction we should give the -FWHM a relatively large value to start the first round of iteration, if the patient moves a lot during the scan, according to FSL eddy. https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/eddy/UsersGuide.

Attached is the code, hope this would help anyone who will encounter this problem.

dwipreproc -rpe_none -fslgrad bvecs bvals -export_grad_fsl bvecs_Eddy bvals_Eddy -pe_dir j -readout_time 0.030115 DTI_orig.nii DTI_Eddy.nii -force -eddy_options " --slm=linear --fwhm=1,0,0,0,0 --dont_peas"

Best regards,

Yixin

I used the notation of i, j an k. (which I think it means 1st, 2nd and 3rd dimension of the volume, am I right?)

Yes: i, j and k are specifically used to refer to image axes, as opposed to “X”, “Y”, “Z”, which would typically be considered to correspond to L-R, A-P, I-S but that may in fact not be the mapping if the acquisition is not approximately axial. The same notation is used in BIDS for the same reason. MRtrix3 goes to the effort of trying to maintain this correspondence automagically in the back-end for you, making the handling of more complicated cases my job.

(One caveat of this is that the input to the -pe_dir option should be based on how the image looks in mrinfo / mrview when you do not specify the -norealign option, and not the actual raw data itself :exploding_head:)

How important is to give correct PE direction, because if I give a wrong PE direction of k, the code won’t run for that long time.

Very. The distortion correction assumes the distortions are along that direction only.

Note that this is the case even when using -rpe_none. Proper modeling of eddy current distortions relies on knowing the direction of phase encoding.

While I was going to say that topup may well run very quickly if you specify the wrong phase encoding direction (since it’d be essentially unable to find any differences between the images that it was capable of correcting), you’re using -rpe_none, and so topup isn’t even being invoked.

Also check your version of eddy. Some earlier versions of eddy I personally observed to not engage multi-threading. I don’t know the exact history or reasoning since it’s outside of my control, it’s just something that I remember seeing.