Eddy's estimate move by susceptibility option causing crash on denoised data?

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 :smile:

best,
Mark

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…

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 :man_facepalming:):

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? :man_shrugging:

When will you learn…? :crazy_face:

Modifying pixdim4 worked; modifying *_dim did not:

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).

That’s my perspective too. What happens if you set it to zero? I could live with that…

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.

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
Antonin

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.

My preference too :+1: