Dwipreproc - eddy ERROR

#13

OK, that sounds like a different problem again from the others mentioned in this thread…

My guess is your data come from a Philips scanner…? They have a habit of adding an additional image at the end of the series, which I think is a mean DWI image, computed from the acquired data. Clearly this is not an actual diffusion-weighted image, and typically its DW encoding entry looks ‘odd’ - on our scanners, it shows up as a 0 0 0 1000: a zero vector with a non-zero b-value… This is clearly going cause all manner of confusion for any downstream processing. You could verify this by inspecting the bvecs & bvals files to see if that is the case here (i.e. last column of bvecs contains zeros, but last entry of bvals is non-zero).

Assuming that is indeed the problem, you’ll probably find that updating your installation to the latest version, freshly released a few days ago, fixes the issue since it contains improved handling of DICOM data that should actually be able to deal with precisely these types of data (since the additional computed image shows up with a different ImageType entry in the DICOM headers)…

#14

Thanks for your response
Yes, the data come from a Philips scanner. Their data is as your said.
I build the MRtrix (RC2-2-gca446aad) at Aug 9 2017. I guess that is new version.
I will try again

#15

Hello

I have had a similar issue to the above. When I run dwipreproc -rpe_none DWI_denoise.mif -fslgrad bvecs bvals DWI_eddy.mif -pe_dir AP I get an error,

[ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:467)

If I invoke the failing eddy command in the temporary folder it works. You suggested a buggy python or interference from locale settings. Whilst not an mrtrix issue I was wondering if you knew of how I could go about fixing this? Or given that eddy is running in the temporary folder should I just use the eddy command manually in a script if that’s easier?

Thanks for your help!

Paul

#16

Paul: Can you provide the full error message? The earlier mention in this thread of the locale settings was only a hypothesis, and as far as I can see there was no confirmation from any user that this was indeed the cause of their problem. This thread now has a range of different issues reported, so we really need to see the full details in order to narrow down our suggestions.

#17

Of course.

Command:  mrconvert /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/DWI_dn.mif /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/dwi.mif -fslgrad /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/bvecs /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/bvals
dwipreproc: Changing to temporary directory (/home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/)
dwipreproc: [WARNING] Total readout time not provided at command-line; assuming sane default of 0.1
Command:  mrinfo dwi.mif -export_grad_mrtrix grad.b
Command:  dwi2mask dwi.mif - | maskfilter - dilate - | mrconvert - mask.nii -datatype float32 -stride -1,+2,+3
Command:  mrconvert dwi.mif -import_pe_table dwi_manual_pe_scheme.txt dwi.nii -stride -1,+2,+3,+4 -export_grad_fsl bvecs bvals -export_pe_eddy eddy_config.txt eddy_indices.txt
Command:  eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: 
dwipreproc: **[ERROR]** Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:467)
dwipreproc: Output of failed command:
I'm thrown
terminate called after throwing an instance of 'EDDY::KMatrixException'
  what():  KMatrixException: msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled
dwipreproc: Changing back to original directory (/home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/

Then by invoking eddy manually in the temp folder like so; eddy --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_eddy it works to produce an eddy corrected file.

Thanks for your help

#18

The actual error is here:

Your b-values are not sufficiently consistent for each shell, and eddy throws out the data in case they were not acquired using a multi-shell scheme. If you know your data are multi-shell (not DSI), you can force eddy to accept your data with the right option - see the FSL wiki for details. You should be able to pass that option using the -eddy_options option to dwipreproc*.

As to why your manual eddy call works, I’m guessing this is because your eddy and eddy_openmp are from different versions of FSL, and one of them is more strict than the other. On my system, FSL 5.0.8 only provides eddy, while 5.0.9 provides eddy_openmp and eddy_cuda - no eddy as such…

*superseded by dwifslpreproc in version 3.0.0

#19

One other possibility of what might be going on here, since I’ve seen a couple of people being forced to use the --data_is_shelled option:

In MRtrix3, we run a clustering algorithm in order to group volumes into shells according to b-value, which accounts for the fact that the b-values of those volumes may not be precisely equivalent. In addition to the b-values that are provided in the DICOMs, these values may additionally be perturbed by MRtrix3 when it normalises each diffusion gradient direction and applies the corresponding scaling to the b-value. Therefore, if eddy does not account for the possibility of small variations in b-value, it’s possible that a bvecs / bvals pair created by an MRtrix3 command (e.g. in the middle of dwipreproc) may cause eddy to stumble, whereas using the “original” bvecs / bvals and invoking eddy directly may work.

Just a hypothesis right now… Wouldn’t explain why @uclpz was able to run eddy directly from within the script temporary directory, that’s more likely an eddy version mismatch as @jdtournier suggested. But just putting the idea out there in case many people are encountering this “Data not shelled” issue.

#20

Yeah, depending on your FSL version, the definition of “shelled” (or not) may be rather strict. This discussion was historically started somewhere here, if I recall correctly: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=fsl;9bfdeaed.1510

Note that there’s also criteria on numbers of directions per shell, and especially these used to be (or are still) rather strict, resulting in rejection of even quite “common” protocols. I’m not sure what their exact constraints/heuristics currently are, or whether these are explicitly documented somewhere though…

#21

Thanks for your help on this. My data is definitely multishell. I did inspect my bvalues which are consistent for each shell - 0, 700, 2000. Curiously if I use the data is shelled option using the command;

dwipreproc DWI_dn.mif DWI_eddy_bval.mif -rpe_none -pe_dir AP -fslgrad bvecs bvals -eddy_options "--data_is_shelled "

I now get the following error below. Any ideas to the cause of this? Thanks again for all your help.

Traceback (most recent call last):
  File "/midas-data/software/mrtrix3_25.5.17/bin/dwipreproc", line 506, in <module>
    run.command('mrconvert dwi_post_eddy' + fsl_suffix + ' result.mif' + stride_option + ' -fslgrad ' + bvecs_path + ' bvals')
  File "/midas-data/software/mrtrix3_25.5.17/lib/mrtrix3/run.py", line 61, in command
    shebang = _shebang(line[0])
  File "/midas-data/software/mrtrix3_25.5.17/lib/mrtrix3/run.py", line 329, in _shebang
    path = find_executable(exeName(item))
  File "/usr/lib64/python2.6/distutils/spawn.py", line 191, in find_executable
    if not os.path.isfile(executable):
  File "/usr/lib64/python2.6/genericpath.py", line 29, in isfile
    st = os.stat(path)
TypeError: stat() argument 1 must be encoded string without NULL bytes, not str
[trackhd@pc8-024 060443961]$ dwipreproc DWI_dn.mif DWI_eddy_bval.mif -rpe_none -pe_dir AP -fslgrad bvecs bvals -eddy_options "--data_is_shelled "
#22

I think you have to add one whitespace character after your double quotes, i.e.
" –data_is_shelled "

#23

Given this output:

It seems to me more likely that the problem might be due to using python version 2.6. As stated in the docs, we require at least version 2.7, at least for the configure & build steps… Worth trying with version 2.7 or 3.X, it might be as simple as that.

#24

Hello all,

I am having a similar issue with the ones mentioned above. When running " dwipreproc data_denoise.mif/ dwi_preprocessed.mif -rpe_none -pe_dir j- " I get the following error:

[ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
terminate called after throwing an instance of 'EDDY::EddyException'
  what():  eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
dwipreproc: Changing back to original directory (/home/suminiky/Downloads/MRTRIX)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/suminiky/Downloads/MRTRIX/dwipreproc-tmp-Y06916/

Afterwards, when running eddy in the temp folder I get this:

eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
terminate called after throwing an instance of 'EDDY::EddyException'
  what():  eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
Aborted (core dumped)

Any ideas on what the issue could be?

Best,
Sabina

#25

Hi Sabina,

This is in fact an unrelated error, which has been reported here. This is not an error within dwipreproc, but something that is generated within eddy that dwipreproc is simply passing along. It claims that the EPI total readout time of your data is not “realistic”, and hence there must have been some kind of error made during your data preparation.

Due to the relationship between readout time, field inhomogeneity estimation, and geometric correction of EPI distortions, you should simply be able to e.g. halve the readout times in all of your images, and processing should operate as expected. The mrconvert -set_property option should be useful for this, in addition to this development-branch documentation page (not yet part of the main documentation, but will be soon).

Rob

#26

Hi Rob,

The answer you gave me worked last time, so thank you! However, now I need to analyze a new set of data and I am yet again receiving an error, but a different one:

dwipreproc: [ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
I’m thrown
terminate called after throwing an instance of ‘EDDY::KMatrixException’
what():
dwipreproc: Changing back to original directory (/home/suminiky/Documents/DATA/Menzel_preop)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy

What could be wrong this time?

Best,
Sabina

#27

Hello all,

I am having a similar issue with the ones mentioned above. When running “dwipreproc dwi_denoised.mif dwi_processed.mif -pe_dir AP -rpe_all -readout_time 0.124” I get the following error:

Command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy
dwipreproc:
dwipreproc: [ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
dwipreproc: Changing back to original directory (/home/wpy/Desktop/FBA/p01)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/wpy/Desktop/FBA/p01/dwipreproc-tmp-L9W43S/

image
image.png1397×826 183 KB

Do you have any ideas of what could be wrong?

Regards,
Pinyi Wang

#28 
I’m thrown
terminate called after throwing an instance of ‘EDDY::KMatrixException’
what():

This error is entirely internal to eddy; MRtrix3’s dwipreproc script is simply passing this error message from the underlying command to the user. So I can really only suggest going into the temporary directory that was preserved by the script, and attempting to invoke eddy directly. You can also manually inspect all of the files that are being provided as input to eddy, and ensure that they are sensible according to the usage of that command. If that seems to be the case, then your question should instead be posed on the FSL mailing list, as it is independent of MRtrix3.

Note: If you say to FSL that you’ve encountered this issue when trying to run an MRtrix3 script, they won’t help you. You must validate yourself that the issue is indeed with eddy, and not with MRtrix3’s wrapping thereof, and then report it as such. Alternatively, if your investigation shows that dwipreproc is providing inappropriate data to eddy, then this is precisely the information that needs to be provided here in order for the issue to be fixed within MRtrix3.

dwipreproc: Output of failed command:
dwipreproc: Changing back to original directory (/home/wpy/Desktop/FBA/p01)

In your case @PinyiWang, eddy appears to not be providing any error message to the terminal whatsoever. Nevertheless, even in this case, the same instructions as given above to @Sabina_R apply to your case also.

1 Like
Dwipreproc -eddy error solution
#29

Thanks for your response!
I will try it!

Best,
Pinyi

#30

Hello all,

I am back with yet another error (in the meantime I have changed computers and am now working on a MacOS High Sierra). What I get now is a little bit different:

dwipreproc: [ERROR] Command failed: eddy --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:853)
dwipreproc: Output of failed command:
dwipreproc: 
dwipreproc: Changing back to original directory (/Data/p01)
dwipreproc: Script failed while executing the command: eddy --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /Data/p01/dwipreproc-tmp-XX4IFY/

And when running eddy directly from the temporary folder, the result is:

eddy --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy -v
Reading images
Loading prediction maker
Evaluating prediction maker model
Calculating parameter updates
Segmentation fault: 11

I know this might just be totally due to eddy, however I have yet to receive a clear answer from the FSL mailing list regarding my data.

Would it maybe be possible to send you a sample of my images for you to check out and maybe get to the bottom of this?
I manually inspected the files that go into eddy and they seem to be sensible, but I am still a novice and would not say that that is 100% the case. What exactly should I be looking for?

Thank you again and sorry for being so persistent :blush:

Best,
Sabina

#31

Hi Sabina,

Given you are able to trigger the fault by executing eddy directly yourself, unless you can find something egregiously wrong with the data that dwipreproc is generating as the input to eddy, the segmentation fault is fundamentally occurring inside of eddy and is hence out of our control.

It would be worth trying to go from your raw image data to the eddy step without invoking any MRtrix3 commands or scripts at all; i.e. running topup manually, generating a processing mask & all other associated files for eddy. Only then can you genuinely prove that you’re encountering an issue with eddy and not that MRtrix3 is somehow providing it with bad data. I would suggest that if you so much as mention in passing that you’ve used any MRtrix3 commands at all in generating the input to eddy when posting to their mailing list, the FMRIB team will be hesitant to commit time to diagnosing your issue; just as I myself am hesitant to put my own time into sorting out people’s eddy issues unless it’s provably a fault of dwipreproc.

Rob

#32

Hi Rob,

Thank you for taking the time to answer. I eventually analyzed the data once again and got an identical error as the one here http://community.mrtrix.org/t/siemens-vs-philips-dwipreproc-eddy-error/1301/3 and it turned out that I also had poorly distributed directions, which is probably why eddy did not want to take it…I have since started using newer data with different acquisition parameters and I could run dwipreproc on it with no problems so far, luckily.

Best,
Sabina