permutation cluster t-test for planar grads

✉️ Mailing List Archive (read-only)
1

Dear MNE users,

I wish to run permutation cluster t-test (2-tailed) on my sensor level data (cond A vs. cond B). I am wondering how best to deal with the planar gradiometer data from a Neuromag 306 system and would be grateful for advice.

Since I am not interested in the direction of the gradients at individual gradiometers within a pair, I think it makes most sense to combine the data for each 102 pairs using RMS (for each gradiometer then RMS(g) = sqrt(sum(g??+g??)/2)). I would perform the t-tests on these RMS data. I then wondered how neighbourhood definitions for clustering ought to be defined - I was thinking I could replace my magnetometer values with the new RMS gradiometer values and use the neighbourhood definitions from ?neuromag306mag?.

I took the options for the neighbourhood templates after reading this page here:
http://martinos.org/mne/dev/generated/mne.channels.read_ch_connectivity.html#mne.channels.read_ch_connectivity

Does this make sense or would you suggest a different approach? Ought I to obtain t-values for each of the 204 gradiometers and perform the clustering on these values instead?

Many thanks for any guidance,

Lucy MacGregor

2

Hi Lucy,

as far as I see it there aren't any templates available for merged
gradiometers. You could probably do what you describe as all sensors are
anyways organized in triplets, the magnetometer neighbor connectivity
should therefore be enough. We also have a channel remapping method in the
evoked object but it I am not sure up to which extent it can be used beyond
illustrative contexts. Here you would create virtual magnetometers, which
would have the advantage that you keep a more interpretable signal. If you
have used SSS you might also consider just using the magnetometers, as SSS,
so to say, fuses magnetometers and gradiometers. In other words after SSS
they are not any longer independent but provide alternative views on the
same underlying structure with something between 64 and 90 linearly
independent dimensions.

I hope this helps a bit.
Denis

3

Hi Denis,

Thank you for the reply. Since I want to analyse magnetometers and gradiometers separately I will go ahead and use the magnetometer neighbour connectivity for the moment. Am I correct in thinking that there should be no adverse effects on any scaling (grads and mags are obviously in different units) because all the neighbour connectivity does is provide a layout of channel positions/neighbours?

Thanks for drawing my attention to the channel remapping.

Lucy

4

Hi Lucy,

yes you're absolutely conceptualizing it. The neighbour definitions are
simply telling the naive statistical procedures which variables should be
considered neighbours, hence, potentially grouped in a cluster.
But should you use SSS keep in mind that grads and mags are not
independent. If you still observe different effects this is to some extent
arbitrary.

Denis

5

Hi Denis,

Thanks for confirming my understanding of how the templates are used.

Wrt to the creating virtual magnetometers using the channel remapping method, what do you mean when you say it would have the advantage of keeping a more interpretable signal?

Lucy

6

Hi Lucy,

it means that you transform the gradiometers such that the result has
n_channels/2 signals that look like magnetometer signals.

Also see here:
http://martinos.org/mne/dev/auto_examples/preprocessing/plot_virtual_evoked.html

Denis

7

Hi Denis,

Ah, thanks for the link. I will take a look.

Thanks again for the pointers.

Lucy

8

Dear all
  I would be very grateful, if you would kindly clarify the coordinate
system numbering for me in MNE. I have the following questions:
Question:
1. (i) Device coordinate coord_frame=1
     (ii) Head coordinate coord_frame =2?
    (iii)Surface RAS coord_frame=3
    (iv) RAS=4

2. In MNE-Python fwd['info']['chs'][0 ] "below "
  (a) Does the value coord_frame=1 mean it is the device coordinate?
   (b) Where is the coil transformation matrix stored(according to the
transformation matrix diagrams for different coordinate systems) ?
   fwd['info']['chs'][0]
Out[36]:
{'cal': 3.1600000394149674e-09,
  'ch_name': u'MEG 0113',
  'coil_type': 3012,
  'coord_frame': 1,
  'kind': 1,
  'loc': array([-0.1066 , 0.0464 , -0.0604 , -0.0127 ,
0.0057 ,
         -0.99990302, -0.186801 , -0.98240298, -0.0033 , -0.98232698,
          0.18674099, 0.013541 ]),
  'logno': 113,
  'range': 0.00030517578125,
  'scanno': 1,
  'unit': 201,
  'unit_mul': 0}

3. In MNE-Python the forward data structure fwd, it says that for the
EEG sensor the coord_frame=4. Does it mean that the electrode position
has undergone the transformations from Head->Surface RAS->RAS??
fwd['info']['chs'][350]
Out[39]:
{'cal': 0.0001976000057766214,
  'ch_name': u'EEG 045',
  'coil_type': 1,
  'coord_frame': 4,
  'kind': 2,
  'loc': array([-0.06437745, -0.04527977, 0.0883803 , 0.00235201,
0.11096951,
         -0.03500458, 0. , 1. , 0. , 0. ,
          0. , 1. ]),
  'logno': 45,
  'range': 0.00030517578125,
  'scanno': 360,
  'unit': 107,
  'unit_mul': 0}

4. Sorry for being paranoid!!! But, does the ""Matrix""" below
fwd['info']['mri_head_t']
Out[42]:
<Transform | MRI (surface RAS)->head>
[[ 0.99930958 0.00998476 -0.03578702 -0.00316745]
  [ 0.01275932 0.81240469 0.5829544 0.00685511]
  [ 0.03489422 -0.58300841 0.81171643 0.02888404]
  [ 0. 0. 0. 1. ]]
mean that it is the inverse of T2, i.e T2inv??? I ask this because in
order to go from Head->Surface RAS, you need the T2 matrix for
transformation.
Many Many thanks
Sorry for asking what appears to be trivial questions??
Many thanks
best regards parham hashemzadeh

9

1. (i) Device coordinate coord_frame=1
     (ii) Head coordinate coord_frame =2?
    (iii)Surface RAS coord_frame=3
    (iv) RAS=4

These values don't match what we have listed:

https://github.com/mne-tools/mne-python/blob/master/mne/io/constants.py#L199

Which is:

1=device
2=isotrak
3=HPI
4=head
5=MRI (surface RAS)

But hopefully you don't need to deal with them directly.

It might help to look through some of our transformations code
<https://github.com/mne-tools/mne-python/blob/master/mne/transforms.py&gt; if
you plan to work with these coordinate frames directly.

   (b) Where is the coil transformation matrix stored(according to the

transformation matrix diagrams for different coordinate systems) ?

It's in the `loc` parameter stored as triplets of (r0, ex, ey, ez), but
again hopefully you can get what you need from some public function instead
of accessing the attribute directly.

4. Sorry for being paranoid!!! But, does the ""Matrix""" below

fwd['info']['mri_head_t']
Out[42]:
<Transform | MRI (surface RAS)->head>
[[ 0.99930958 0.00998476 -0.03578702 -0.00316745]
  [ 0.01275932 0.81240469 0.5829544 0.00685511]
  [ 0.03489422 -0.58300841 0.81171643 0.02888404]
  [ 0. 0. 0. 1. ]]
mean that it is the inverse of T2, i.e T2inv??? I ask this because in
order to go from Head->Surface RAS, you need the T2 matrix for
transformation.

This means that it's a MRI->Head transform, meaning it will take triplets
in MRI surface RAS space and transform them to the Neuromag head coordinate
system. It sounds like you want Head->MRI instead, which you can get by
using mne.transforms.invert_transform, which is a light wrapper around
scipy.linalg.inv. Our forward solution code does its calculations in head
coordinates, which is why it stores the MRI->Head transformation (it's used
to transform the BEM surfaces, which are natively in MRI RAS coords).

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20160413/11dec086/attachment.html

10

Dear Eric
  Thank you very much for your response. The coord_frame link is very
handy. I asked those questions because I need to implement a different
inverse problem formulation. For the case of EEG, I can use the
leadfield as given by MNE. However, I need volume source points, and my
question is are the volume source points in the same coordinates as EEG
electrodes???
For the case of the MEG, I do not use the forward solution. I need to
know (a) make sure that the MEG sensors are in the same coordinates as
the volume points and then implement a different formulation. So, some
accessibility to the attributes may be necessary and I just need to be
on top of things, making sure how everything is correct for my end.
Many thanks for your response.
many thanks
best regards parham hashemzadeh

11

I received a question with regard to my statement that gradiometers and
magnetometers get "fused" by SSS. So the reason why I say this is that the
covariance of the magnetometers and the gradiometers gets modified
dramatically, especially the cross-terms. Assume SSS of rank=64, the rank
of the mags and the grads is each 64 and the joint rank is also 64; both
are projections from the same SSS origin coordinate system. This gets more
obvious when computing whiteners from the covariance, the overall scaling
will be wrong if sensors are treated independently and with the correct
scaling / rank value one can see that magnetometers get dramatically
down-weighted and only marginally contribute to the overall RMS of the
whitened signal based on the grad+mag covariance. This is also the reason
why we auto-detect the presence of SSS and when showing
evoked.plot_white(covariance) only 1 signal for both mag + grad is shown
for SSSed data, while mags and grads are shown separately otherwise.
We figured out these details while implementing our advanced covariance
methods with Alex, Eric and Matti. From a point of view of the method all
this is not very surprising probably but certainly it remains implicit to
many.
I hope this makes the point a bit clearer.

Denis