Print

Print
Dear Ben,

for single-band data the number of excitations is simply the number of slices. For multi-band (also known as Simultaneous Multi Slice (SMS)) data, it is the number of slices divided by the multi-band factor.

I tend to mostly use --mporder=16 for single-band data and --mporder=8 for multi-band data.

Jesper


On 21 Sep 2017, at 17:11, Chernoff, Ben <[log in to unmask]> wrote:

Hi Jesper,

Thank you very much for posting these. I am looking at the documentation to determine the appropriate parameters to feed eddy in order to carry out slice to volume motion correction, and I see that you recommend between N/4 and N/2 for --mporder, where N is the number of excitations per volume. I am wondering how to calculate that number N. I have a PDF which contains all the information about the parameters of the sequence used for my data, but I’m not sure which values I need to use to calculate the number of excitations. Perhaps I am overthinking it and it’s obvious/intuitive, in which case I apologize.

Thank you very much!

-Ben Chernoff

Ben Chernoff
Ph.D. Student, Concepts, Actions, and Objects Lab
Rochester Center for Brain Imaging, Room 2B231
University of Rochester

On Sep 21, 2017, at 9:20 AM, Jesper Andersson <[log in to unmask]> wrote:

Dear All,

we have released binaries for eddy for version 5.0.11 of FSL. The official 5.0.11 FSL release is still some little time away, which is why we have decided on this pre-release. The eddy that will be distributed with the official 5.0.11 release will be identical to this release. Unless, fingers crossed, severe bugs are reported in this pre-release.

There are binaries for CentOS have been built on a CentOS 6.7 machine and should run on CentOS 6 and probably (though I haven’t been able to test that) 7. 

The binary eddy_openmp will run on CPU only. It will use more than one CPU/core when available and the maximum number of cores it will use is determined by the environment variable OMP_NUM_THREADS. If OMP_NUM_THREADS is not set it will use all available cores. If running it like that I strongly recommend nicing it.

There are a number of binaries eddy_cuda6.5, eddy_cuda7.0, eddy_cuda7,5 and eddy_cuda8.0 that all need an NVidia GPU to run. They are all maximally “fat”, i.e. the 6.5 version has been built for all compute capabilities supported by CUDA 6.5, the 7.0 version has been built for all compute capabilities supported by CUDA 7.0 etc. Chose the binary that corresponds to your CUDA installation. Note that there is nothing to stop you from having multiple CUDA installations, in which case I would recommend using the latest of those installed.


For macOS it has been built on a 10.12.2 (Sierra) machine.

For MacOS there are three versions. 

eddy_cpu: Is a single CPU version.
eddy_cuda7.5 and eddy_cuda8.0: Are CUDA versions for 7.5 and 8.0 respectively.

I hope to be able to build an openmp version as well and add that to the patch, but that will not happen for a couple of days.

The main new feature of the new version is the slice-to-volume (or intra-volume) subject movement model described in Andersson et al. (doi:10.1016/j.neuroimage.2017.02.085). We hope that this will be found to be useful for data acquired on subjects that make sudden movements (babies, children, patients with dementia etc). The details of it are described on the eddy wiki-page. This feature is very computationally intense, and hence is only available for the GPU versions. For those who want to use that feature but don’t have access to a GPU I understand that there are computational resources available from commercial companies for a fee.

The second new feature is an improved registration of the diffusion weighted images to the b0 images. These changes are also described at the wiki-page.

The wiki-pages have mostly been updated to reflect the new version, but there might be that odd little mistake still.

You can find the binaries at


I hope all will work fine. Fingers crossed.

Jesper