we recently released a patch for the 5.09 eddy that has the --data_is_shelled flag (see below for original email). Unfortunately these are only the CentOS and Mac executables so far, but if you are on one of those systems it should hopefully work for you.
Dear All,
There are executables for CentOS 6 and for MacOsx10.9. In both cases there is a choice between an openmp version (named eddy_openmp) or a CUDA version (named eddy_cudax.x). The x.x refers to the version of the CUDA libraries that was used to build the
executable. The CUDA binaries are all “fat” and contains code for a range of compute capabilities, 1.0--3.5 for CUDA library up to 6.0 and 2.0--3.7 for CUDA libraries > 6.0.
Please also note that if you don’t find your CUDA version among the executables, there is nothing to stop you from having several versions of the CUDA libraries on your machine. So just download the version you need to run eddy, and that version will sit
happily next to whatever version you are currently running.
I have done some very preliminary tests running the CentOS 6 binaries on a CentOS 7 machine, and it seems to work. If anyone tries and have any problems, please let me know.
We strongly recommend using the CUDA version if at all possible.
The main new feature is the
--repol
switch. It means that slices with signal loss will be identified and replaced by “predictions”.
Other features that people will find useful are
--data_is_shelled
This switch will override the internal check to ensure that date are acquired on a set of b-value shells (as opposed to DSI). It has emerged that the internal check is a little too stringent for some popular (shelled) acquisitions. By specifying --data_is_shelled
you “promise” that is is actually shelled.
--field
Previous versions of eddy would only accept topup output as a susceptibility field. There were some very good reasons for that, so be warned if you decide to use the --field.
It allows you to use any old field as input to eddy, as long as it is specified in Hz. You can for example use a field that has been calculated from a dual echo-time fieldmap sequence and prepared with prelude (as long as you make sure it is in Hz, rather
than radians/s as fugue expects).
One good reasons for only allowing topup output was that you could get both PE polarity and total acquisition time wrong. As long as you got it wrong in the same way in both topup and eddy you would still be completely fine. If you use a dual echo-time
fieldmap you need to get all numbers exactly right, and it is not always easy since the different vendors export this information in different formats.
Another good reason is that as long as the first b0-volume in your topup data file is also the first volume in the data set you feed into eddy it is guaranteed that the field is in the reference space of eddy. If you use a dual echo-time fieldmap you will
need to register the field to the diffusion data yourself.
The --topup will of course work as before. Unless you have already acquired your dual echo fieldmaps, or have a penchant for making your life much more difficult than it needs be, I strongly recommend you stick with --topup.
I will attempt to get the eddy help pages up to date in the next couple of days.
You can find the binaries at
I hope all will work fine. Fingers crossed.
Jesper