[FieldTrip] disconnected cluster

[Roy Cox]

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> 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> 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
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>
>
>
> _______________________________________________
> fieldtrip mailing list
> 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/20151109/8b7ff9c6/attachment-0001.html>