# Dwipreproc eddy\_cuda --slspec Unable to open file MultiBandGroups **URL:** \ **Category:** Uncategorized\ **Created:** [April 6, 2018, 6:45pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573 "2018-04-06T18:45:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 6, 2018, 6:45pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/1 "2018-04-06T18:45:09Z")
Dear MRtrix Experts, I have recently got a CUDA install up an running on our Linux Ubuntu 16.04 system. When running the following code: > dwipreproc {i}\_in.mif.gz {i}\_out.mif.gz -rpe\_none -pe\_dir PA -readout\_time 0.0441 -eddy -cuda " --repol --mporder=18 --s2v\_niter=10 --s2v\_interp=trilinear --s2v\_lambda=5 --slspec=json\_slspec.txt " I get the following error > dwipreproc: [ERROR] Command failed: eddy\_cuda --imain=dwi.nii --mask=mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals --repol --mporder=18 --s2v\_niter=10 --s2v\_interp=trilinear --s2v\_lambda=5 --slspec=json\_slspec.txt --out=dwi\_post\_eddy (dwipreproc:518) > dwipreproc: Output of failed command: > eddy: msg=MultiBandGroups::MultiBandGroups: Unable to open file > terminate called after throwing an instance of ‘EDDY::EddyException’ > what(): eddy: msg=MultiBandGroups::MultiBandGroups: Unable to open file when I remove the --slspec=\<.txt\> flag, eddy\_cuda runs without this error. Our data is from a Siemens 3T Trio, 36 volumes, Single Band, 72 interleaved slices. (Older sequence to preserve longitudinal acquisitions) I suspect providing the interleaved slice acquisition order is important for slice to volume motion correction. Therefore, I am uneasy about moving forward without providing this information. Apologies, if this is an FSL specific issue, which I strongly suspect… Any help would be very appreciated! Thank you all for your work! Best, Derek ---
**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:** [April 10, 2018, 3:24am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/2 "2018-04-10T03:24:21Z")
Hi Derek, Most likely, the script is failing because you have provided a path to the “slspec” file that is _relative_ to your current working directory, but then when `eddy` is actually invoked within `dwipreproc` the working directory is the temporary directory created by the script. Providing an _absolute_ path to the slspec file _may_ work. I honestly don’t know what `eddy` will do if the `--mporder` option is specified but no slspec file is provided; personally I’d have expected it to not proceed. The coming _MRtrix3_ update includes [changes to `dwipreproc`](https://github.com/MRtrix3/mrtrix3/pull/1175) and associated [documentation](https://github.com/MRtrix3/mrtrix3/pull/1245) for dealing with slice-to-volume correction. Once this change is pushed, the `dwipreproc` script will detect your use of “`-eddy_options "--slspec="`”, and copy that text file into the temporary directory where `eddy` will see it. Or more conveniently, _MRtrix3_ will capture slice timing information from DICOM and store it in the image header, and _automatically_ generate the slspec file for `eddy` without requiring user intervention. 👍 Rob ---
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 10, 2018, 9:59pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/3 "2018-04-10T21:59:49Z")
Hi Rob, This seems like a very sensible explanation! Thank you. I was also surprised that eddy ran with --mporder but no slspec.txt file. I have tried running dwipreproc and specifying the full directory to the slspec.txt however I either get the following error if I include a “/” at the start of the path > Command: eddy\_cuda --imain=dwi.nii --mask=mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals --repol --mporder=18 --s2v\_niter=10 --s2v\_interp=trilinear --s2v\_lambda=5 **–slspec=/data/users/DSA/EDDYTEST/my\_slspec.txt** --out=dwi\_post\_eddy > Traceback (most recent call last): > File “/data/bin/mrtrix3/bin/dwipreproc”, line 518, in > run.command(eddy\_cmd + ’ --imain=dwi.nii --mask=mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals’ + eddy\_in\_topup\_option + eddy\_manual\_options + ’ --out=dwi\_post\_eddy’) > File “/data/bin/mrtrix3/lib/mrtrix3/run.py”, line 175, in command > stdout\_text = tempfiles[index][0].read().decode(‘utf-8’) > File “/usr/lib/python2.7/encodings/utf\_8.py”, line 16, in decode > return codecs.utf\_8\_decode(input, errors, True) > UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0xa0 in position 0: invalid start byte or the same ‘msg=MultiBandGroups: Unable to open file error’ as before if not including the “/” i.e. –slspec=data/users/DSA/EDDYTEST/my\_slspec.txt Thus, it does not look like I will be able to provide the full path to my slspec.txt file within dwipreproc. I’m looking forward to the updates you detailed! How imminent are these going to being available? In the meantime do you see a workaround? Is it possible to copy slspec.txt into the dwipreproc temporary directory and ‘restart’ dwipreproc from there? Thank you again! Derek ---
**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:** [April 12, 2018, 1:48am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/4 "2018-04-12T01:48:15Z")
> `UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0xa0 in position 0: invalid start byte` Okay, that looks like a similar issue to [Hamed’s recent post](http://community.mrtrix.org/t/dwipreproc-command-error/1574) and the corresponding [GitHub issue](https://github.com/MRtrix3/mrtrix3/issues/953). The _MRtrix3_ Python library is falling over when trying to read the text written to the terminal by `eddy`; what I don’t know is whether or not the data it is failing to decode is healthy feedback or an error message. I’ll see if I can reproduce it. > How imminent are these going to being available? I’ve been pushing hard on this; was aiming for the end of the week but there’s likely to be ongoing discussion about [this particular issue](https://github.com/MRtrix3/mrtrix3/pull/1228#issuecomment-380636442). You can see the outstanding issues via the relevant [milestone](https://github.com/MRtrix3/mrtrix3/milestone/4) and [pull request](https://github.com/MRtrix3/mrtrix3/pull/1232) on GitHub. > In the meantime do you see a workaround? Is it possible to copy `slspec.txt` into the `dwipreproc` temporary directory and ‘restart’ `dwipreproc` from there? That should be possible. All of the scripts that use the _MRtrix3_ Python scripts have the `-continue` option; it’s quite clunky and doesn’t work in all scenarios, but in this case it should be able to serve that purpose. Alternatively, if you’re not averse to some version control shenanigans, the development branch that includes the updates to `dwipreproc` described earlier is publicly accessible, so you’re welcome to give it a try (bearing in mind that checking out that branch will come with a large batch of other changes throughout the entire software). Rob ---
**Author:** ![Hamed](https://community.mrtrix.org/user_avatar/community.mrtrix.org/hamed/32/2871_2.png) [@Hamed](https://community.mrtrix.org/u/Hamed)\ **Post date:** [April 12, 2018, 12:50pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/5 "2018-04-12T12:50:47Z")
Hi Rob > [@rsmith](#): > > Or more conveniently, MRtrix3 will capture slice timing information from DICOM and store it in the image header, and automatically generate the slspec file for eddy without requiring user intervention. This would be awesome. But do you think this would be an option for Philips DICOMs as well? I guess they don’t include this information. Do they? Cheers, Hamed ---
**Author:** ![Hamed](https://community.mrtrix.org/user_avatar/community.mrtrix.org/hamed/32/2871_2.png) [@Hamed](https://community.mrtrix.org/u/Hamed)\ **Post date:** [April 12, 2018, 1:41pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/6 "2018-04-12T13:41:24Z")
Hi Derek, > [@DAndrews](#): > > I have recently got a CUDA install up an running on our Linux Ubuntu 16.04 system. I have similar Linux Ubuntu 16.04 system. > $ uname -m && cat /etc/\*release > x86\_64 > DISTRIB\_ID=Ubuntu > DISTRIB\_RELEASE=16.04 > DISTRIB\_CODENAME=xenial > DISTRIB\_DESCRIPTION=“Ubuntu 16.04.4 LTS” > NAME=“Ubuntu” > VERSION=“16.04.4 LTS (Xenial Xerus)” > ID=ubuntu > ID\_LIKE=debian > PRETTY\_NAME=“Ubuntu 16.04.4 LTS” > VERSION\_ID=“16.04” > HOME\_URL=“[http://www.ubuntu.com/](http://www.ubuntu.com/)” > SUPPORT\_URL=“[http://help.ubuntu.com/](http://help.ubuntu.com/)” > BUG\_REPORT\_URL=“[Bugs : Ubuntu](http://bugs.launchpad.net/ubuntu/)” > VERSION\_CODENAME=xenial > UBUNTU\_CODENAME=xenial with nvidia: > $ nvidia-smi > Thu Apr 12 15:13:02 2018 > ±----------------------------------------------------------------------------+ > | NVIDIA-SMI 390.30 Driver Version: 390.30 | > |-------------------------------±---------------------±---------------------+ > | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | > | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | > |===============================+======================+======================| > | 0 Quadro M4000 Off | 00000000:03:00.0 On | N/A | > | 46% 36C P8 13W / 120W | 416MiB / 8118MiB | 0% Default | > ±------------------------------±---------------------±---------------------+ ±----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 1255 G /usr/lib/xorg/Xorg 297MiB | | 0 2682 G compiz 109MiB | | 0 8425 G unity-control-center 3MiB | ±----------------------------------------------------------------------------+ and > $ nvcc --version > nvcc: NVIDIA (R) Cuda compiler driver > Copyright (c) 2005-2015 NVIDIA Corporation > Built on Tue\_Aug\_11\_14:27:32\_CDT\_2015 > Cuda compilation tools, release 7.5, V7.5.17 But so far unable to use eddy cuda. Could you please explain more about how you made eddy cuda work. Thanks and cheers, Hamed ---
**Author:** ![Hamed](https://community.mrtrix.org/user_avatar/community.mrtrix.org/hamed/32/2871_2.png) [@Hamed](https://community.mrtrix.org/u/Hamed)\ **Post date:** [April 12, 2018, 2:51pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/7 "2018-04-12T14:51:04Z")
Hi Derek Never mind my question. Apparently, eddy\_cuda binary is included in fsl 5.0.11 and I didn’t know that I had to call -cuda explicitly in the dwipreproc command (I thought it will find it automatically!). 🤨 So I did that and my 102d multishell topup+eddy\_openmp (8+35 minutes) runtime reduced to (8+15 minutes)! Nice! 🙂 Cheers, Hamed ---
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 12, 2018, 6:36pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/8 "2018-04-12T18:36:15Z")
Hi Rob, Your sensible explanations are once again helping keep me sane! I have tried using the _-continue_ option as you suggested. This appears to get around the _msg=MultiBandGroups: Unable to open file error_ but still returns _UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0x9e in position 1: invalid start byte_ Therefore, I think adding the full path to the slspec.txt file for the --slspec flag might have worked, however the file “my\_slspec.txt” or “myslspec.txt” is failing to be read regardless. From reviewing [Hamed’s recent post](https://community.mrtrix.org/t/dwipreproc-command-error/1574) and the corresponding [GitHub issue](https://github.com/MRtrix3/mrtrix3/issues/953) a solution did not jump out at me. Did I miss something? It seems like the update for this should hopefully be available soon (days not weeks) 🤞😄 so I’m thinking my best option may be to wait it out. Although, this may not solve the unicode issue… ---
**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:** [April 13, 2018, 2:19am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/9 "2018-04-13T02:19:04Z")
> But do you think this would be an option for Philips DICOMs as well? I guess they don’t include this information. Do they? Correct. From the data I have at hand, Philips never include this information. Conversely, GE provide the acquisition time of each slice as being identical to the time of the commencement of the acquisition. In both cases _MRtrix3_ will detect that there is no timing _contrast_ between slices, and hence not write any slice timing information to the image header. Perhaps I need to be more conservative by reporting that this capability applies for Siemens data only… I’d also encourage Philips and GE users to put pressure on their vendors to push software updates to enable this. I’m surprised the fMRI community haven’t already done that, given the availability of software for slice timing correction. > … I didn’t know that I had to call `-cuda` explicitly in the `dwipreproc` command (I thought it will find it automatically!) Yes, currently it explicitly requires setting the `-cuda` option. At the time that script was first implemented I expected very few users to have gone to the effort of getting CUDA working, but many may have downloaded both binaries, and hence attempting to execute the CUDA version would lead to failures. In the `3.0_RC3` update, detection of the CUDA `eddy` binary is more robust (searches for the highest CUDA version available, so you don’t have to explicitly construct an “`eddy_cuda`” softlink). I also now have mechanisms for catching failed command executions and allowing the script to continue. So I wouldn’t be against modifying `dwipreproc` to use the CUDA version by default if it can be found, if that would lead to less user issues / confusion. Thoughts? > This … still returns `UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0x9e in position 1: invalid start byte` I’m trying to duplicate your use case as a way for me to simultaneously investigate the UTF-8 encoding issue. The only insight I’ve had so far has been in certain circumstances where the CUDA version of `eddy` generates a segmentation fault: the command outputs text relating to the memory areas implicated, but somewhere in that text is raw binary data that results in invalid codes if interpreted as UTF-8. Unfortunately this is not reproducible, which is always the first step in diagnosing and fixing faults. > … I’m thinking my best option may be to wait it out. Although, this may not solve the unicode issue… Given this has cropped up a number of times now, the _MRtrix3_ update won’t be pushed out without some solution to the Unicode issue. Worst case scenario, terminal text output by some commands may not appear precisely as intended; but that’s a helluva lot better than users getting unhandled Python exception messages. Just trying to generate good reproducible use cases so that I can figure out the best solution. And make sure the solution works on all 3 OS’s, both versions of Python on each, and with and without the `-debug` option for each 🤯 ---
**Author:** ![Hamed](https://community.mrtrix.org/user_avatar/community.mrtrix.org/hamed/32/2871_2.png) [@Hamed](https://community.mrtrix.org/u/Hamed)\ **Post date:** [April 13, 2018, 3:16pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/10 "2018-04-13T15:16:28Z")
Hi Derek > [@DAndrews](#): > > From reviewing Hamed’s recent post and the corresponding GitHub issue a solution did not jump out at me. Did I miss something? I explain what happens to a couple of my subjects. It may or may not solve your issue but could be helpful for others with the same error. In the dwipreproc temporary directory, there is a log file. In one of the lines in the middle, there is this command (in my case): > dwiextract dwi.mif -pe 0,1,0,0.0173 - | mrconvert - dwi\_pe\_1.nii **-json\_export dwi\_pe\_1.json** which creates a .json file. If I open this file (for some of my subjects), I see that there is “È” (E with a grave accent) or something like that in the subject’s name (coming originally from DICOMs/scanner) which in later steps causes ‘utf8’ problem when the .json file is used by: > mrconvert dwi\_pe\_1\_topup.nii.gz dwi\_pe\_1\_topup.mif **-json\_import dwi\_pe\_1.json** Traceback (most recent call last): File “/home/…/mrtrix3/bin/dwipreproc”, line 488, in run.command('mrconvert ’ + temp\_path + ’ ’ + output\_path + ’ -json\_import ’ + json\_path) File “/home/…/mrtrix3/lib/mrtrix3/run.py”, line 183, in command stderr\_text = tempfiles[index][1].read().decode(‘utf-8’) File “/usr/lib/python2.7/encodings/utf\_8.py”, line 16, in decode return codecs.utf\_8\_decode(input, errors, True) UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0xc9 in position 228: invalid continuation byte dwipreproc: So what I do is to replace this letter with normal ‘E’ ( **without** accent grave) in the .json file, save the file and continue the dwipreproc as where it crashed. Cheers, Hamed ---
**Author:** ![Hamed](https://community.mrtrix.org/user_avatar/community.mrtrix.org/hamed/32/2871_2.png) [@Hamed](https://community.mrtrix.org/u/Hamed)\ **Post date:** [April 13, 2018, 3:34pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/11 "2018-04-13T15:34:50Z")
> [@rsmith](#): > > Correct. From the data I have at hand, Philips never include this information. Check this out please: [http://dbic.dartmouth.edu/wiki/index.php/Slice\_Acquisition\_Order](http://dbic.dartmouth.edu/wiki/index.php/Slice_Acquisition_Order) Using above and knowing the ‘acquisition’ type from the DICOMs’ header (luckily they have included this 🙂 ), I guess it would be possible to address this issue.? Cheers, Hamed ---
**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:** [April 14, 2018, 12:06pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/12 "2018-04-14T12:06:22Z")
> I explain what happens to a couple of my subjects. It may or may not solve your issue but could be helpful for others with the same error. While the _reported_ error is the same, the underlying _issue_ that is leading to the error differs quite significantly between your two cases (more info on [GitHub](https://github.com/MRtrix3/mrtrix3/pull/1296#issuecomment-381103710)). @DAndrews: The way I was able to “reproduce” your issue was by providing an invalid `slspec` file, which leads to a CUDA segmentation fault; that segmentation fault then (sometimes) contains non-text data that causes the script library to have a hiccup. So in the absence of you actually seeing that error, I would suggest checking over your `slpec` file _extremely_ closely; `eddy` does not appear to currently perform a sanity check on it, so if e.g. a slice is missing from the list, that will lead to your currently-rather-useless error feedback. > Check this out please: I’ll have a look into that. I’m aware of the slice acquisition order fields in NIfTI, but I’d need to figure out how `dcmstack` is extracting that information from DICOM. ---
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 16, 2018, 8:56pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/13 "2018-04-16T20:56:16Z")
Ok, I went back and looked at my slspec.txt file. I had made a poor assumption that our slice acquisition started with slice “1”, when it actually starts with slice “0”. After adjusting the slspec file, and taking the steps to copy the slspec file into the temp folder and use -continue dwipreproc and eddy\_cuda run with no errors. My test results look great! Thank you again Rob for all your help! Best, Derek ---
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 18, 2018, 9:58pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/14 "2018-04-18T21:58:34Z")
Hi Rob, Unfortunately, my celebration _may_ have been a bit premature. While eddy\_cuda appears to run and move on to the following mrconvert steps, then I get a general eddy\_cuda failed error… > Command: eddy\_cuda --imain=dwi.nii --mask=mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals --repol --mporder=18 --s2v\_niter=10 --s2v\_interp=trilinear --s2v\_lambda=5 --slspec=json\_slspec.txt --out=dwi\_post\_eddy > Command: mrconvert dwi\_post\_eddy.nii.gz result.mif -stride -1,2,3,4 -fslgrad dwi\_post\_eddy.eddy\_rotated\_bvecs bvals > Command: mrconvert result.mif /data/proj/app/pipeline/DWI\_TH/100604-200\_3/100604-200\_3\_posteddy.mif.gz > dwipreproc: Changing back to original directory (/data/proj/app/pipeline/DWI\_TH/100604-200\_3) > dwipreproc: Script failed while executing the command: eddy\_cuda --imain=dwi.nii --mask=mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals --repol --mporder=18 --s2v\_niter=10 --s2v\_interp=trilinear --s2v\_lambda=5 --slspec=json\_slspec.txt --out=dwi\_post\_eddy > dwipreproc: For debugging, inspect contents of temporary directory: /data/proj/app/pipeline/DWI\_TH/100604-200\_3/dwipreproc-tmp-7ZN2XE the output file is produced and looks good. The error.txt file in the tmp directory gives the same old ‘msg=MultiBandGroups: Unable to open file error’ which I’m assuming is a hold over from the first run of dwipreproc that creates the tmp directory, which I then use -continue to flag. I’m also thinking this error.txt could be the reason for this error warning, when in fact all is well? I am using the -nocleanup flag… ---
**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:** [April 19, 2018, 3:47am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/15 "2018-04-19T03:47:47Z")
> The `error.txt` file in the tmp directory gives the same old `msg=MultiBandGroups: Unable to open file error` which I’m assuming is a hold over from the first run of `dwipreproc` that creates the tmp directory, which I then use `-continue` to flag. I’m also thinking this `error.txt` could be the reason for this error warning, when in fact all is well? I am using the `-nocleanup` flag… Correct; all is indeed well. I only recently discovered this issue myself. It’s already [fixed](https://github.com/MRtrix3/mrtrix3/commit/ba85d75ef88f8b42e180292aba0e29be4b198fc1) for the coming update. ---
**Author:** ![DAndrews](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@DAndrews](https://community.mrtrix.org/u/DAndrews)\ **Post date:** [April 19, 2018, 4:43pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/16 "2018-04-19T16:43:47Z")
> Correct; all is indeed well. Great news! I figured that was the issue. Best wishes with the rollout of the new update. Your guidance is very very appreciated! ---
**Author:** ![martahedl](https://community.mrtrix.org/user_avatar/community.mrtrix.org/martahedl/32/3799_2.png) [@martahedl](https://community.mrtrix.org/u/martahedl)\ **Post date:** [May 18, 2018, 5:09pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/17 "2018-05-18T17:09:34Z")
Hi, joining the ranks of problems occuring in dwipreproc associated with eddy\_cuda. Since I’ve updated the latest MRtrix release candidate AND my macOS to High Sierra 10.13.4 (in one go) a couple of days ago, an error has kept occuring when running dwipreproc (the exact command was dwipreproc dwi\_denoised.mif dwi\_den\_preproc.mif -rpe\_pair -se\_epi b0s.mif -pe\_dir AP -eddy\_options " --data\_is\_shelled --slm=linear ; and was run on unanonymized data), telling me that eddy\_cuda\_6.5 could not be carried out since I did not have the necessary permissions. I then reinstalled my FSL. Now I get the following message running the same command: [WARNING] Command failed: eddy\_cuda --imain=eddy\_in.nii --mask=eddy\_mask.nii --acqp=eddy\_config.txt --index=eddy\_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --data\_is\_shelled --slm=linear --out=dwi\_post\_eddy dwipreproc: [WARNING] CUDA version of eddy appears to have failed; trying OpenMP version I also went back to a dataset I had preprocessed before the updates (without any warnings), using the exact same command as above. Now I’m getting the same warning there. Does anyone have any idea what the issue might be? Do you think that’s a problem of the MRtrix update or the OSX? Best, Marlene. ---
**Author:** ![maxpietsch](https://community.mrtrix.org/user_avatar/community.mrtrix.org/maxpietsch/32/25_2.png) [@maxpietsch](https://community.mrtrix.org/u/maxpietsch)\ **Post date:** [May 18, 2018, 6:16pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/18 "2018-05-18T18:16:35Z")
This sounds like an incompatibility problem between eddy and your OS and cuda similar to [here](https://community.mrtrix.org/t/eddy-cuda-on-osx-versions-10-9/627). Does `eddy_cuda` work on any data? You might need to update [cuda](https://www.nvidia.com/object/macosx-cuda-387.178-driver.html). ---
**Author:** ![sniogi](https://community.mrtrix.org/user_avatar/community.mrtrix.org/sniogi/32/3493_2.png) [@sniogi](https://community.mrtrix.org/u/sniogi)\ **Post date:** [May 19, 2018, 1:53am UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/19 "2018-05-19T01:53:30Z")
I had the same eddy\_cuda error running dwipreproc on Amazon web services a couple days ago. I got around it by reinstalling cuda 7.5 toolkit and older nvidia-367 drivers which supported the GPU on the aws instance. Worked “almost” like a charm after that… I had the Unicode error on 3 of 10 subjects during dwipreproc. It was a problem when mrtrix was reading the header. I had an older version of mrtrix still running on host machine (without cuda). So I ran dwipreproc and terminated it after it started the non-cuda Eddy. I just rsnyc’d the temp directory that dwipreproc created to AWS and manually executed the remaining dwipreproc commands (eddy\_cuda, some mrconvert commands, and copying data from tmp directory back to original data folder). Annoying, but worked. I’ll have to see if the -continue switch works for me. That seems like an easier work around than what I did. ---
**Author:** ![martahedl](https://community.mrtrix.org/user_avatar/community.mrtrix.org/martahedl/32/3799_2.png) [@martahedl](https://community.mrtrix.org/u/martahedl)\ **Post date:** [May 20, 2018, 8:14pm UTC](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573/20 "2018-05-20T20:14:21Z")
@maxpietsch I updated cuda, but the problem remains. Unfortunately, eddy\_cuda doesn’t seem to work on any of my data any more. @sniogi Which operating system are you running? The cuda 7.5 toolkit is not available for OSX 20.13.4, which I am now using. Neither are any of the nvidia-367 drivers I found. Do you have other suggestions? [Next page](https://community.mrtrix.org/t/dwipreproc-eddy-cuda-slspec-unable-to-open-file-multibandgroups/1573.md?page=2)