Back to the main page.

Bug 798 - ft_freqstatistics fails on old input data (reported by Yoni)

Status CLOSED FIXED
Reported 2011-07-06 16:12:00 +0200
Modified 2011-11-11 11:19:38 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P1 normal
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2011-07-06 16:12:49 +0200

cfg =[]; cfg.method = 'montecarlo'; cfg.statistic = 'pooledT'; cfg.tail = 0; cfg.alpha = 0.025; cfg.correctm = 'cluster'; cfg.gradfile = '/home/coherence/yonlev/temporary_yonlev/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.res4'; cfg.neighbours = neighbourselection(cfg); cfg.numrandomization = 1000; cfg.clusterstatistic = 'maxsum'; %how to combine the single samples that belong to a cluster, 'maxsum', 'maxsize', 'wcm' (default = 'maxsum') cfg.clusterthreshold = 'parametric';%method for single-sample threshold, 'parametric', 'nonparametric_individual', 'nonparametric_common' (default = 'parametric') cfg.clusteralpha = 0.05;%for either parametric or nonparametric thresholding (default = 0.05) cfg.clustercritval = [-1.96 1.96]; cfg.clustertail = 0; cfg.design(1,1:2*13) = [ones(1,13) 2*ones(1,13)]; cfg.design(2,1:2*13) = [1:13 1:13]; cfg.ivar =1; cfg.uvar =2; stat_second_test = ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj3,t2_subj4,t2_subj5,t2_subj6,t2_subj7,t2_subj8,t2_subj9,t2_subj10,t2_subj11,t2_subj12,t2_subj13,t2_subj1_null,t2_subj2_null,t2_subj3_null,t2_subj4_null,t2_subj5_null,t2_subj6_null,t2_subj7_null,t2_subj8_null,t2_subj9_null,t2_subj10_null,t2_subj11_null,t2_subj12_null,t2_subj13_null); %%%% et voila ce que ca me ressort lorsque j'execute ce script: stat_second_test = ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj3,t2_subj4,t2_subj5,t2_subj6,t2_subj7,t2_subj8,t2_subj9,t2_subj10,t2_subj11,t2_subj12,t2_subj13,t2_subj1_null,t2_subj2_null,t2_subj3_null,t2_subj4_null,t2_subj5_null,t2_subj6_null,t2_subj7_null,t2_subj8_null,t2_subj9_null,t2_subj10_null,t2_subj11_null,t2_subj12_null,t2_subj13_null); Warning: NEIGHBOURSELECTION is only a compatibility wrapper, which will soon be removed. Please instead call FT_NEIGHBOURSELECTION. > In neighbourselection at 16 Obtaining the gradiometer configuration from a file. there are on average 8.9 neighbours per channel ??? Error using ==> ft_checkdata at 269 This function requires freq data as input. Error in ==> ft_freqstatistics at 124 varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'freq', 'feedback', 'no');


Robert Oostenveld - 2011-07-06 16:17:10 +0200

The problem can be confirmed with >> ft_datatype(t2_subj1) ans = unknown >> t2_subj1 t2_subj1 = stat: [274x1 double] df: [274x1 double] critval: [274x2 double] prob: [274x1 double] mask: [274x1 logical] dimord: 'chan' label: {274x1 cell} cfg: [1x1 struct] powspctrm: [274x1 double]


Robert Oostenveld - 2011-07-06 16:19:36 +0200

>> t2_subj1.cfg ans = channel: {274x1 cell} latency: [0.5000 1] frequency: [2 26] avgovertime: 'yes' avgoverchan: 'no' avgoverfreq: 'yes' method: 'analytic' statistic: 'indepsamplesT' design: [1x430 double] ivar: 1 trackconfig: 'off' checkconfig: 'loose' checksize: 100000 roi: [] avgoverroi: 'no' channelcmb: [] precision: 'double' version: [1x1 struct] previous: {[1x1 struct] [1x1 struct]} dimord: 'chan_freq_time' dim: [274 1 1] correctm: 'no' alpha: 0.0500 tail: 0


Robert Oostenveld - 2011-07-06 16:48:28 +0200

I (hopefully) fixed the problem in ft_checkdata by converting dimord into chan_freq and adding freq=nan to the data structure. manzana> svn commit utilities/ft_checkdata.m utilities/ft_datatype.m Sending utilities/ft_checkdata.m Sending utilities/ft_datatype.m Transmitting file data .. Committed revision 3781.


Yoni Levy - 2011-07-11 16:32:28 +0200

(In reply to comment #3) For some reason, now while running the same ft_freqstatistics, the output is lacking any significance (stat_second_test.stat.negclusters = empty matrix). Hence when attempting to plot, I read the output: "no clusters present with a p-value lower than the specified alpha, nothing to plot". > I (hopefully) fixed the problem in ft_checkdata by converting dimord into > chan_freq and adding freq=nan to the data structure. > > manzana> svn commit utilities/ft_checkdata.m utilities/ft_datatype.m > Sending utilities/ft_checkdata.m > Sending utilities/ft_datatype.m > Transmitting file data .. > Committed revision 3781.


Robert Oostenveld - 2011-07-12 08:39:23 +0200

what makes you believe this to be an error in fieldtrip, and not a feature of the data? Did you look at the distribution of the clusters and the summed stats for the clusters in the observed data?


Robert Oostenveld - 2011-07-13 14:46:38 +0200

changed the status for a whole bunch of resolved bugs to CLOSED


Yoni Levy - 2011-07-28 14:29:41 +0200

To perform the ft_freqstatistics operation, I reloaded the old data (t2_subj1,...,t2_subj13, t2_subj1_null,..t2_subj13_null), and then I run ft_freqstatistics as follows: ***************************** ***************************** ***************************** cfg =[]; cfg.method = 'montecarlo'; cfg.statistic = 'pooledT'; cfg.tail = 0; cfg.alpha = 0.025; cfg.correctm = 'cluster'; cfg1.gradfile = '/home/coherence/yonlev/temporary_yonlev/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.res4'; cfg1.method = 'distance'; cfg.neighbours = ft_neighbourselection(cfg1); cfg.numrandomization = 1000; cfg.clusterstatistic = 'maxsum'; cfg.clusterthreshold = 'parametric'; cfg.clusteralpha = 0.05; cfg.clustercritval = [-1.96 1.96]; cfg.clustertail = 0; cfg.design(1,1:2*13) = [ones(1,13) 2*ones(1,13)]; cfg.design(2,1:2*13) = [1:13 1:13]; cfg.ivar =1; cfg.uvar =2; stat_second_test_july11 = ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj3,t2_subj4,t2_subj5,t2_subj6,t2_subj7,t2_subj8,t2_subj9,t2_subj10,t2_subj11,t2_subj12,t2_subj13,t2_subj1_null,t2_subj2_null,t2_subj3_null,t2_subj4_null,t2_subj5_null,t2_subj6_null,t2_subj7_null,t2_subj8_null,t2_subj9_null,t2_subj10_null,t2_subj11_null,t2_subj12_null,t2_subj13_null); ***************************** ***************************** ***************************** Then, for a reason which is unclear to me, the output data of the 'ft_freqstatistics' contains empty matrices, as follows: ***************************** ***************************** stat_second_test_july11 = prob: [274x0 double] posclusters: [274x0 double] posclusterslabelmat: [274x0 double] posdistribution: [1x1000 double] negclusters: [274x0 double] negclusterslabelmat: [274x0 double] negdistribution: [1x1000 double] mask: [274x0 logical] stat: [274x0 double] ref: [274x0 double] dimord: 'chan_freq' label: {274x1 cell} freq: [] cfg: [1x1 struct] ***************************** ***************************** Any idea of what went wrong? Thanks, Yoni


Robert Oostenveld - 2011-08-25 09:25:03 +0200

> Any idea of what went wrong? perhaps no data was selected? Perhaps there is no overlapping data in the subjects that you are appending (if one subject goes from 10-40Hz and another from 50-100Hz then it won't work). I don't have a mat file that allows me to reproduce the bug. Please prepare a mat file such that I can do load bug798 ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj3,t2_subj4,t2_subj5,t2_subj6,t2_subj7,t2_subj8,t2_subj9,t2_subj10,t2_subj11,t2_subj12,t2_subj13,t2_subj1_null,t2_subj2_null,t2_subj3_null,t2_subj4_null,t2_subj5_null,t2_subj6_null,t2_subj7_null,t2_subj8_null,t2_subj9_null,t2_subj10_null,t2_subj11_null,t2_subj12_null,t2_subj13_null); where the input data should be as small as possible to reproduce the bug (e.g. use fewer subjects, the bug should also be there with 2 subjects) and where the input cfg does not point to other data files.


Robert Oostenveld - 2011-08-31 17:54:41 +0200

On 31 Aug 2011, at 8:53, Yoni Levy wrote: Dear Robert, I wrote you a week ago regarding bug 798. In case it got lost somewhere, here again is what I wrote. If it is needed to again place the files in the common/temporary space please let me know. Cheers, Yoni


Robert Oostenveld - 2011-08-31 17:55:07 +0200

(In reply to comment #9) > On 31 Aug 2011, at 8:53, Yoni Levy wrote: > > Dear Robert, > I wrote you a week ago regarding bug 798. In case it got lost somewhere, here > again is what I wrote. If it is needed to again place the files in the > common/temporary space please let me know. > > Cheers, Yoni please respond to comment 8 above.


Yoni Levy - 2011-08-31 18:48:22 +0200

(In reply to comment #8) > > Any idea of what went wrong? > > perhaps no data was selected? Perhaps there is no overlapping data in the > subjects that you are appending (if one subject goes from 10-40Hz and another > from 50-100Hz then it won't work). > > I don't have a mat file that allows me to reproduce the bug. Please prepare a > mat file such that I can do > > load bug798 > ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj3,t2_subj4,t2_subj5,t2_subj6,t2_subj7,t2_subj8,t2_subj9,t2_subj10,t2_subj11,t2_subj12,t2_subj13,t2_subj1_null,t2_subj2_null,t2_subj3_null,t2_subj4_null,t2_subj5_null,t2_subj6_null,t2_subj7_null,t2_subj8_null,t2_subj9_null,t2_subj10_null,t2_subj11_null,t2_subj12_null,t2_subj13_null); > > where the input data should be as small as possible to reproduce the bug (e.g. > use fewer subjects, the bug should also be there with 2 subjects) and where the > input cfg does not point to other data files. I checked the data and couldnt find any mismatch in the overlapping data between the subjects that i am appending. I placed in 'common/temporary/4Robert O' the four files for the two subjects that i used for the test. I also placed the grad file there. Here is the script I use to run the ft_freqstatistics: cfg =[]; cfg.method = 'montecarlo'; cfg.statistic = 'pooledT'; cfg.tail = 0; cfg.alpha = 0.025; cfg.correctm = 'cluster'; cfg1.gradfile = '/home/coherence/yonlev/temporary_yonlev/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.ds/CriticConsc_CriticConsc_20080715_01.res4'; cfg1.method = 'triangulation'; cfg1.feedback='yes'; cfg.neighbours = ft_neighbourselection(cfg1); cfg.numrandomization = 1000; cfg.clusterstatistic = 'maxsum'; cfg.clusterthreshold = 'parametric'; cfg.clusteralpha = 0.05; cfg.clustercritval = [-1.96 1.96]; cfg.clustertail = 0; cfg.design(1,1:2*2) = [ones(1,2) 2*ones(1,2)]; cfg.design(2,1:2*2) = [1:2 1:2]; cfg.ivar =1; cfg.uvar =2; stat_second_test_july11 = ft_freqstatistics(cfg,t2_subj1,t2_subj2,t2_subj1_null,t2_subj2_null);


Robert Oostenveld - 2011-08-31 21:43:40 +0200

(In reply to comment #11) I failed to locate the attachment. Could you send the mat file that is needed to reproduce the problem once more (see comment #8)?


Yoni Levy - 2011-09-01 13:09:57 +0200

(In reply to comment #12) > (In reply to comment #11) > > I failed to locate the attachment. Could you send the mat file that is needed > to reproduce the problem once more (see comment #8)? I now sent the attachment via email.


Robert Oostenveld - 2011-09-01 14:55:41 +0200

I tracked the bug down to ft_selectdata, where I already made some changes. However, solving the other problems is probably better done by JM. To facilitate debugging, I added fieldtrip/test/test_bug798.m and copied the data to come/common. @Jan-Mathijs, could you have a look at it? It has to do with parameter selection on a freq structure and with appending (where the dimord is not updated properly). See the last section of the test script.


Jan-Mathijs Schoffelen - 2011-09-01 17:05:00 +0200

The issue propagating with each fix ;o). I get a crash in line 38 of the test script. ft_selectdata tries to automatically figure out along which dimension to concatenate the input data. The required behavior here is that the single subjects are concatenated, and a dimord of 'rpt_XXXXXX' is returned. Now, the input data is fixed in checkdata, to contain a freq field (set to NaN). Due to this, ft_selectdata does not manage to recognize that the data shouldn't be appended in the freq-dimension. This causes the present problem. My suggestion would be, to explicitly move the 'append' functionality to the respective ft_appendXXX functions, and to specify a key-value pair that determines the 'append' direction. This would also solve a related bug, where some tolerance in inequal frequency bins is required.


Robert Oostenveld - 2011-09-01 20:29:42 +0200

(In reply to comment #15) >... > This causes the present problem. You are right, thanks for the detailed analysis. > My suggestion would be, to explicitly move the 'append' functionality to the > respective ft_appendXXX functions, and to specify a key-value pair that > determines the 'append' direction. This would also solve a related bug, where > some tolerance in inequal frequency bins is required. Since the problem starts with the freq-axis having the value nan (which I recently invented and added to ft_checkdata), I suggest to fix it by setting freq=0 instead of freq=nan. Then I can also remove part of the (incomplete) workaround in ft_selectdata. Let's discuss the append issue at a later time. Note that there is still an open issue with parameter selection, see bug #921. @Yoni: it now works with attached script.


Robert Oostenveld - 2011-09-01 20:30:23 +0200

Created attachment 129 test script based on input from yoni


Jan-Mathijs Schoffelen - 2011-09-01 21:33:50 +0200

I implemented functionality for concatenation across observations in ft_appendfreq directly. ft_freqstatistics does not rely on ft_selectdata anymore for the concatenation, but on ft_appendfreq (which does not call ft_selectdata anymore). The concatenation should now work more robustly. FIXME: as of yet it does probably not yet work for crsspctrm / fourierspctrm. the testscript now runs without problems.


Yoni Levy - 2011-09-04 22:18:10 +0200

(In reply to comment #18) Thank you for resolving this bug. However, there still remains a bug when running my old data, while using this other freqstatistics script; once again, this script worked perfectly well in the past, and now no more; I cant manage tracking the bug: for tt=[4,6] load(strcat('LF_o_', num2str(tt))); load(strcat('LF_t_', num2str(tt))); sizeo = size(LF_o.powspctrm); sizet = size(LF_t.powspctrm); tatao= sizeo(1); tatat = sizet(1); cfg =[]; cfg.channel = 'all'; cfg.avgoverchan = 'yes'; cfg.method = 'analytic'; cfg.statistic = 'indepsamplesT'; cfg.design(2,1:tatao+tatat) = [1:tatao 1:tatat]; cfg.design(1,1:tatao+tatat) = [ones(1,tatao) 2*ones(1,tatat)]; cfg.ivar =1; eval(['t_t_o_subj' num2str(tt) ' =ft_freqstatistics(cfg,LF_o,LF_t);']); end; " I receive either the error message of this type (when loading data files 'LF_o_subj4' and 'LF_t_subj4'): ??? Error using ==> ft_appendfreq at 157 appending across observations is not possible, because the dimensions are incompatible Error in ==> ft_freqstatistics at 241 data = ft_appendfreq(tmpcfg, varargin{:}); or of that type (when loading data files 'LF_o_subj6' and 'LF_t_subj6'): not performing a correction for multiple comparisons ??? Reference to non-existent field 'time'. Error in ==> ft_freqstatistics at 327 stat.time = data.time; Would you be able to indicate to me whether this is again an appending bug or another that I cannot track? p.s. the files are heavy so I put them inside the directory home/common/temporary/yoni Thanks, Yoni


Robert Oostenveld - 2011-09-05 09:05:53 +0200

please don't spam the bugzilla system without providing sufficient information to reproduce the bug this is another bug on another dataset, so it should not be added to bug #798


Robert Oostenveld - 2011-09-05 09:17:56 +0200

(In reply to comment #20)\ I reposted the problem as bug #931


Yoni Levy - 2011-09-05 09:28:24 +0200

(In reply to comment #20) > please don't spam the bugzilla system without providing sufficient information > to reproduce the bug > > this is another bug on another dataset, so it should not be added to bug #798 alright, I just thought that since the title of bug 798 was concerning this same function and also incompatibility with old dataset that it would be adequate to include as follow-up. But I see the rational for opening a new bug for it.


Robert Oostenveld - 2011-09-14 14:33:26 +0200

I closed all the bugs that were in the status RESOLVED. This includes the ones that we just discussed in the weekly fieldtrip meeting, but also the bugs that we did not discuss.


Robert Oostenveld - 2011-11-03 21:55:59 +0100

Hoi Thijs het testscript voor deze bug geeft weer een fout, wat ergens diep in selectdata gebeurt. We moeten even overleggen hoe we selectdata gaan aanpakken. Robert


Jan-Mathijs Schoffelen - 2011-11-04 09:33:28 +0100

Het probleem wordt veroorzaakt doordat in selectdata de concatenatie van de vereiste parameter (in dit geval powspctrm) teruggestopt wordt in data{1}. De dimord enzo worden wel aangepast, maar de .stat/.prob/.mask worden niet verwijderd uit de data-structuur. Dit levert later een probleem op in dimlength omdat de interne consistentie van de data-structuur niet om over naar huis te schrijven is. Ik heb een tijdelijke fix gemaakt, waarbij de geconcateneerde data-structuur on-the-fly wordt aangemaakt. Mijn voorstel zou zijn om de functionaliteit van het appenden door de respectievelijke appendXXX functies te laten uitvoeren en het hele stuk zoals het nu in selectdata zit daar te reimplementeren. Ik heb overigens gisteren ft_freqgrandaverage wat opgeschoond; Ik zie voor me, dat functionaliteit van ft_freqgrandaverage ge-merged wordt met die in appendfreq


Robert Oostenveld - 2011-11-11 11:19:38 +0100

I closed all bugs that were recently resolved.