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