Dwipreproc - non-repeatable results

1

Dear MRtrix gurus,

First of all, thank you for providing such an excellent software suite! I’m a recent MRtrix convert, and I’ve been really impressed with all the features offered.

I’ve recently noticed that the dMRI preprocessing pipeline I’m creating (which relies heavily on MRtrix) produces slightly different tensor metric maps when repeatedly run on the same subject.

Tracing this issue back to the early steps of the pipeline, I can see that dwipreproc produces identical image results on repeated runs, but the values in the gradient table file can differ. For example:

Grad table 1

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0.9999910408 0.004232840534 3.618870022e-05 1000
0.7954288898 0.6060447622 0.001620943175 1000
-0.2663316022 0.5511894284 0.7907323768 1000
0.9322053092 -0.3481137442 -0.0990458616 1000
-0.1562621226 -0.7815501474 0.6039548958 1000
-0.5654401304 -0.1045455397 0.8181367178 1000
0.5341489 0.4472017558 0.7174228476 1000
-0.5482559782 0.816532843 -0.1808023746 1000
0.7553389987 -0.2395859067 0.6099685158 1000
-0.1644417534 -0.9857423592 0.03564983872 1000
0.2296401527 -0.9562313853 -0.1813475616 1000
0.1160192239 -0.8264884405 -0.5508687661 1000
-0.5019457878 -0.499498911 0.7060816271 1000
-0.4945098364 0.763097823 0.4161030331 1000
-0.7149742081 -0.1320140029 -0.6865742384 1000
-0.5244126272 -0.8495396676 -0.05721669022 1000
0.7480063997 -0.472439653 -0.4661407517 1000
0.5890808674 -0.2873989751 -0.7552387442 1000
-0.2201150803 -0.9161280624 -0.3350503315 1000
-0.8278058834 0.4919238162 -0.2697190731 1000
0.5965305282 0.6837666023 0.4202553538 1000
-0.4770566202 0.3368222804 -0.8117682752 1000
0.9336798903 -0.04403391662 0.35539116 1000
0.226429034 0.702823162 0.6743659952 1000
-0.1498898719 0.2989161423 -0.9424341707 1000
0.1532331828 -0.9692961727 0.1923136013 1000
0.8882212798 -0.1058090024 -0.4470653343 1000
0.1028435273 0.4235684898 0.9000071907 1000
-0.2387678893 0.8300926059 -0.5039207882 1000
0.6889254127 0.6125395253 -0.3875269097 1000
-0.1044751424 0.6070306793 -0.7877808699 1000
-0.002952946506 0.0004933735659 0.9999955183 1000
-0.3929796218 -0.107183501 -0.9132790997 1000
-0.2511222499 -0.3286536309 0.9104528579 1000
-0.8070033509 -0.2467240983 0.5365378001 1000
-0.931187445 -0.3225559419 0.1698458319 1000
0.5614698799 -0.6233445209 0.5442363294 1000
-0.7118507733 0.6918114715 0.1211006377 1000
0.8692336591 0.3675482137 0.3306677432 1000
-0.2764247661 0.1876258537 0.9425422472 1000
0.3973152287 0.851082609 -0.3432185917 1000

Grad table 2

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0.9999915874 0.004094178754 0.0002506801697 1000
0.7954501312 0.6060166281 0.001713241169 1000
-0.2664577836 0.5513252723 0.7905951516 1000
0.9322197306 -0.3481481019 -0.0987890329 1000
-0.1563889685 -0.7814460417 0.6040567642 1000
-0.5656143103 -0.1044145904 0.8180330343 1000
0.5340298596 0.4473240148 0.7174352478 1000
-0.5482009436 0.8165221105 -0.1810175917 1000
0.7551833495 -0.2394724146 0.6102057614 1000
-0.1644491334 -0.9857354385 0.03580681133 1000
0.2296692451 -0.9562638183 -0.1811395803 1000
0.1161029189 -0.8265877787 -0.5507020576 1000
-0.5020866216 -0.4993672363 0.7060746333 1000
-0.4945423 0.7631838168 0.4159066906 1000
-0.7148483586 -0.1321580861 -0.686677555 1000
-0.5244008686 -0.8495534988 -0.05711901401 1000
0.7481004801 -0.4725349019 -0.4658931618 1000
0.589213278 -0.2875546491 -0.7550761795 1000
-0.2200886178 -0.9161897251 -0.3348990712 1000
-0.8277492868 0.491901975 -0.2699325197 1000
0.5964641419 0.6838481734 0.4202168525 1000
-0.476922655 0.336686501 -0.8119033078 1000
0.9336221182 -0.04394675837 0.3555536848 1000
0.2263373955 0.702939424 0.6742755739 1000
-0.1497347992 0.2987565402 -0.9425094268 1000
0.1531882853 -0.9692599575 0.1925317739 1000
0.88829362 -0.105889389 -0.446902542 1000
0.1026860592 0.4236965611 0.8999648868 1000
-0.2386627867 0.8300391411 -0.504058626 1000
0.6890813674 0.6123527541 -0.3875448022 1000
-0.1043139971 0.6068942847 -0.7879073024 1000
-0.003115935569 0.0006635248144 0.9999949253 1000
-0.3928335222 -0.1073061801 -0.9133275467 1000
-0.2512551253 -0.3284536178 0.9104883761 1000
-0.807115428 -0.2466001101 0.5364262033 1000
-0.9312259798 -0.3225038826 0.1697333797 1000
0.5614091641 -0.6232437467 0.5444143483 1000
-0.7118589539 0.6918590719 0.1207801906 1000
0.8691621262 0.3676597614 0.3307317617 1000
-0.2765771834 0.187765068 0.942469809 1000
0.3973482092 0.8510464592 -0.3432700466 1000

I am using data that has been converted to NIfTI format with dcm2nii, and feeding the gradient info to dwipreproc with the -fslgrad flag. Here’s what my call to dwipreproc looks like:

dwipreproc ./dwi.nii.gz dwi_MD_C.nii.gz -tempdir ./tmp/dwipreproc-tmp -nocleanup -fslgrad ./*.bvec ./*.bval -export_grad_mrtrix ./dwi_MD_C.b -pe_dir $phase_dir -readout_time $read_time -rpe_none

As a first attempt at removing this variation, I’ve tried disabling multi-threading (-nthreads 0 for the MRtrix wrapper, and export OMP_NUM_THREADS=1 for the FSL back-end), but sadly this hasn’t had the desired effect.

Does anyone have any ideas as to how I can make dwipreproc deterministic? Here’s the version info for the MRtrix build I’m currently using:

== mrconvert 3.0_RC3-91-gd2cd716d == 64 bit release version, built Sep 11 2018, using Eigen 3.3.4

Thanks for taking the time to read!

Best wishes,

Rich

2

Given what you’ve shown here, the most likely culprit is the motion correction in eddy. If there are very minor variations in the estimated rotations (and it sounds like we are talking about minor variations, right?), then they would translate to minor variations in the corrected bvecs. I would however also expect similarly minor variations in the image intensities though – although these are likely to be too small to spot with the naked eye. Do you see such differences?

As to what might cause these variations, I’m probably not familiar enough with the inner workings of eddy to comment. It might be that there is some degree of stochastic initialisation in there somewhere. The other option is that you might be using the CUDA version of eddy, not the OpenMP version? In which case the OMP flag would have no effect, and the issue might still be randomness introduced by the unpredictable order of execution – not sure. Either way, if you really want to get to the bottom of it, you’ll probably get more informed answers from the FSL forum, given that you seem to have narrowed the issue down to eddy. But you’d need to eliminate any dependence on dwipreproc first, make sure you genuinely get slight differences in the bvecs on repeated, but otherwise identical runs of eddy.

3

You’re quite right, I should have dug deeper into the various FSL outputs before posting. I apologise for prematurely besmirching MRtrix’s good name.

For anyone else who might be interested, the culprit is a random sampling of a subset of voxels within eddy, which is used for setting the hyperparameters of the GP. Random sampling can be disabled by setting the --initrand flag to true (see here).

From the limited tested I’ve done since yesterday, it seems that using export OMP_NUM_THREADS=1 and feeding -eddy_options " --initrand=true" to dwipreproc is enough to ensure a repeatable result. I will report back if this turns out not to be the case.

Thanks for pointing me in the right direction!

Rich

1 Like