dwifslpreproc error for multishell dwi image

Dear MRtrix3 experts,

I met a problem when I doing dwifslpreproc for multishell (5 shells) dwi images.

The command I used:

dwifslpreproc dwi_den.mif dwi_den_preproc.mif -nocleanup -pe_dir AP -rpe_pair -se_epi b0_pair.mif -eddy_options " --slm=linear --data_is_shelled" 

I pasted the error contents after topup completed:


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_cuda10.2 --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --slm=linear --data_is_shelled --out=dwi_post_eddy --verbose
***dwifslpreproc: CUDA version of 'eddy' was not successful; attempting OpenMP version***
Command:  eddy_openmp --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --slm=linear --data_is_shelled --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 --topup=field --slm=linear --data_is_shelled --out=dwi_post_eddy --verbose (app.py:196)
dwifslpreproc: [ERROR] Information from failed command:
dwifslpreproc:
               =============
               eddy_cuda10.2
               =============
               
               
               ===========
               eddy_openmp
               ===========
               Reading images
               EDDY:::  EddyUtils::get_groups: Inconsistent b-values detected
               EDDY:::  EddyUtils.cpp:::  static bool EDDY::EddyUtils::get_groups(const std::vector<EDDY::DiffPara>&, std::vector<std::vector<unsigned int> >&, std::vector<unsigned int>&, std::vector<double>&):  Exception thrown
               EDDY:::  EddyUtils.cpp:::  static bool EDDY::EddyUtils::GetGroups(const std::vector<EDDY::DiffPara>&, std::vector<std::vector<unsigned int> >&, std::vector<double>&):  Exception thrown
               EDDY:::  ECScanClasses.cpp:::  std::vector<std::vector<unsigned int> > EDDY::ECScanManager::GetShellIndicies(std::vector<double>&) const:  Exception thrown
               EDDY::: Eddy failed with message EDDY:::  ECScanClasses.cpp:::  EDDY::ECScanManager::ECScanManager(const string&, const string&, const string&, const string&, const string&, const string&, const string&, const string&, EDDY::ECModel, EDDY::ECModel, const std::vector<unsigned int>&, const EDDY::PolationPara&, EDDY::MultiBandGroups, bool):  Exception thrown
               
               
               =============
               eddy_cuda10.2
               =============
               eddy_cuda10.2: error while loading shared libraries: libcublas.so.10: cannot open shared object file: No such file or directory
               
               
               ===========
               eddy_openmp
               ===========
               
               
dwifslpreproc:
dwifslpreproc: [ERROR] For debugging, inspect contents of scratch directory: /home/..../dwifslpreproc-tmp-KITOSL/
dwifslpreproc: Scratch directory retained; location: /........

However it is so strange that few subj’s image can work well with dwifslpreproc and without this error even though they are aquired by the same scanner with same parameters.

Does anyone has any idea or suggestion? Thank you!

Best,
Sia

Hi Sia,

There are two issues here. The first is on this line:

eddy_cuda10.2: error while loading shared libraries: libcublas.so.10: cannot open shared object file: No such file or directory

This suggests that you either don’t have CUDA version 10 installed on your system, or it’s not available or otherwise misconfigured. This means you won’t be able to use the GPU-accelerated version of EDDY (and also won’t be able to do slice-to-volume correction). If you have access to a NVIDIA GPU and you were expecting to be using the CUDA version, then I suggest you search for the keyword ‘CUDA’ on this forum – you’ll find this is a common problem, but the solution will vary depending on the specifics of your system.


The second issue occurs when the script falls back to the OpenMP (CPU) version of EDDY, and fails with the message:

Inconsistent b-values detected

If these data were acquired with the same protocol as other subjects that have been successfully processed with the same command, then this is indeed unexpected – but it can happen. If you can post the full output of:

mrinfo dwi_den.mif -shell_sizes -shell_bvalues -dwgrad

This might give us a better idea of what the problem might be.

All the best,
Donald.

Dear kdtournier,

Thanks you so much for your reply.

For the first error, I have cuda11.5 located in /usr/local/cuda, do I have to keep the cuda version the same as 10.2 so that I can use the eddy cuda command?

For the second, I have copied the b-value following this command into the tmp file, still report the same error. I really have no idea and finally copied the b-value in tmp file from subj without error, :joy: :sweat_smile: and run eddy_openup and the other commands of dwifslpreproc one by one, it worked.
This is really weird but anyway it goes well without error.

Yes, the version of the CUDA library needs to match the version that the eddy_cuda executable expects. You can have both versions installed alongside each other if needed.

:exploding_head: I have no idea what you’ve just done…

Any chance you could explain this in more detail, including the filenames involved and their contents, so we can try to figure out what might have gone wrong in the first place? If there’s an issue in the script, it’s worth fixing before others also encounter problems…

If you can post the full output of:

For the second, I have copied the b-value following this command into the tmp file, still report the same error.

@Sia: What @jdtournier was asking for was to post the output of that mrinfo command here on the forum, not to attempt to inject those data into the script (if eddy claims that there’s an issue with the gradient table, extracting that gradient table and putting it in the scratch directory can’t possibly fix the problem).