Dwipreproc - eddy ERROR

mairapinto · May 23, 2017, 4:44pm

Hello everyone,

I am having some trouble in the pre-processing step of the analysis, I have single-shell Philips diffusion image with 32 gradient directions. Apparently, the eddy command is not working properly:

$ dwipreproc MRTRIX_steps/G1_001_denoised.mif MRTRIX_steps/G1_001_preproc.mif -rpe_none -pe_dir AP -nocleanup -info

Command: eddy --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 --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:
Segmentation violation, Address not mapped, Offending address = 0x40
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::find_matching_option(std::string const&) [0x7fd6d1a2552a]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_option(std::string const&, std::string const&, char**, int, int) [0x7fd6d1a2561a]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_long_option(std::string const&) [0x7fd6d1a25dab]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_command_line(unsigned int, char**, int, bool) [0x7fd6d1a268c8]
dwipreproc: Changing back to original directory (/home/msiqueira/Desktop/TESTE_MRTRIX/G1_001)
dwipreproc: Script failed while executing the command: eddy --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/msiqueira/Desktop/TESTE_MRTRIX/G1_001/dwipreproc-tmp-AMOF7L/

Do you have any ideas of what could be wrong?

Regards,

Maíra Pinto

jdtournier · May 24, 2017, 9:13am

This looks like eddy crashing when trying to interpret the command line arguments - but I can’t see anything overtly wrong with that. A wild shot in the dark would be that your locale settings (i.e. character encoding) are somehow getting in the way (I’ve definitely seen some odd behaviour of this nature in the past). One way to try to figure this out is to go to the temporary folder and invoke the failing eddy command manually:

cd /home/msiqueira/Desktop/TESTE_MRTRIX/G1_001/dwipreproc-tmp-AMOF7L/
eddy --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy

If that command completes OK, then I’d suspect a buggy python installation, or interference from your locale settings, or something of that nature that somehow interferes with the relationship between the binary representation of the command string and its graphical rendering on the terminal (if that makes any sense…).

mairapinto · May 24, 2017, 12:55pm

Thank you @jdtournier.

I tried running the eddy command in the temporary folder, however, the same error continues happening:

msiqueira@isis:~/Desktop/TESTE_MRTRIX/G1_001/dwipreproc-tmp-U1XJ2J$ eddy --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
Segmentation violation, Address not mapped, Offending address = 0x40
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::find_matching_option(std::string const&) [0x7f2d4c1c752a]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_option(std::string const&, std::string const&, char**, int, int) [0x7f2d4c1c761a]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_long_option(std::string const&) [0x7f2d4c1c7dab]
/usr/lib/fsl/5.0/libutils.so Utilities::OptionParser::parse_command_line(unsigned int, char**, int, bool) [0x7f2d4c1c88c8]
eddy ) [0x44c1d5] [
eddy ) [0x44f960] [
eddy ) [0x40feae] [
/lib/x86_64-linux-gnu/libc.so.6 __libc_start_main [0x7f2d4b320830]
eddy ) [0x412059] [

My locale settings are:

msiqueira@isis:~/Desktop/TESTE_MRTRIX/G1_001/dwipreproc-tmp-U1XJ2J$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE=pt_BR.UTF-8
LC_NUMERIC=pt_BR.UTF-8
LC_TIME=pt_BR.UTF-8
LC_COLLATE=“en_US.UTF-8”
LC_MONETARY=pt_BR.UTF-8
LC_MESSAGES=“en_US.UTF-8”
LC_PAPER=pt_BR.UTF-8
LC_NAME=pt_BR.UTF-8
LC_ADDRESS=pt_BR.UTF-8
LC_TELEPHONE=pt_BR.UTF-8
LC_MEASUREMENT=pt_BR.UTF-8
LC_IDENTIFICATION=pt_BR.UTF-8
LC_ALL=

Is it different from yours? Do you think that might be the problem?

jdtournier · May 24, 2017, 1:17pm

Locale doesn’t seem to be the issue (main setting is en_US.UTF-8, which is fine). The fact that your command doesn’t work when invoked directly also points to this being a genuine problem with eddy here… I’m out of ideas - maybe others will have a better idea of what the problem might be?

AmirHussein · May 25, 2017, 2:40pm

Hi all,

I have encountered a problem with the same topic, so I’m just posting it here.

I’m doing dwipreproc on a multishell 30 direction dwi data (b=1000,2000) with 2 pairs of b0s concatenated (b0s.mif) on ubuntu 16.04 using the command below:

dwipreproc dwi_denoised.mif dwi_preprocessed.mif -pe_dir AP -rpe_pair -se_epi b0s.mif

It gave me an error when it reached eddy, so I checked for the solutions and downloaded eddy_openmp here inside fsl directory and changed the permissions. I ran the script again and encountered this error:

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:467)
dwipreproc: Output of failed command:
eddy: msg=ECScanManager::mean_of_first_b0: Zero mean
terminate called after throwing an instance of ‘EDDY::EddyException’
what(): eddy: msg=ECScanManager::mean_of_first_b0: Zero mean

I’ll be glad to hear any possible solutions.

Bests,
Amir

mairapinto · May 25, 2017, 8:48pm

I solved my problem

Actually, there were some problems in accessing the memory where eddy was installed, so we deleted all fsl and eddy files and reinstalled everything.

The link where we downloaded:
Http://neuro.debian.net/pkgs/fsl-5.0-eddy-nonfree.html

@AmirHussein maybe there is some configuration in your computer that is not correct, you could try installing again and check that.

Dionysios_Perdikis · May 29, 2017, 2:43pm

Dear all,

I am also having the exact same problem as @mairapinto (check the log below, where you can see the locale also, as well as what happens when running it from the temporary folder).

I am on a iMac OS 10.12.5, and it is the first time I try to run Mrtrix3 after updating to MacOS Sierra…

The only other difference is that I had to add the gradient information as a separate text file with a
mrconvert -grad
command.

Any ideas beside reinstalling FSL?..

Thank you very much in advance.

(python2.7.3) CBRs-iMac:DWI dionperd$ dwipreproc AP ./dwi_raw.mif ./dwi.mif -rpe_none -nthreads MRTRIX_THRDS -force -verbose dwipreproc: dwipreproc: 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. dwipreproc: dwipreproc: Generated temporary directory: /tmp/dwipreproc-tmp-NAIN28/ Command: mrconvert /Users/dionperd/VEP/CC/TVB1/DWI/dwi_raw.mif /tmp/dwipreproc-tmp-NAIN28/series.mif dwipreproc: Changing to temporary directory (/tmp/dwipreproc-tmp-NAIN28/) dwipreproc: Command: '/Users/dionperd/mrtrix3/release/bin/mrinfo series.mif -size' (piping data to local storage) dwipreproc: Result: 1024 1024 1 62 dwipreproc: Command: '/Users/dionperd/mrtrix3/release/bin/mrinfo series.mif -dwgrad' (piping data to local storage) dwipreproc: Result: 0 0 0 0 -0.203751 0.51962 -0.829747 999.999 0.198467 0.520485 -0.830485 999.999 0.402595 0.176183 -0.898263 1000 -0.403742 0.731789 -0.54907 1000 -0.202258 0.941879 -0.268244 999.999 -0.853214 0.518371 -0.0575979 1000 -0.731345 0.520189 -0.441064 1000 -0.407833 0.176684 -0.895798 999.999 -0.733285 0.176636 -0.656577 1000 -0.650238 0.730701 0.208008 1000 -0.322074 0.94103 0.103592 1000 -0.324168 0.520046 0.790233 1000 -0.650269 0.520333 0.553537 999.999 -0.978605 0.176551 0.105649 1000 -0.854682 0.176502 0.488227 1000 0.00073429 0.731522 0.681817 999.999 0.00282216 0.941805 0.336149 999.999 0.653958 0.519271 0.550179 1000 0.329783 0.520575 0.787557 1000 0.197481 -0.176631 -0.964263 1000 0.203803 0.176381 0.962992 1000 0.651114 0.730603 0.205594 999.999 0.324138 0.940969 0.0975322 1000 0.200327 0.940724 -0.273693 1000 0.403742 0.731789 -0.54907 1000 0.732622 0.176654 -0.657312 1000 0.728929 0.519567 -0.445772 1000 0.852216 0.51932 -0.0635149 1000 0.857573 0.177031 0.482937 1000 0.979299 0.176333 0.0993995 1000 0 0 0 0 -0.203751 0.51962 -0.829747 999.999 0.198467 0.520485 -0.830485 999.999 0.402595 0.176183 -0.898263 1000 -0.403742 0.731789 -0.54907 1000 -0.202258 0.941879 -0.268244 999.999 -0.853214 0.518371 -0.0575979 1000 -0.731345 0.520189 -0.441064 1000 -0.407833 0.176684 -0.895798 999.999 -0.733285 0.176636 -0.656577 1000 -0.650238 0.730701 0.208008 1000 -0.322074 0.94103 0.103592 1000 -0.324168 0.520046 0.790233 1000 -0.650269 0.520333 0.553537 999.999 -0.978605 0.176551 0.105649 1000 -0.854682 0.176502 0.488227 1000 0.00073429 0.731522 0.681817 999.999 0.00282216 0.941805 0.336149 999.999 0.653958 0.519271 0.550179 1000 0.329783 0.520575 0.787557 1000 0.197481 -0.176631 -0.964263 1000 0.203803 0.176381 0.962992 1000 0.651114 0.730603 0.205594 999.999 0.324138 0.940969 0.0975322 1000 0.200327 0.940724 -0.273693 1000 0.403742 0.731789 -0.54907 1000 0.732622 0.176654 -0.657312 1000 0.728929 0.519567 -0.445772 1000 0.852216 0.51932 -0.0635149 1000 0.857573 0.177031 0.482937 1000 0.979299 0.176333 0.0993995 1000 dwipreproc: Command: '/Users/dionperd/mrtrix3/release/bin/mrinfo series.mif -stride' (piping data to local storage) dwipreproc: Result: -1 -2 3 4 Command: mrconvert series.mif dwi_pre_topup.nii -stride -1,+2,+3,+4 dwipreproc: Creating phase-encoding configuration file Command: dwi2mask series.mif - | maskfilter - dilate - | mrconvert - mask.nii -datatype float32 -stride -1,+2,+3 Command: mrconvert series.mif - -stride -1,+2,+3,+4 | mrinfo - -export_grad_fsl bvecs bvals Command: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy dwipreproc: dwipreproc: [ERROR] Command failed: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy dwipreproc: Output of failed command: Segmentation violation, Address not mapped, Offending address = 0x504a25004 eddy 0x000000010006395b SPLINTERPOLATOR::Splinterpolator<float>::derivatives_at_i(unsigned int const*, unsigned int const*, double*) const eddy 0x0000000100063f79 SPLINTERPOLATOR::Splinterpolator<float>::DerivXYZ(unsigned int, unsigned int, unsigned int, unsigned int) const eddy 0x0000000100055df2 EDDY::FieldUtils::GetJacobianFrom1DField(NEWIMAGE::volume<float> const&, unsigned int) eddy 0x0000000100057e6f EDDY::FieldUtils::GetJacobian(NEWIMAGE::volume4D<float> const&, EDDY::AcqPara const&) eddy 0x000000010003ecf9 EDDY::ECScan::field_for_scan_to_model_transform(boost::shared_ptr<NEWIMAGE::volume<float> const>, NEWIMAGE::volume<float>*, NEWIMAGE::volume<float>*) const eddy 0x000000010004031a EDDY::ECScan::transform_to_model_space(NEWIMAGE::volume<float> const&, boost::shared_ptr<NEWIMAGE::volume<float> const>, NEWIMAGE::volume<float>&, bool) const eddy 0x0000000100040fae EDDY::ECScanManager::GetUnwarpedScan(unsigned int, NEWIMAGE::volume<float>&, EDDY::ScanType) const eddy 0x000000010000353c EDDY::LoadPredictionMaker(EDDY::EddyCommandLineOptions const&, EDDY::ScanType, EDDY::ECScanManager const&, unsigned int, NEWIMAGE::volume<float>&, 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 dwipreproc: Changing back to original directory (/Users/dionperd/VEP/CC/TVB1/DWI) dwipreproc: Script failed while executing the command: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy dwipreproc: For debugging, inspect contents of temporary directory: /tmp/dwipreproc-tmp-NAIN28/ (python2.7.3) CBRs-iMac:DWI dionperd cd /tmp/dwipreproc-tmp-NAIN28/
(python2.7.3) CBRs-iMac:dwipreproc-tmp-NAIN28 dionperd$
(python2.7.3) CBRs-iMac:dwipreproc-tmp-NAIN28 dionperd$ eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
Segmentation violation, Address not mapped, Offending address = 0x505401004
eddy 0x000000010006395b SPLINTERPOLATOR::Splinterpolator::derivatives_at_i(unsigned int const*, unsigned int const*, double*) const
eddy 0x0000000100063f79 SPLINTERPOLATOR::Splinterpolator::DerivXYZ(unsigned int, unsigned int, unsigned int, unsigned int) const
eddy 0x0000000100055df2 EDDY::FieldUtils::GetJacobianFrom1DField(NEWIMAGE::volume const&, unsigned int)
eddy 0x0000000100057e6f EDDY::FieldUtils::GetJacobian(NEWIMAGE::volume4D const&, EDDY::AcqPara const&)
eddy 0x000000010003ecf9 EDDY::ECScan::field_for_scan_to_model_transform(boost::shared_ptr<NEWIMAGE::volume const>, NEWIMAGE::volume, NEWIMAGE::volume) const
eddy 0x000000010004031a EDDY::ECScan::transform_to_model_space(NEWIMAGE::volume const&, boost::shared_ptr<NEWIMAGE::volume const>, 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=

Dionysios_Perdikis · May 31, 2017, 11:44am

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?

jdtournier · May 31, 2017, 12:00pm

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

rsmith · June 5, 2017, 4:08am

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

jdtournier · June 5, 2017, 9:02am

@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…

YeWu · August 10, 2017, 8:18pm

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

jdtournier · August 10, 2017, 8:56pm

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

YeWu · August 11, 2017, 1:50am

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

uclpz · August 31, 2017, 4:16pm

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

rsmith · August 31, 2017, 11:34pm

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.

uclpz · September 1, 2017, 12:43pm

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

jdtournier · September 4, 2017, 12:20pm

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

rsmith · September 5, 2017, 5:59am

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.

ThijsDhollander · September 5, 2017, 6:08am

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…