# \[ERROR\]: Not classified into shells **URL:** \ **Category:** Uncategorized\ **Created:** [August 17, 2020, 2:08pm UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006 "2020-08-17T14:08:47Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![FL33TW00D](https://community.mrtrix.org/user_avatar/community.mrtrix.org/fl33tw00d/32/3371_2.png) [@FL33TW00D](https://community.mrtrix.org/u/FL33TW00D)\ **Post date:** [August 17, 2020, 2:08pm UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/1 "2020-08-17T14:08:47Z")
Hi MRtrix Team, I am attempting to preprocess some of the DTI data provided by the OASIS-3 dataset. Upon running the dwifslpreproc script with the following arguments: ```auto dwifslpreproc sub-OAS30141_dwi_den.mif sub-OAS30141_dwi_den_preproc.mif -nocleanup -rpe_none -pe_dir j- -eddy_options "--slm=linear --data_is_shelled" ``` I recieve the following error: ```auto [ERROR] DWI volumes could not be classified into b-value shells; gradient encoding may not represent a HARDI sequence ``` This the values from my .bval file: ```auto 0 50 350 600 900 1150 100 400 650 950 150 450 700 1000 1300 200 500 800 1050 1350 300 850 1100 1400 ``` Any clues on how to fix this? Many Thanks, Christopher Fleetwood ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [August 23, 2020, 1:41pm UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/2 "2020-08-23T13:41:43Z")
Welcome Christopher! Could you please try re-running, but simply inserting a seemingly pointless space in between the opening double-quote and “`--slm`”? So it would be: ```auto dwifslpreproc sub-OAS30141_dwi_den.mif sub-OAS30141_dwi_den_preproc.mif -nocleanup -rpe_none -pe_dir j- -eddy_options " --slm=linear --data_is_shelled" ``` If my suspicion is correct, that will prevent the Python `argparse` module from erroneously discarding the first entry in the content specified via the “`-eddy_options`” command-line option, which will in turn prevent the `dwifslpreproc` script from going down [this code path](https://github.com/MRtrix3/mrtrix3/blob/3.0.1/bin/dwifslpreproc#L289-L305) unnecessarily. This glitch is unfortunately out of my control unless I completely [implement](https://github.com/MRtrix3/mrtrix3/issues/1608) a Python command-line interface for _MRtrix3_ from scratch… I would also express caution at using FSL `eddy` for pre-processing these data: while providing “`--data_is_shelled`” may get the command to execute, your data are in fact very clearly _not_ shelled, and I don’t know exactly what `eddy` will do in this circumstances, because the Gaussian Process it uses to generate predicted images for registration does not operate across _b_-values. Rob ---
**Author:** ![FL33TW00D](https://community.mrtrix.org/user_avatar/community.mrtrix.org/fl33tw00d/32/3371_2.png) [@FL33TW00D](https://community.mrtrix.org/u/FL33TW00D)\ **Post date:** [August 27, 2020, 9:30am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/3 "2020-08-27T09:30:10Z")
Hi @rsmith, Thanks for coming back to me. I did some digging myself and you’re absolutely right that the data is not shelled, and going down the EDDY route is not going to be suitable. Instead I have moved over to QSIPrep and will be using MRTrix for the reconstruction portion of the process. Many Thanks, Christopher Fleetwood ---
**Author:** ![Michael\_Wang](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/a8b319/32.png) [@Michael\_Wang](https://community.mrtrix.org/u/Michael_Wang)\ **Post date:** [November 13, 2020, 9:58am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/4 "2020-11-13T09:58:50Z")
Hello, I also met the similar question with you and I used the FSL to do the pre-processing but want to use the ‘tckgen’ to track. Also appeared ‘DWI volumes could not be classified into b-value shells; gradient encoding may not represent a HARDI sequence’, which kind of code should I use to track between the two ROIs’(ROI1 and ROI2) tckgen? I am appreciate that you can help me about that. ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [November 17, 2020, 1:09pm UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/5 "2020-11-17T13:09:37Z")
Hi Michael, You would need to be more specific about your issue for us to provide useful advice. If you have the same problem as the original poster, then your data inherently can’t be pre-processed using FSL (or at least, not using `eddy`). We’d need to know a lot more about your sequence and the specifics of the DW encoding scheme before we can comment on whether your sequence can be processed using MRtrix at all. If your DW encoding doesn’t use a shell structure, but something like a DSI acquisition, I think you can use QSIPrep (as suggested above) to do the preprocessing, and as I understand it, that can then be used to generate data suitable for use with `tckgen`. But I don’t know the specifics of how that might work… ---
**Author:** ![Michael\_Wang](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/a8b319/32.png) [@Michael\_Wang](https://community.mrtrix.org/u/Michael_Wang)\ **Post date:** [November 18, 2020, 9:30am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/6 "2020-11-18T09:30:43Z")
![dti](https://community.mrtrix.org/uploads/default/original/2X/d/d4c537ae783695c236162d1d7dd61f056d952fc4.jpeg) Hello,sorry for I didn’t make my question clear. And very thank you for your reply. I am using the same DTI dataset from the OASIS with the original poster said and with the same.bval file. I tried to use the FSL’s ‘eddy\_correct’ to do the pre-processing and it did work. ‘eddy’ I want to try this next step and thank you for telling me this will not work. As I used the code bellow in Mrtrix3 ( **whether this can get what I want: fiber cross the two mask ROIs and it’s count, length and mean value of FA/MD** ): - data.nii.gz: zip dwi image after eddy\_correct; - MD/FA.nii.gz: after I did the FSL’s dtifit get the two images 1. mrconvert data.nii.gz -fslgrad dtiraw.bvec dtiraw.bval data.mif 2. dwi2response tournier data.mif wm\_response.txt 3. dwi2fod data.mif wm\_response.txt fod.mif 4. tckgen fod.mif track\_roi.tck -include 1\_mask.nii 2\_mask.nii 5. tckstats track\_roi.tck 6. tcksample track\_roi1.tck FA.nii.gz FA\_roi1.txt -stat\_tck mean 7. tcksample track\_roi1.tck MD.nii.gz MD\_roi1.txt -stat\_tck mean ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [November 18, 2020, 11:56am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/7 "2020-11-18T11:56:12Z")
> [@Michael\_Wang](#): > > I tried to use the FSL’s ‘eddy\_correct’ to do the pre-processing and it did work. Yes, `eddy_correct` makes very minimal assumptions about the data, and should ‘work’ for any dataset – as long as the registration between the _b_=0 volume and each individual diffusion-weighted volume works correctly (not always the case), but it also ignores susceptibility-induced distortions (not necessarily a problem in your case, I expect these datasets don’t come with the reversed PE scans needed to perform the correction anyway), and doesn’t perform outlier rejection and correction. In my experience, `eddy_correct` often introduced more problems than were originally present… But: > [@Michael\_Wang](#): > > ‘eddy’ I want to try this next step and thank you for telling me this will not work. That is indeed the problem. But also: > [@Michael\_Wang](#): > > - dwi2response tournier data.mif wm\_response.txt > - dwi2fod data.mif wm\_response.txt fod.mif Both of these steps _also_ rely on the data being multi-shell, so won’t work with your data – at least not in their current form. We had a brief look at the acquisition details, and assuming the diffusion encoding is [as described on page 12 of this document](https://www.oasis-brains.org/files/OASIS-3_Imaging_Data_Dictionary_v1.8.pdf) (25 directions, none of which have the same _b_-value), I’m afraid there isn’t much you can do with it other than regular DTI… ---
**Author:** ![Michael\_Wang](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/a8b319/32.png) [@Michael\_Wang](https://community.mrtrix.org/u/Michael_Wang)\ **Post date:** [November 18, 2020, 3:35pm UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/8 "2020-11-18T15:35:00Z")
Very thank you for your kind and clear explanation. This really help me much. Thank you~ I will try other ways and conntinue learn more about Mrtrix 3. ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [November 22, 2020, 7:06am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/9 "2020-11-22T07:06:21Z")
Hi all, I should clarify an initial mistake on my part: > [@FL33TW00D](#): > > `dwifslpreproc sub-OAS30141_dwi_den.mif sub-OAS30141_dwi_den_preproc.mif -nocleanup -rpe_none -pe_dir j- -eddy_options "--slm=linear --data_is_shelled"` > `[ERROR] DWI volumes could not be classified into b-value shells; gradient encoding may not represent a HARDI sequence` > [@rsmith](#): > > Could you please try re-running, but simply inserting a seemingly pointless space in between the opening double-quote and “`--slm` ”? While providing the `--data-is-shelled` to `eddy` has the potential to convince `eddy` to proceed with processing even with data _it_ deems to not be arranged in shells, the originally reported error message was actually generated by an _MRtrix3_ command; presumably the internal `dwi2mask` call. So no amount of coercion of `eddy` would have actually gotten around this. Hopefully in `3.1.0` we will have [these changes](https://github.com/MRtrix3/mrtrix3/pull/2197) to DWI masking, which (following [appropriate configuration](https://github.com/MRtrix3/mrtrix3/pull/2197/files?short_path=b096219#diff-b0962190ae93ebb06d0024097228b437677ab8f967ec0e611ee0bb13524eeedc) on your part) will allow _MRtrix3_ scripts that may want to execute `dwi2mask` to still proceed, by selecting a masking algorithm that is compatible with non-shelled data. But nevertheless, the fact that both _MRtrix3_ and FSL would classify this as a non-shelled acquisition means that `eddy` is likely not the right choice anyway. ---
**Author:** ![Michael\_Wang](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/a8b319/32.png) [@Michael\_Wang](https://community.mrtrix.org/u/Michael_Wang)\ **Post date:** [November 24, 2020, 4:23am UTC](https://community.mrtrix.org/t/error-not-classified-into-shells/4006/10 "2020-11-24T04:23:54Z")
Thank you for your supplement.