Back to the main page.

Bug 2848 - ft_timelockstatistics doesn't cluster properly with custom neighbours struct

Status CLOSED WORKSFORME
Reported 2015-02-20 15:35:00 +0100
Modified 2016-05-09 08:46:40 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Linux
Importance: P5 major
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also:

Pim Mostert - 2015-02-20 15:35:42 +0100

I'm trying to do a cluster-based permutation test on source-level data, defined on a mesh (so not in voxels), for one specific time point. My idea was to use ft_timelockstatistics with a custom neighbours struct, obtained from my mesh using triangle2connectivity. However, the results indicate that the clusters are not calculated correctly. In case this is not actually a bug, then I would greatly appreciate to learn what I'm doing wrong. I compressed the relevant script and datafiles into a zip. It is too large (~5 mb) to attach, but it can be downloaded from my Dropbox here: https://www.dropbox.com/s/llhbhsqgphi3o0m/bug.zip?dl=0 Thanks, Pim


Jan-Mathijs Schoffelen - 2015-02-22 10:24:25 +0100

In theory it should be possible to use ft_sourcestatistics for this, specifying the neighborhood in the cfg as cfg.connectivity. Does this not work, either? If not, could you be somewhat more specific as to how the clusters are incorrect?


Robert Oostenveld - 2015-02-23 10:25:58 +0100

I downloaded the data and copied it to /home/common/matlab/fieldtrip/data/test/ where the FT team can access it. If you want, you can delete/unshare the file again from your dropbox.


Pim Mostert - 2015-02-23 11:34:09 +0100

Created attachment 703 Clusters #1 and #3


Pim Mostert - 2015-02-23 11:34:40 +0100

I didn't know about cfg.connectivity. Now, when I enter an NxN logical connectivity matrix in cfg.connectivity, and morph my data into a data-structure that resembles the result from ft_sourceanalysis, then ft_sourcestatistics does indeed give me the desired results. So for me, the problem is solved at this point. Perhaps cfg.connectivity should be added to the help for ft_sourcestatistics and/or ft_statistics_montecarlo? Nevertheless, using a custom neighboorhood struct with ft_timelockanalysis, as I wanted to do in the first place, should work as well, shouldn't it? Specifically, I assigned a label to each location on the mesh, named 'pnt1' through 'pnt8196' and created a neighbours-struct as described in "help ft_prepare_neighbours". However, this gives me weird clustering - see attachments. The first negative cluster appears to have "holes" in it (Figure 1). The second negative cluster is similar, but for the other hemisphere. The third negative cluster appears to encompass the holes in cluster #1 (Figure 2). Maybe the clustering-algorithm can't handle a neighbours-struct with 8196 elements? Thanks again, Pim


Jan-Mathijs Schoffelen - 2015-02-23 11:47:32 +0100

(In reply to Robert Oostenveld from comment #2) @Robert: could you update the file permissions of the bug2848 directory (and possibly the underlying files), so that the ground troops can read the data :-)? Thanks.


Robert Oostenveld - 2015-02-26 13:06:38 +0100

(In reply to Jan-Mathijs Schoffelen from comment #5) aye aye sir! roboos@mentat001> chmod -R g+rwX bug2848/


Jan-Mathijs Schoffelen - 2015-08-07 14:40:23 +0200

I cannot reproduce the figures with the current version of the code. It may be that in the meantime the code has improved. My initial suspicion was an inconsistency between the assumed order of the 'channels' in the adjacency matrix, in comparison to the order in which the 'channels' ended up in the numeric representation of the data. Long story short, it could have been that ft_selectdata re-ordered the channels (e.g. alphabetized them), which would have led to {'pnt1';'pnt11';'pnt12'}, rather than {'pnt1';'pnt2';'etc}, while the cfg.channel was kept unordered (or vice versa), causing the order in the adjacency matrix to be different. As I said, this does not seem to be a problem (anymore), so I suggest to close it for now. However, we should stay vigilant, because there is some buzz on the discussion list right now, dealing with clustering, and it could be that it is related to this (although the person asking the question has not been very helpful in really sketching the problem, so far)...