Eddy error from dwifslpreproc

Dear mrtrix experts,

I’ve been trying to run the dwifslpreproc step after dwidenoise and mrdegibbs.
I’m using a MacBook and mrconvert 3.0.3-2-g4824f0e2.
I used the command:
dwifslpreproc dwi_denoised_unringed.mif dwi_denoised_unringed_preproc.mif -rpe_none -pe_dir ap -readout_time 0.55
I encountered an error as following:

dwifslpreproc: Note that this script makes use of commands / algorithms that have relevant articles for citation; INCLUDING FROM EXTERNAL SOFTWARE PACKAGES. Please consult the help page (-help option) for more information.
dwifslpreproc: Generated scratch directory: /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/
Command:  mrconvert /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwi_denoised_unringed.mif /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/dwi.mif -json_export /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/dwi.json
dwifslpreproc: Changing to scratch directory (/Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/)
Command:  mrinfo dwi.mif -export_grad_mrtrix grad.b
Command:  dwi2mask dwi.mif - | maskfilter - dilate - | mrconvert - eddy_mask.nii -datatype float32 -strides -1,+2,+3
Command:  mrconvert dwi.mif -import_pe_table dwi_manual_pe_scheme.txt eddy_in.nii -strides -1,+2,+3,+4 -export_grad_fsl bvecs bvals -export_pe_eddy eddy_config.txt eddy_indices.txt
Command:  eddy_cuda7.5 --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --slm=linear --out=dwi_post_eddy --verbose
dwifslpreproc: CUDA version of 'eddy' was not successful; attempting OpenMP version
Command:  eddy --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --slm=linear --out=dwi_post_eddy --verbose

dwifslpreproc: [ERROR] eddy* --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --slm=linear --out=dwi_post_eddy --verbose (app.py:196)
dwifslpreproc: [ERROR] Information from failed command:
               Reading images
               EDDY:::  AcqPara::AcqPara: Unrealistic read-out time
               EDDY:::  EddyHelperClasses.cpp:::  EDDY::AcqPara::AcqPara(const NEWMAT::ColumnVector &, double):  Exception thrown
               EDDY::: Eddy failed with message 
               dyld: Library not loaded: @rpath/libcublas.7.5.dylib
                 Referenced from: /usr/local/fsl/bin/eddy_cuda7.5
                 Reason: image not found
dwifslpreproc: [ERROR] For debugging, inspect contents of scratch directory: /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/
dwifslpreproc: Scratch directory retained; location: /Volumes/Ziqian_Book/Dr_chen/DTI_cst_ziqian_c/cross_sectional/DTI/hc004/dwifslpreproc-tmp-27A09J/
1 Like

Hey mate, how did you calculate your readout time? I had this error once and I found out I was calculating it wrong. It should be

Echo Spacing x 0.001 x EPI Factor

as stated in the eddy/Faq website. Yours looks pretty high which might explain the error.

Thanks, friend.
How do you export the EPI Factor?
I converted DICOM to nii by MRIcroGL and got total readout time. Around 0.2.
But it still reported the same error after I modified -readout_time to 0.2.

I’m not sure how you “export” it. In my data this value found in the method file, under the PVM_EpiNEchoes entry (I’m using a Bruker scanner with Paravision software). Ask the person who performed the scan to help you find this value, or at least the details of the scanner/software so you can ask around to other people who use similar setup where they find the value you need.

Good luck!

eddy will throw an error if the total readout time is 0.2 or greater (from memory). I am not aware of any reason why.

If you do not have different readout times between different volumes, then the precise value is inconsequential from the perspective of eddy's internal calculations AFAIK. Indeed if you were to simply omit the -readout_time option, and allow dwifslpreproc to substitute in an agnostic default of 0.1, processing should proceed.