# Eddy's estimate move by susceptibility option causing crash on denoised data? **URL:** \ **Category:** Uncategorized\ **Tags:** preprocessing\ **Created:** [August 15, 2019, 5:58pm UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754 "2019-08-15T17:58:49Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![MrRibbits](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/3bc359/32.png) [@MrRibbits](https://community.mrtrix.org/u/MrRibbits)\ **Post date:** [October 7, 2019, 5:47pm UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/21 "2019-10-07T17:47:09Z")
> [@rsmith](#): > > Are you absolutely sure that those are the only things being modified by `nifti_tool` ? That’s all I’m modifying with nifti\_tool, and that does the trick. My workaround is getting the job done, so if I’m the only one encountering this issue, don’t change anything just for me 😄 best, Mark ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [October 20, 2019, 1:56am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/22 "2019-10-20T01:56:12Z")
I managed to encounter the same issue with my own data & processing script week before last; hopefully I’ll get the chance to experiment a little more with it… ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [October 22, 2019, 5:16am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/23 "2019-10-22T05:16:52Z")
I had varied success with setting `freq_dim` / `phase_dim` / `slice_dim` via `nifti_tool`; led to `eddy` success on one day, didn’t the next. Must be related to the position of Mercury or something… I do however have an alternative hypothesis, which seems to be working for me thus far (have not yet run to completion or for all permutations of modifications, but it’s not yet crashed where others did today). And there’s some chance this may have been modified in your own manipulations leading to the fix without you noticing. This difference was overlooked in your earlier `fslhd` dumps (should not have trusted @jdtournier’s summary of such 🤦‍♂️): > `pixdim4 nan` > `pixdim4 5.000000` Hypothetically, if one needed to know the size of image voxels in order to choose an appropriate basis field granularity, and this were erroneously calculated by e.g. taking “the geometric mean of the sizes of all image axes” (as opposed to the three spatial axes), this “size” of the fourth axis 4 (which is non-spatial and hence meaningless) would contribute to such a calculation. Propagation of that NaN could conceivably lead to some kind of internal error related to sizes? 🤷‍♂️ ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [October 22, 2019, 6:24am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/24 "2019-10-22T06:24:54Z")
> [@rsmith](#): > > should not have trusted @jdtournier’s summary of such 🤦‍♂️ When will you learn…? 🤪 ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [October 23, 2019, 3:59am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/25 "2019-10-23T03:59:17Z")
Modifying `pixdim4` worked; modifying `*_dim` did not: ```nohighlight root@1d1bca7523c1$ nifti_tool -mod_nim -mod_field dt 1.0 -infiles eddy_in.nii -prefix modified_pixdim root@1d1bca7523c1$ eddy_openmp --imain=modified_pixdim.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --repol --estimate_move_by_susceptibility --out=dwi_post_eddy Setting linear second level model Resetting second level model root@1d1bca7523c1$ nifti_tool -mod_nim -mod_field freq_dim 1 -mod_field phase_dim 2 -mod_field slice_dim 3 -infiles eddy_in.nii -prefix modified_dims root@1d1bca7523c1$ eddy_openmp --imain=modified_dims.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --repol --estimate_move_by_susceptibility --out=dwi_post_eddy Setting linear second level model Resetting second level model Basisfield:: msg=hadamard: Image dimension mismatch EDDY::: MoveBySuscCF.cpp::: NEWMAT::ReturnMatrix EDDY::MoveBySuscCFImpl::grad(const ColumnVector&): Exception thrown EDDY::: Eddy failed with message EDDY::: MoveBySuscCF.cpp::: virtual NEWMAT::ReturnMatrix EDDY::MoveBySuscCF::grad(const ColumnVector&) const: Exception thrown root@1d1bca7523c1$ ``` At our end, we could fairly easily ensure that when writing to NIfTI, any dimensions with NaN size are instead set to some other value. But whether or not we do so I would still be concerned as to why the value stored here would have an effect on `eddy`. I think in some instances the “voxel size” of the fourth dimension is utilised to store the repetition time in fMRI; but for DWI I don’t see how that parameter can have any meaning (if anything, storing a NaN value there actually makes _more_ sense to me than anything else). ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [October 23, 2019, 7:09am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/26 "2019-10-23T07:09:20Z")
> [@rsmith](#): > > but for DWI I don’t see how that parameter can have any meaning (if anything, storing a NaN value there actually makes _more_ sense to me than anything else). That’s my perspective too. What happens if you set it to zero? I could live with that… ---
**Author:** ![MrRibbits](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/3bc359/32.png) [@MrRibbits](https://community.mrtrix.org/u/MrRibbits)\ **Post date:** [October 24, 2019, 3:44pm UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/27 "2019-10-24T15:44:42Z")
Sorry just getting back to this thread now. I agree that setting pixdim4 to 0 instead of NaN shouldn’t have any effect on DWI data (as opposed to fMRI data). I could also live with that fix ! BTW I noticed someone reading this thread has posted on the FSL board asking Jesper about this, not sure if he replied yet. ---
**Author:** ![Antonin\_Skoch](https://community.mrtrix.org/user_avatar/community.mrtrix.org/antonin_skoch/32/358_2.png) [@Antonin\_Skoch](https://community.mrtrix.org/u/Antonin_Skoch)\ **Post date:** [October 26, 2019, 8:18pm UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/28 "2019-10-26T20:18:15Z")
I brought this issue to FSL list. Jesper fixed this for next release. See the relevant thread: [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=FSL;b671062b.1910](https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=FSL;b671062b.1910) Antonin ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [October 28, 2019, 2:15am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/29 "2019-10-28T02:15:40Z")
> What happens if you set it to zero? Execution does succeeed if `pixdim4` is set to zero. But it sounds like an FSL update should fix the issue, in which case (unless there’s some other motive) I’d rather keep the NaN there. ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [October 28, 2019, 7:44am UTC](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754/30 "2019-10-28T07:44:00Z")
> [@rsmith](#): > > But it sounds like an FSL update should fix the issue, in which case (unless there’s some other motive) I’d rather keep the NaN there. My preference too 👍 [Previous page](https://community.mrtrix.org/t/eddys-estimate-move-by-susceptibility-option-causing-crash-on-denoised-data/2754.md?page=1)