[FieldTrip] coherence and group analyses

Maris, E.G.G. (Eric) e.maris at donders.ru.nl
Tue Apr 21 07:38:52 CEST 2015


Dear Jean-Marc Lina,

I’m sorry for this very late reply. Your post (which I requested) had slipped my attention.



Involved in source analyses from MEG/EEG data, I am going through your papers related to statistical testing (Nonparametric stat testing of coherence differences, 2007 and stat testing in electrophys studies, 2012). Mostly concerned with coherence and coherency (either topography or tomography), I have some questions related to nonparametric statistical testing in the case where we have 2 groups (one group per condition, N subjects in each group) of individuals (n trials for each subjects). I will greatly appreciated some information that could help clarifying the followings:
- how do we design the null distribution? permutations are among all subjects?  How do we handle fixed/random effects?

When you have multiple subjects, you should go for a random effects analysis. This implies that the ingredients for your statistical analysis are coherence values for every subject within every condition.

What you do next depends on whether you have a within-groups or a between-groups design. In a within-groups design, every subject has participated in the multiple experimental conditions that you want to compare, and in a between-groups design, every subject has participated in only a single condition and you want to compare these conditions (e.g., patients versus controls, high-versus-low performers).

In a within-groups design, the permutation distribution is obtained by randomly permuting the conditions within every subject.

In a between-groups design, the permutation distribution is obtained by randomly permuting the subjects between the conditions.

- Can we reproduce stricto sensu the Monte-Carlo approach described in the 2007 publication at the level of subjects (each subject being a UO) ?

For an analysis that involves all subjects, the permutation distribution is obtained in a different way as described in the 2007 paper. In that paper, we had between-trials design, which is formally equivalent to a between-subjects designs (involving random permutations of trials between conditions). In a random effects analysis of the data of all subjects, one has to randomly permute the subject-level coherences between the conditions within every subject.

- Can we use the stat defined as the difference of the imaginary part of the coherence ? (averaged over the subjects in a group?)

Yes, you can use every statistic you expect to be sensitive for the phenomenon that you are investigating.


Best,
Eric




With my anticipated thanks,
Best

JM Lina



From: Robert Oostenveld <r.oostenveld at donders.ru.nl<mailto:r.oostenveld at donders.ru.nl>>
Cc: <jim.mckay at candoosys.com<mailto:jim.mckay at candoosys.com>>
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Date: 3 Mar 2015 21:54:55 CET
Reply-To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Magnetic dipole fit vs Equiv. Current dipole fit


Hi Jim

You can do an inverse solution with any method (including dipole fitting) by specifying cfg.vol=[] in the corresponding high-level function (e.g. ft_prepare_leadfield, ft_dipolefitting or ft_sourceanalysis). This causes the forward model to be computed with a magnetic dipole.

If you want to track this down to the lower lever code, have a look at these lines in the code

“forward/ft_voltype.m" line 115 of 138 --83%-- col 11
“forward/ft_compute_leadfield.m" line 280 of 611 --45%-- col 12

My appologies for this not being documented better. I have been using this myself to check on the localization of the headcoils in the CTF “hz.ds” datasets, which worked fine.

I hope you can get it to work for the Sandia Labs system. For the CTF system it is not needed to do these computations in MATLAB, since the CTF electronics does this in (alomst) real-time and the positions are streamed along with the MEG channel data. That makes this this http://fieldtrip.fcdonders.nl/getting_started/realtime_headlocalizer easy for the system we have in Nijmegen. Arjen and I have also been working on making it work for the Elekta system where the fitting has to be done in MATLAB, but have not been able sofar to get it to work robustly. You can find the experiences and (still open) report at http://bugzilla.fcdonders.nl/show_bug.cgi?id=1792.

best regards
Robert




On 25 Feb 2015, at 22:40, Jim McKay <jim.mckay at candoosys.com<mailto:jim.mckay at candoosys.com>> wrote:

Hello Fieldtrippers,

I am consulting with the Sandia Labs on development of an atomic magnetometer based MEG system prototype. One of the areas I am working on is head localization, so I was looking at the code for the realtime head localization in Fieldtrip. I was surprised to see that although the comments talk about using a magnetic dipole forward solution, it actually used the FT dipolefit code which is based on an equivalent current dipole, as far as I can tell.

There should be a significant difference in the forward solutions between MD and ECD, so how does this work? Or am I just missing something?

Cheers,

Jim

--
Jim McKay
Candoo Systems Inc. - Magnetic field sensors, systems, and site surveys
Tel. 778-840-0361
jim.mckay at candoosys.com<mailto:jim.mckay at candoosys.com>
www.candoosys.com<http://www.candoosys.com>

_______________________________________________
fieldtrip mailing list
fieldtrip at donders.ru.nl
http://mailman.science.ru.nl/mailman/listinfo/fieldtrip




From: Robert Oostenveld <r.oostenveld at donders.ru.nl<mailto:r.oostenveld at donders.ru.nl>>
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Date: 3 Mar 2015 22:14:42 CET
Reply-To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] inconsistent chanunit for Neuromag data


Hi Steve

The grad.chanunit pertains to the units that would be computed as the forward solution. The hdr.chanunit pertains to the units of the channel-level data.

Using the ft_convert_units helper function you could convert the units of the gradiometer definition from cm to mm or m. This changes the baseline of the planar gradiometers with a factor of 10 or 100. However, the planar gradient chanel data is not updated simultaneously and remains in the same units (fieldstrength per distance). So it can happen that grad.chanunit and hdr.chanunit are inconsistent.

The consequence (which many people on the list will have noticed, but might not have understood) is that the forward solution - and therefore the inverse solution -  for the Elekta planar gradiometer channels can easily be incorrect: due to the data being in T/m and the forward solution in T/cm (or some other units, I don’t know the typical units from the top of my head). As long as you always use the same pipeline on hte planar gradiometers, you will most likely not notice since you will be interpreting the sourc estimates in “arbitrary units” anyway. But if you were to combine the planar channels with the magnetometers, the planar channels (fieldstrength per distance) would be affected differently than the manetometer channels (fieldstrength) by your choise of geometrical units.

Using the ft_datatype_sens helper function you can ensure that the scaling of the grad structure (which affects the “coilpos" field but also the rows of the “tra" field that correspond to the planar channels) is consistent with your channel level data. If you specify all your data in SI units (T, m, V, etc.) the units of the forward computations will be correct and hence the units of the inverse estimates will also be consistent in SI units (e.g. dipole moment in A/m). The thing is that the different fieldtrip import functions (which come from various origins) return data in non-SI units more often than not :-(

If you work with channel level data, SI units are often not nice. ERFs in Tesla are very small (10^-12). ERPs are usually expressed in uV. Also for anatomcial MRIs it is not convenient to express data in SI units (m) and mm is common. The CTF system by default expresses geometrical distance in cm. Etc… So all systems by themselves made their own “convenient” choices. But if all the data comes together with the physical model, it becomes a mess. The logical choice to solve the inconsistencies is to express it in SI units.

I hope this helps in clarifying the situation.

best regards,
Robert

PS if you search on bugzilla, you can see some (still open) bugs that pertain to this




















On 27 Feb 2015, at 03:53, Steve Patterson <sapttrs at gmail.com<mailto:sapttrs at gmail.com>> wrote:

Hello,

I noticed that fieldtrip produces inconsistent channel units when I
read in Neuromag (vectorview) data.

For example:

%%%%%%%%%%%%%%%%%%%%%%%%

cfg                                = [];
cfg.dataset                   = 'example.fif';
cfg.trialfun                    = 'ft_trialfun_general';
cfg.trialdef.eventtype    = 'STI101';
cfg.trialdef.eventvalue  = [17 18 20];
cfg.trialdef.prestim       = 0.500;
cfg.trialdef.poststim     = 1.000;
cfg                                = ft_definetrial(cfg);
data                              = ft_preprocessing(cfg);

disp(data.hdr.chanunit(1:6));
'T/m'
'T/m'
'T'
'T/m'
'T/m'
'T'

disp(data.grad.chanunit(1:6));
'T'
'T'
'T'
'T'
'T'
'T'

%%%%%%%%%%%%%%%%%%%%%%%%

data.hdr.chanunit is correct and data.grad.chanunit is wrong.

data.grad.chanunit must take precedence in further analysis, because
I've noticed this causes problems downstream.

For example, when using ft_dipolesimulation, the simulated data on the
gradiometer channels is too small in amplitude by a factor of
1/(16.8E-3) (the distance between the gradiometer coil pair in
meters).

This is reflected in the grad.tra matrix, whose non-zero values are
all 1's and -1's, whereas they should be 1's (magnetometers), and +/-
1/16.8E-3 (gradiometers).

If you could fix this, it would be much appreciated!

thanks,

Steve
_______________________________________________
fieldtrip mailing list
fieldtrip at donders.ru.nl<mailto:fieldtrip at donders.ru.nl>
http://mailman.science.ru.nl/mailman/listinfo/fieldtrip






From: Robert Oostenveld <r.oostenveld at donders.ru.nl<mailto:r.oostenveld at donders.ru.nl>>
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Date: 3 Mar 2015 22:18:34 CET
Reply-To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] eeglab2fieldtrip - Fieldtrip vs EEGLAB version


Hi Omar,

The eeglab2fieldtrip.m function lives on the boudary between the two projects. We (i.e. Arno and me) have decided to maintain it on the EEGLAB side and copy it to FieldTrip whenever needed. That is why it is in fieldtrip/external/eeglab.

If you go to
https://code.google.com/p/fieldtrip/source/list?path=/trunk/external/eeglab/eeglab2fieldtrip.m&start=10122
you can see the history. See also http://bugzilla.fcdonders.nl/show_bug.cgi?id=2770

In general for (almost) all code in fieldtrip/external it is being maintained externally, and often by people that are not directly related to the fieldtrip project.

best
Robert


On 16 Feb 2015, at 16:38, Mian, Omar <miano at lsbu.ac.uk<mailto:miano at lsbu.ac.uk>> wrote:

Hello,

There seem to be differences between the eeglab2fieldtrip.m when the Fieldtrip and EEGLAB versions are compared.

Is this an oversight?
Which one is “better” ?

data.cfg.version.id contains a later date in the Fieldtrip version, but the file properties modified date is later in the EEGLAB version.

The versions I am comparing are:
\fieldtrip-20150109\external\eeglab\eeglab2fieldtrip.m
\eeglab13_4_4b\plugins\dipfit2.3\eeglab2fieldtrip.m

Thanks

Omar

---------------------------
Omar Mian, Phd
Research Fellow

School of Applied Sciences
London South Bank University
103 Borough Road
London SE1 0AA
Copyright in this email and in any attachments belongs to London South Bank University. This email, and its attachments if any, may be confidential or legally privileged and is intended to be seen only by the person to whom it is addressed. If you are not the intended recipient, please note the following: (1) You should take immediate action to notify the sender and delete the original email and all copies from your computer systems; (2) You should not read copy or use the contents of the email nor disclose it or its existence to anyone else. The views expressed herein are those of the author(s) and should not be taken as those of London South Bank University, unless this is specifically stated. London South Bank University is a company limited by guarantee registered in England and Wales. The following details apply to London South Bank University: Company number - 00986761; Registered office and trading address - 103 Borough Road London SE1 0AA; VAT number - 778 1116 17 Email address - LSBUinfo at lsbu.ac.uk<mailto:LSBUinfo at lsbu.ac.uk> _______________________________________________
fieldtrip mailing list
fieldtrip at donders.ru.nl<mailto:fieldtrip at donders.ru.nl>
http://mailman.science.ru.nl/mailman/listinfo/fieldtrip




From: Tolga Ozkurt <tolgaozkurt at gmail.com<mailto:tolgaozkurt at gmail.com>>
To: <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Date: 4 Mar 2015 09:54:53 CET
Reply-To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: [FieldTrip] Visualization of Channels for Human Connectome Project MEG data


Dear Fieldtrip list,

I was seeing the MEG files uploaded by “Human Connectome Project”, which seem to be pre-processed by Fieldtrip. The resting data were collected in supine position with 4D Neuromag 248 channels.

When I use the standard command for layout

cfg.layout       = '4D248.lay';

the channel locations do not seem to fit. (Please see the attached figure). I do not quite know the channel distribution of the system; but it seems some channels are out of the head.

Could you give me an idea to project the channel layout properly?

Thank you.

Tolga

--
Tolga Esat Özkurt, PhD
Department of Health Informatics
Middle East Technical University
http://www.metu.edu.tr/~ozkurt/

<alpha_resting_data_example.jpg>


From: "Schoffelen, J.M. (Jan Mathijs)" <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Date: 4 Mar 2015 11:34:27 CET
Reply-To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Visualization of Channels for Human Connectome Project MEG data


Hi Tolga,

There’s a layout that ‘better fits’ the projected channel locations, and which you can obtain from the megconnectome software that accompanies the HCP MEG data. The software can be obtained from here: humanconnectome.org/documentation/MEG1/meg-pipeline.html<http://humanconnectome.org/documentation/MEG1/meg-pipeline.html>
If you download one of the packages and unzip it, you’ll find a ‘template’ directory. Inside, there’s a 4D248.mat file (note that you need the ‘4D248.mat’ in cfg.layout in that case), which you can use as a layout for visualization.

Best wishes,
Jan-Mathijs


On Mar 4, 2015, at 9:54 AM, Tolga Ozkurt <tolgaozkurt at gmail.com<mailto:tolgaozkurt at gmail.com>> wrote:

Dear Fieldtrip list,

I was seeing the MEG files uploaded by “Human Connectome Project”, which seem to be pre-processed by Fieldtrip. The resting data were collected in supine position with 4D Neuromag 248 channels.

When I use the standard command for layout

cfg.layout       = '4D248.lay';

the channel locations do not seem to fit. (Please see the attached figure). I do not quite know the channel distribution of the system; but it seems some channels are out of the head.

Could you give me an idea to project the channel layout properly?

Thank you.

Tolga

--
Tolga Esat Özkurt, PhD
Department of Health Informatics
Middle East Technical University
http://www.metu.edu.tr/~ozkurt/

<alpha_resting_data_example.jpg>_______________________________________________
fieldtrip mailing list
fieldtrip at donders.ru.nl<mailto:fieldtrip at donders.ru.nl>
http://mailman.science.ru.nl/mailman/listinfo/fieldtrip



_______________________________________________
fieldtrip mailing list
fieldtrip at donders.ru.nl<mailto:fieldtrip at donders.ru.nl>
http://mailman.science.ru.nl/mailman/listinfo/fieldtrip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20150421/ce0fe244/attachment-0001.html>


More information about the fieldtrip mailing list