Could you please let me know whether or not the following is correct:

How much subject moved ~  (*.eddy_movement_rms) - (*.eddy_restricted_movement_rms)

no, those are two alternative “views” on how much the subject moved. 

A problem with assessing how much a subject actually moved from registering diffusion data is that there is an almost total co-linearity between an non-zero mean of an EC induced gradient and an actual subject movement in the PE direction (typically y). From a perspective of correcting the data it doesn’t matter if we assign it to EC or movement, the end result corrected images are identical. 

But from the perspective of telling “how much” a subject moved (presumably for QC reasons) it can make a difference. That means that if we include translations in the PE direction in the estimate (as in .eddy_movement_rms) we likely overestimate movement. If instead we exclude translations in the PE direction (as in .eddy_restricted_movement_rms) we likely underestimate it. But there is really no way we can know the full “truth”.

My recommendation is to use .eddy_restricted_movement_rms and accept that it is likely to be a slight underestimation, but one that will still give you the info you need in terms of relative amount of movement across subjects.

Jesper

Thank you!

Mahmoud

On Mon, Aug 29, 2016 at 9:44 AM, Jesper Andersson <[log in to unmask]> wrote:

Dear Mahmoud,

Regarding the eddy_openmp:

1- I am assuming that the translation and rotation values in *.eddy_parameters are in mm and radian, right?

yes.

2- Are the above motion parameters from the alignment of each volume to the first b0 volume? if not, how can we specify that?

They are relative the first volume of the 4D file you specified for your --imain.

3- Should we expect any difference between the motion parameters driven from mcflirt and eddy_openmp outputs? if yes, which one is more accurate/preferable?

The eddy output should be considerably more accurate. But typically you would never need to actually use the motion parameters for anything.

Jesper

Thank you!

Mahmoud

On Wed, Aug 17, 2016 at 11:29 AM, Jesper Andersson <[log in to unmask]uk> wrote:

Hi again,

that is right.

Jesper

On 17 Aug 2016, at 16:27, Mahmoud <[log in to unmask]> wrote:

Dear Jesper,

If the MB factor is 2 and number of slices is even it means that no slice was removed from top or bottom, and I shouldn't use the --mb_offs, right?

Thank you,

Mahmoud

On Wed, Aug 17, 2016 at 10:58 AM, Jesper Andersson <[log in to unmask]k> wrote:

Dear Mahmoud,

the help pages are at

http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/

I am literally now writing the help text. I am struggling quite badly with the moinwiki (just don’t get me started!), so it is taking a little longer than I had hoped for. But the --mb and the reason for why you might want to use it should already be there.

Jesper

On 17 Aug 2016, at 15:49, Mahmoud <[log in to unmask]> wrote:

Hello Jesper,

Is there a manual for eddy_openmp that describes the optional arguments in more details?

For example, how helpful would be to use the --mb switch? My data is acquired with MB=2 and GRAPPA=2 . Do I have to add --mb 2 to eddy_openmp command line?

Thank you,

Mahmoud

On Wed, Aug 17, 2016 at 6:09 AM, Jesper Andersson <[log in to unmask]k> wrote:

Dear Michele,

this is a known problem for some acquisition schemes. The patch that was released yesterday will address this issue through the --data_is_shelled flag.

Jesper

On 27 Jul 2016, at 16:46, Michele Guerreri <[log in to unmask]> wrote:

> Hi,
>
> I'm trying to use eddy tool to correct my DW data. When I run the tool i receive these message:
>
> I'm thrown
> terminate called after throwing an instance of 'EDDY::KMatrixException'
>   what():  KMatrixException: msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled
> Aborted
>
> In my experiment I'm using one b_0 and 11 b-values from 200 to 5000 s/mm^2. For each b-value I have 15 directions.
> I have already used eddy on the same data but dividing the 166 4D-volume in three separate 4D-volumes and it worked.
>
> Thank you in advance.
>
> Michele.