Hi MRtrix experts,
I have a single shell 60 directions b-3000 interleaved data.
I am using mrtrix3tissue/5.2.8 and FSL/6.0.4. Trying to apply dwifslpreproc command with the following options; but I got an error.txt saying "could not open matrix file index.txt ".
Could you please help to fix it? My index.txt is 1x67 (67 volumes).
I also get the same error for opening “acqp.txt” !
Do you think, given that the “dwifslpreproc” internally extract both index and acqp files by default as below:
causes the problem? Is it really necessary that I pass those 2 text files as input for eddy_options or not?
When I remove those 2 inputs, it runs fine till it gives this error that :
“Cuda version was not successful and attempting OpenMP version”. Then here is the main error:
slice-to- vol is not yet implemented for CPU version !
BTW, I would appreciate if you have any comments on my set-up eddy_options:-)
dwifslpreproc test1_den_unringed.mif test1_prep.mif -pe_dir RL -rpe_pair -se_epi test1_b0_pair.mif [ -readout_time 0.028 ] -eddy_options " --acqp=acqparams.txt --index=index.txt --out=dwi_post_eddy --repol --mporder=16 --slspec=SliceOrder.txt --s2v_niter=10 --s2v_lambda=5 --s2v_interp=trilinear --verbose"
Thanks a lot for your time and support.
To use SS3T-CSD at the moment, I would advise to only use the MRtrix3Tissue fork for 3-tissue response function estimation and SS3T-CSD itself. For other steps like the preprocessing (e.g. dwifslpreproc), it’s best to install side-by-side with an MRtrix3 installation (of the latest version, i.e., 3.0.xx). I intend to document this a bit better in the near future, but haven’t found the time yet. If you’ve got any questions on running things in this way (i.e. side-by-side), feel free to be in touch.
Thanks for your quick response. I am not sure what I should do as a side-by-side installation. Here is my updated question:
I noticed that the “dwifslpreproc” command does not exist in mrtrix/3.0_rc3_latest nor mrtrix/3.0_rc3 versions. The latest version including that command is mrtrix/[3.0.2.]. Now, when I run the following command:
dwifslpreproc Sub001_den_unring.mif Sub001_prep.mif -pe_dir RL -rpe_pair -se_epi Sub001_b0_pair.mif -readout_time 0.028 -eddy_options " --acqp=acqparams.txt --index=index.txt --out=dwi_post_eddy --repol --mporder=16 --slspec=SliceOrder.txt --s2v_niter=10 --s2v_lambda=5 --s2v_interp=trilinear --verbose"
I got this error: Cannot provide eddy slice specification file via -eddy_options “–slspec=…” as manipulations are required; use -eddy_slspec option instead
Then I tried to fix it as the following:
dwifslpreproc test1_den_unring.mif test1_prep.mif -pe_dir RL -rpe_pair -se_epi test1_b0_pair.mif -readout_time 0.028 -eddy_slspec=SliceOrder.txt -eddy_options " --acqp=acqparams.txt --index=index.txt --out=dwi_post_eddy --repol --mporder=16 --s2v_niter=10 --s2v_lambda=5 --s2v_interp=trilinear --verbose"
Then got this error: Slice-to-vol is not yet implemented for the CPU version.
I am a bit confused, and would really appreciate it if you write an example command line that works for slice-to-volume correction.
Thanks a lot for your support:-)
Dear @Suzim ,
Is your CUDA environment set up to run eddy_cuda? Slice to volume correction is only possible with the CUDA version of eddy.
One easy way to check whether this is a dwifslpreproc error or an FSL/CUDA issue is to go to temporary directory created by dwifslpreproc and then call eddy directly with your preferred options.
Thanks for your reply. Ok so you confirm that slice-to-vol correction only is possible using Cuda. Now, I am loading FSL/6.0.3 and Cuda/8.0 . Based on your explanation, the -eddy_options " … " does NOT work and I must call eddy_cuda . But when I run the following command, it errors saying " unrecognised argument".
dwifslpreproc test2_den_unring.mif test2_prep_eddy.mif -pe_dir RL -rpe_pair -se_epi test2_b0_pair.mif -eddy_cuda8.0 --acqp=acqparams.txt --index=index.txt --out=test2_post_eddy --repol --mporder=16 --slspec=SliceOrder.txt --s2v_niter=10 --s2v_lambda=5 --s2v_interp=trilinear --verbose
Could you please correct the above command in a way that MRtrix would recognise ?
Should it be like -eddy_cuda " … " OR -eddy_cuda … OR eddy_cuda " …" OR …etc.
Unfortunately there is no updated documentation to clarify how apply eddy_cuda using dwifslpreproc.
I would really appreciate if you help to fix this issue:-)
Thanks for your support,
OK, there’s a few issues to untangle here. I’ll try to clarify:
The correct way to pass options to
eddy is using the
-eddy_options option, like you did originally.
There are exceptions to this, when options that would normally be passed to
eddy require some intervention from the
dwifslpreproc script to work as expected. The
–slspec option is one of these. The message you got there was instructing you to use
-eddy_slspec option instead of trying to pass that directly to
eddy. But that applies only to that
–slspec option from that list of options you’d provided – the rest of them should still be passed to
@NicDC is correct that slice to volume only works with
eddy_cuda. But that doesn’t (usually) need any special handling from the user:
dwifslpreproc will try quite hard to use
eddy_cuda (or any other version of it that it can find) and only fall back to
eddy_openmp when none of the cuda versions succeed – irrespective of whether slice to volume is to be used. If
eddy_cuda8.0) is in your PATH and correctly set up, then it should Just Work™…
Thanks @jdtournier ,
Yes, you shouldn’t need to specify eddy_cuda in the dwifslpreproc command. The only errors I can see here
are that there should be no “=” sign after -eddy_slspec, and that you should not specify the --out flag in the eddy_options.
However the error you mention here
suggests that dwifslpreproc was trying to call eddy_cuda and that failed, so it switched to eddy_openmp, which is unable to run slice-to-volume correction. Therefore I suggested checking whether your eddy_cuda8.0 command is working when called in the command line. To do this, you can just open a new terminal and type
and when you press ENTER, it should print out the help page to the terminal, if your CUDA environment is correctly set up. For this you would need an NVIDIA CUDA-enabled graphics card with the correct driver and CUDA library installed. If its a library issue, you will get some error like
error while loading shared libraries: libcudart.so.8.0: cannot open shared object file: No such file or directory
which means that you don’t have the cuda libraries required to run eddy_cuda. To get that sorted, I would recommend following these instructions to install cuda toolkit 9.1.85 and check if eddy executable runs now by typing:
If that works, then re-running your command
with the two edits mentioned earlier, should work.
Hope this helps,
Thank you both @jdtournier and @NicDC
Your comments were really helpful and I ran that command with your corrections and worked fine:-)
Now one last question:
when I pass --acqp=acqparams.txt and --index=index.txt within the -eddy_options, it cannot read the files with this error:
EddyInputError: Error when attempting to read --index file
Do you know what is the problem?
As I have noticed, dwifslpreproc internally execute both index and acqp files (not sure how). Do you think those two input parameters are necessary to pass and make a real difference on the output result of preprocessing or not?
I am much worried of the acqp file as I have calculated the Time factor based on my MRI-sequence. (my acqp is like [1 0 0 0.0585] as it has R>>L direction)
Thanks a lot for your time and help:-)
Normally dwifslpreproc will create the acqparams (eddy_config) and index (eddy_indices) files based on your input to the -pe_dir, -rpe_pair (or its alternatives) and -readout_time options. So there should be no need to add them in -eddy_options.
Presently it looks like you are passing a different total readout time in the -readout_time and in the -eddy_options --acqparams, and this would not be recommended, so perhaps check that you have the right one in the -readout_time input.
Sure, I do appreciate your help Nick.
It is really nice that MRtrix has such a friendly and supportive community.