[FieldTrip] disconnected cluster

Tue Nov 10 11:12:26 CET 2015

Hi Roy,

Thanks for looking into it in such detail. I can however not reproduce your problem. Can you update to a more recent version of FieldTrip and try whether it persists?
Given the line numbers in ft_selectdata that you mention, it seems that you are using somewhat older code.

Best,
Jan-Mathijs

On Nov 10, 2015, at 1:52 AM, Roy Cox <roycox.roycox at gmail.com<mailto:roycox.roycox at gmail.com>> wrote:

Hi Jan-Matthijs,

It was quite a quest, but I think/hope I've located the problem. I was typing this email as I was troubleshooting, so skip to 3) to get to the point:

I've tried setting both cfg.channel = 'all' and cfg.channel = cfg.label before calling ft_timelock_statistics. It makes no difference.

1) ft_timelock_statistics

I think the problem occurs at an earlier stage than what I thought at first, namely on line 105 of this function:

[varargin{:}] = ft_selectdata(tmpcfg, varargin{:});

After this, the varargin array of structures has the alphabetical channel order (while the input tmpcfg.channel was still good):

varargin{1}.cfg.channel

ans =

    'Af3'
    'Af4'
    'Af7'

etc

Then after the next line

[cfg, varargin{:}] = rollback_provenance(cfg, varargin{:});

cfg now also contains these channel orders.

2) ft_selectdata

on line 264 the contents of cfg.channel is changed from whatever was put in there (either the cfg.label order or 'all')

if haschan,    [selchan,    cfg] = getselection_chan   (cfg, varargin{:}, cfg.select); end

this jumps to subfunction get_selection on line 619:

3) ft_get_selection

line 630 then correctly selects the requested channels from the label list in varargin{k}.labels

selchannel = ft_channelselection(cfg.channel, varargin{k}.label);

selchannel still has the correct order of channels, but then line 631 calls "union" which puts things in alphabetical order:

label      = union(label, selchannel);

637 finds the correspondences between the two lists:

[ix, iy] = match_str(label, varargin{k}.label);

then there is a loop from 653-660 that does some more reordering/matching that I don't follow,

but ultimately, on 677, the alphabetical list of channels is assigned to cfg.channel:

cfg.channel = label;

I believe this is where the error stems from, because the variable "label" has not had its alphabetical order changed since calling "union" on 631.

Hope this helps,

Roy

On Fri, Nov 6, 2015 at 1:34 AM, Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>> wrote:
Hi Roy,

The inadvertent alphabetization of channels should not occur. This issue has popped up in the past on several occasions (and on several locations in the code) and it has been a really tricky issue to deal with once and for all. Thanks for all the detective work so far. From what you write, it seems that the cfg.channel that goes into channelconnectivity is already in alphabetical order. Would it be possible to track down where this happens? Do you explicitly add the alphabetical list to cfg.channel in your call to ft_timelockanalysis? Does the problem persist if you define cfg.channel = data.label, i.e. the list in the order as it occurs in the data. (I would assume that the order of the channels is the same across all input data structures).

Best,
Jan-Mathijs

On Nov 5, 2015, at 8:58 PM, Roy Cox <roycox.roycox at gmail.com<mailto:roycox.roycox at gmail.com>> wrote:

hi all,

I'm worried that something is not quite right with how the channel neighborhood configuration is used in the formation of spatial clusters.

I first noticed it when I got a significant cluster like below. Plotted are t statistics for a between-group comparison, with the significant "cluster" indicated with white electrodes. Notice F5 and P8 here which are disconnected from the rest. I should also mention that I have only one "time point" (and no frequencies), so it's not possible that these channels are somehow connected via a "time bridge" (if that would even be possible).<cluster.jpg>

I've inspected my channel layout and that looks good:

<2D_layout.jpg>
I've looked at my neighborhood plot and that looks good too, although I notice that frontal channels are plotted to the right here (not sure if that's simply by default):

<neighboorhood.jpg>

Looking into the disconnected channel F5, the neighborhood structure seems in order:

cfg.neighbours(15)

ans =

          label: 'F5'
    neighblabel: {'Af7'  'F3'  'F7'  'Fc5'}

I call ft_timelockstatistics, which then calls ft_statistics_montecarlo, which, on line 165 calls

cfg.connectivity = channelconnectivity(cfg);

Stepping into this function, on line 20 it says:

chans=cfg.channel;

Checking what this variable contains, it has all my channels in alphabetical order, but my electrode location order is most definitely not. I've tried to force the orders to be the same by setting cfg.channel = cfg.label before calling ft_timelockstatistics, but somewhere down the line my channel order is made alphabetical again.

So I suspect that the neighborhood structure, reflecting my actual channel order, is applied to the alphabetical channel order. That would explain why a cluster could be scattered across the brain (and also why there's still some spatial continuity given that alphabetically close channels are usually close together in space).

Has anyone ever seen this? Any suggestions how to solve this (other than making my entire channel location file alphabetical)? I'm also posting this because it may be of relevance to others.

Roy

_______________________________________________
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

_______________________________________________
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/20151110/42481af7/attachment-0001.html>