Dwipreproc eddy_cuda --slspec Unable to open file MultiBandGroups

21

To clarify: In 3.0_RC3, rather than explicitly requiring the -cuda command-line option in order to use the CUDA version of eddy, dwipreproc instead looks for the CUDA version and will automatically run that version. If however the CUDA version fails, then dwipreproc will issue a warning, and automatically run the OpenMP version (if it is installed). Therefore, if you have placed the CUDA version of eddy somewhere in your PATH but never attempted to run it, then with the 3.0_RC3 update you will now get a warning that that version is failing. If however the OpenMP version runs without issue, then the outcome from dwipreproc will not be detrimentally affected. If you are put off by the warning, the CUDA eddy binary should simply be deleted, since it’s unable to run on your system regardless.

CUDA is very sensitive to version mismatches; not only between the CUDA version installed on the system and that used to compile the binary (which is why there are multiple versions of the CUDA version of eddy provided), but also the kernel and video driver versions.

If you believe that the CUDA version should be working on your system, then you will need to run it manually and check the error message that it produces.

I had the Unicode error on 3 of 10 subjects during dwipreproc.

I was hoping that Unicode conversion errors would have been removed with the 3.0_RC3 update. If you are indeed running this updated version and are still getting this error, please provide further details either here or on GitHub.

22

Thanks @rsmith - good to know OpenMP vs. Cuda doesn’t make a big difference. Dwipreproc finished fine on OpenMP :hugs:

23

@martahedl The AWS instance was running ubuntu 16.04. I have a Mac Pro workstation, but it doesn’t have an NVIDIA graphics card so no cuda locally for me.

@rsmith I just installed it on 5/17 so I assume it’s the latest version. This is the version output from mrconvert -version:

ubuntu:~$ mrconvert -version
== mrconvert 3.0_RC3-3-g17640ca9 ==
64 bit release version, built May 17 2018, using Eigen 3.2.92
Author(s): J-Donald Tournier (jdtournier@gmail.com) and Robert E. Smith (robert.smith@florey.edu.au)
Copyright © 2008-2018 the MRtrix3 contributors.

This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at http://mozilla.org/MPL/2.0/

MRtrix3 is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For more details, see http://www.mrtrix.org/

This is the error I received:

ubuntu:~$ dwipreproc data2.mif test.mif -rpe_none -pe_dir AP -export_grad_fsl bvec.txt bval.txt -info

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: Loading header for image file ‘/home/ubuntu/s10/data2.mif’
Traceback (most recent call last):
File “/home/ubuntu/mrtrix3/bin/dwipreproc”, line 74, in
image.check3DNonunity(path.fromUser(app.args.input, False))
File “/home/ubuntu/mrtrix3/lib/mrtrix3/image.py”, line 101, in check3DNonunity
image_in = Header(image_in)
File “/home/ubuntu/mrtrix3/lib/mrtrix3/image.py”, line 20, in init
data = json.load(f)
File “/usr/lib/python2.7/json/init.py”, line 291, in load
**kw)
File “/usr/lib/python2.7/json/init.py”, line 339, in loads
return _default_decoder.decode(s)
File “/usr/lib/python2.7/json/decoder.py”, line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File “/usr/lib/python2.7/json/decoder.py”, line 380, in raw_decode
obj, end = self.scan_once(s, idx)
UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0xa0 in position 51: invalid start byte

Identical command on same data worked fine on an older release of mrtrix I had on my local machine. Let me know if you want me to post to GITHUB…

24

good to know OpenMP vs. Cuda doesn’t make a big difference.

Well, apart from the execution time, the other big difference is that slice-to-volume correction isn’t implemented in the OpenMP version of eddy. But given that you upgraded your OS at the same time, I would think that your inability to run eddy_cuda would be far more likely a result of that upgrade than the changes to MRtrix3.

This is the error I received:

Oooh OK. It’s the same Unicode error message as reported previously, but originating from a very different location. While I can see why these data may not have been a problem with a previous version of MRtrix3, it’s nevertheless not actually MRtrix3’s fault; at least not entirely. The error is arising deep inside of Python library code. But I might be able to provide an upstream solution…

What would be useful for me here, would be if you could run:

mrconvert data2.mif data2.mih
mrinfo data2.mif -json_all data2.json

, and upload files data2.mih and data2.json to the new GitHub issue I’ve made for this report. There’s no need to provide file data2.dat generated by the mrconvert call: it’s only the header information that I’m interested in. It’s important to explicitly upload the files rather than copy&pasting the text, as the latter process could obscure the issue.

You could also try running dwipreproc under Python3 and see whether it better deals with the data you have.

25

Dear all,
From where I can download OpenMP for macOS?

in the current version (3.0_RC3) i get an error:
dwipreproc: [WARNING] CUDA version of eddy appears to have failed; trying OpenMP version

26

You should not need to download OpenMP; it’s a library that the binary is compiled against. Assuming that you are only seeing the warning you have copy&pasted here and not a subsequent error, then the OpenMP version is working; it’s the CUDA version that is present on your system, but not successfully executing (probably because you downloaded the CUDA version of eddy but have not adequately set up CUDA itself).

The direct eddy downloads are here. However in checking the Mac downloads, it appears that the standard version of eddy is in fact called eddy_cpu there, rather than eddy_openmp. I had not realised this earlier, and so dwipreproc will not automatically detect this file. If this is the file that you have downloaded onto your system, and dwipreproc is failing to complete, creating a softlink called eddy that points to eddy_cpu should work. Alternatively, installing FSL version 6 using their installation script now includes eddy as part of its installation.

(Anyone who has used this script to install on Mac: please let me know if the names of the eddy executables are different there also)