# Dwipreproc run for too long time
**URL:** https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058
**Category:** Uncategorized
**Created:** [November 18, 2018, 11:28pm UTC](https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058 "2018-11-18T23:28:17Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Yixin\_Ma](https://community.mrtrix.org/u/Yixin_Ma)
#### Post date: [November 18, 2018, 11:28pm UTC](https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058/1 "2018-11-18T23:28:17Z")
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
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [November 20, 2018, 4:52pm UTC](https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058/2 "2018-11-20T16:52:59Z")
> [@Yixin\_Ma](#):
>
> 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, but if you’re in doubt, you can always use the anatomical labels such as `AP` instead.
> [@Yixin\_Ma](#):
>
> 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?)
This might be due to there being lots of _b_ =0 images, which `topup` takes ages to process – see [this recent thread](http://community.mrtrix.org/t/dwipreproc-topup-with-many-b0-up-down-reverse-phase-pairs/2047) on this issue.
> [@Yixin\_Ma](#):
>
> 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. If you correct along the wrong direction, you’ll get the wrong correction.
> [@Yixin\_Ma](#):
>
> Is there any way to not to specify phase encoding direction?
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?
---
### Author:  [@Yixin\_Ma](https://community.mrtrix.org/u/Yixin_Ma)
#### Post date: [November 20, 2018, 5:53pm UTC](https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058/3 "2018-11-20T17:53:05Z")
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](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
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [November 25, 2018, 8:50am UTC](https://community.mrtrix.org/t/dwipreproc-run-for-too-long-time/2058/4 "2018-11-25T08:50:57Z")
> 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](https://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html#interaction-between-strides-and-transform) automagically in the back-end for you, making the handling of more complicated cases [my job](https://github.com/MRtrix3/mrtrix3/blob/master/core/header.cpp#L524-L552).
(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 🤯)
> > 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.