, NEWIMAGE::volume&, bool) const
> eddy 0x0000000100040fae EDDY::ECScanManager::GetUnwarpedScan(unsigned int, NEWIMAGE::volume&, EDDY::ScanType) const
> eddy 0x000000010000353c EDDY::LoadPredictionMaker(EDDY::EddyCommandLineOptions const&, EDDY::ScanType, EDDY::ECScanManager const&, unsigned int, NEWIMAGE::volume&, bool)
> eddy 0x0000000100006073 EDDY::Register(EDDY::EddyCommandLineOptions const&, EDDY::ScanType, unsigned int, EDDY::SecondLevelECModel, EDDY::ECScanManager&, NEWMAT::Matrix&, NEWMAT::Matrix&)
> eddy 0x0000000100007f96 main
> eddy 0x0000000100001a48 start
> ??? 0x0000000000000008 0x0
> (python2.7.3) CBRs-iMac:dwipreproc-tmp-NAIN28 dionperd$
> (python2.7.3) CBRs-iMac:dwipreproc-tmp-NAIN28 dionperd$ locale
> LANG=“en\_US.UTF-8”
> LC\_COLLATE=“en\_US.UTF-8”
> LC\_CTYPE=“en\_US.UTF-8”
> LC\_MESSAGES=“en\_US.UTF-8”
> LC\_MONETARY=“en\_US.UTF-8”
> LC\_NUMERIC=“en\_US.UTF-8”
> LC\_TIME=“en\_US.UTF-8”
> LC\_ALL=
---
### Author:  [@Dionysios\_Perdikis](https://community.mrtrix.org/u/Dionysios_Perdikis)
#### Post date: [May 31, 2017, 11:44am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/8 "2017-05-31T11:44:35Z")
Apparently the problem for me seems to be that the original dicoms were in mosaic form.
Once I got some nifti files, and after I converted to .mif and added the gradient information there was no more problem.
How does mrtrix3 handle this format, and how can it be converted?
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [May 31, 2017, 12:00pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/9 "2017-05-31T12:00:17Z")
OK, I can see how this could cause some confusion…
_MRtrix3_ should handle this format just fine - but where it can fail is when the DICOM files have been processed by some third party application, particularly for the purposes of anonymisation - this process often strips out so-called private tags from the DICOM files, which are vendor-specific. The fact that you needed to add the gradient encoding information separately suggests that you would indeed have been provided with a stripped-down version of the original Siemens DICOM, from which the proprietary Siemens CSA tags have been removed. Unfortunately, these tags contain the information required to correctly read the Siemens mosaic format, as well as the diffusion encoding information. [More details here](http://mrtrix.readthedocs.io/en/latest/tips_and_tricks/dicom_handling.html#error-no-diffusion-encoding-information-found-in-image) if you’re interested.
My guess is if you go back to the original DICOMs, it would work fine. I’m not sure where you got the NIfTI version from, but presumably that was either converted from the original DICOMs, or converted using a more heuristic approach (you can guess what the right parameters would be for the mosaic, up to a certain point). But _MRtrix3_ currently relies on the Siemens private CSA tags to read these correctly.
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [June 5, 2017, 4:08am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/10 "2017-06-05T04:08:13Z")
If you are able to go back to the original DICOMs and run `eddy` without a problem, it would be useful for us to get an example of your images. If indeed some anonymisation process is preventing the correct conversion of Siemens DICOMs, this error should preferably be raised _well before_ `dwipreproc` gets to the point of invoking `eddy`. I would also be curious to know exactly what type of input image is able to survive `mrconvert` but cause a segmentation violation in `eddy` (FMRIB may also be interested to see such an image).
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [June 5, 2017, 9:02am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/11 "2017-06-05T09:02:22Z")
@rsmith: the problem is that the DICOM data were provided in mosaic format. If you strip out the Siemens CSA info, _MRtrix3_ can’t reformat these into 3 volumes - they remain as 2D slices with all the slices in a single large montage. If the user also provides the DW gradient info manually (which they did), then I guess `eddy` is the first command that will actually fail (no `topup` used on this invocation). There’s a good chance the mask produced by `dwi2mask` will also be empty, given that the cleanup operations operate at a 3D level, and this is likely to cause `eddy` to then crash out - but `dwi2mask` probably won’t itself crash (might be a idea for it to raise an error if the mask is empty, though…).
So either an empty mask, or the fact that `eddy`'s been presented with a single slice, which means even trilinear interpolation can’t be done, for example, or there can’t be any through-slice gradients for registration, or any number of other related problems…
---
### Author:  [@YeWu](https://community.mrtrix.org/u/YeWu)
#### Post date: [August 10, 2017, 8:18pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/12 "2017-08-10T20:18:20Z")
Hi, I also encountered the same problem that dwipreproc doesn’t work during eddy command.
I tried to do dwipreproc from DICOM and NIFTI after mrconvert respectively, still have the same error. When I tried to convert DICOM to NIFTI by MRICron and run dwipreproc, it does work.
I found that dimensions of the nifti files from the two different ways are a little different. Actually, this data should be 128 x 128 x 75 x 33. But I’m not sure if this is an important problem for that eddy doesn’t work.
From MRICron
Dimensions: 128 x 128 x 75 x 33
Voxel size: 2 x 2 x 2 x 10.0674
Data strides: [-1 2 3 4]
Format: NIfTI-1.1 (GZip compressed)
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 2.5892550945281982
Transform: 0.9939 -0.1092 0.01662 -114.9
0.1103 0.988 -0.1081 -124.4
-0.004625 0.1092 0.994 -85.37
comments: TE=91.52799988;sec=73829.0400
From MRtrix
Dimensions: 128 x 128 x 75 x 34
Voxel size: 2 x 2 x 2 x ?
Data strides: [-1 -2 3 4]
Format: NIfTI-1.1 (GZip compressed)
Data type: unsigned 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 2.5892550945281982
Transform: 0.9939 -0.1092 0.01662 -114.9
0.1103 0.988 -0.1081 -124.4
-0.004625 0.1092 0.994 -85.37
mrtrix\_version: 3.0\_RC2-2-gca446aad
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [August 10, 2017, 8:56pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/13 "2017-08-10T20:56:35Z")
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](http://www.mrtrix.org/2017/07/31/mrtrix-3-0-release-candidate-2/), fixes the issue since it contains [improved handling of DICOM data](https://community.mrtrix.org/t/mrtrix-3-0-release-candidate-2/1065/9) 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)…
---
### Author:  [@YeWu](https://community.mrtrix.org/u/YeWu)
#### Post date: [August 11, 2017, 1:50am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/14 "2017-08-11T01:50:19Z")
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
---
### Author:  [@uclpz](https://community.mrtrix.org/u/uclpz)
#### Post date: [August 31, 2017, 4:16pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/15 "2017-08-31T16:16:43Z")
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
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [August 31, 2017, 11:34pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/16 "2017-08-31T23:34:34Z")
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.
---
### Author:  [@uclpz](https://community.mrtrix.org/u/uclpz)
#### Post date: [September 1, 2017, 12:43pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/17 "2017-09-01T12:43:00Z")
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
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [September 4, 2017, 12:20pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/18 "2017-09-04T12:20:22Z")
The actual error is here:
> [@uclpz](#):
>
> ```auto
> terminate called after throwing an instance of 'EDDY::KMatrixException'
> what(): KMatrixException: msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled
>
> ```
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](https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/eddy/UsersGuide#A--data_is_shelled). You should be able to pass that option using the [`-eddy_options` option to `dwipreproc`](http://mrtrix.readthedocs.io/en/3.0_rc3/reference/scripts/dwipreproc.html#other-options-for-the-dwipreproc-script)\*.
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](https://mrtrix.readthedocs.io/en/latest/reference/commands/dwifslpreproc.html) in version 3.0.0
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [September 5, 2017, 5:59am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/19 "2017-09-05T05:59:32Z")
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](https://github.com/MRtrix3/mrtrix3/blob/master/src/dwi/shells.cpp#L292) 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](https://github.com/MRtrix3/mrtrix3/blob/master/src/dwi/gradient.h#L46-L47) 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.
---
### Author:  [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)
#### Post date: [September 5, 2017, 6:08am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-error/913/20 "2017-09-05T06:08:16Z")
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](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…
[Next page](https://community.mrtrix.org/t/dwipreproc-eddy-error/913.md?page=2)