Back to the main page.

Bug 3029 - ft_sourceanalysis: failure when using 'dics' as method with fourier input

Reported 2015-12-15 21:03:00 +0100
Modified 2019-08-10 12:32:41 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to:
Depends on:
See also:

Jan-Mathijs Schoffelen - 2015-12-15 21:03:10 +0100

probably PCC is affected as well. Surprising that no one has noticed this before, because it seems to be due to the revamped prepare_freq_matrices. Diagnosis: if 'dics' is used, without too many toeters en bellen in the cfg to ft_sourceanalysis, prepare_freq_matrices returns an NchanxNchan cad-matrix, but an Ntrials that reflects the number of trials in the input data. This is due to the cfg.keeptrials is set to 'no' in ft_sourceanalysis, which is inherited by prepare_freq_matrices, while the default (and required value) in prepare_freq_matrices is 'yes'.

Jan-Mathijs Schoffelen - 2016-02-11 08:55:07 +0100

Added comment: it seems that the refchan handling in ft_sourceanalysis for DICS fails as well. This has been reported by David Pedrosa. Course of action: -create a git branch for this bug. -write a test function to reproduce the problem. -fix it. -merge the branch into the main repo.

Jan-Mathijs Schoffelen - 2016-02-11 11:25:57 +0100

I have created a separate branch in my local version of the repo. The test function now reproduces part of the problems.

Jan-Mathijs Schoffelen - 2016-02-11 11:34:18 +0100

Just playing around a bit to get more fluent using git: I pushed the branch bug3029 to my schoffelen/fieldtrip.git repo, so that other people can check out what's happening there.

Jan-Mathijs Schoffelen - 2016-02-15 11:41:56 +0100

Hi eavesdroppers! I have pushed a branch to my fieldtrip repository on, called bug3029. I think I fixed the issues. I would appreciate if you could test this by merging this branch into your local fieldtrip clone and try it out, before I 'pull request' it to fieldtrip/fieldtrip.

David Pedrosa - 2016-02-15 11:52:05 +0100

Thanks for the (fast) effort! Will try your modified code today and comment about the results. Best, David

R Seymour - 2016-02-16 14:16:38 +0100

Thanks Jan-Mathijs. I tried this out and it went past the reshape error.. but then when I tried to do whole-brain coherence I encountered some memory issues (although this could be due to my PC!). Rob

David Pedrosa - 2016-02-17 11:07:34 +0100

Dear Jan-Mathijs, it works for my data. Thanks again. Best, David

Jan-Mathijs Schoffelen - 2016-02-17 12:54:06 +0100

OK, thanks for the feedback both. I have merged this branch now with fieldtrip/fieldtrip and removed the bug3029 branch.

Jens Klinzing - 2016-09-08 17:45:32 +0200

I am not sure if this is the intended behavior but calling ft_sourceanalysis with fourier input still leads to an error if cfg.rawtrial = 'yes' and (by default:) cfg.keeptrials = 'no'. The reason is clear already from the above discussion but let me quickly repeat: In ft_sourceanalysis, line 488 (in the case of cfg.method = 'dics') a call is made to prepare_freq_matrices and there, starting from line 77 - in case no crsspctrm present and cfg.keeptrials = 'no' - ft_checkdata is called with a desired output of 'fullfast' instead of 'full'. This leads to an output of only one trial. This is different for data containing a cross spectrum, this is why I think its an unexpected behavior. Having only one trial leads to an error later in ft_sourceanalysis line 555 (due to the combination of Ntrials = 1 and cfg.rawtrial = 'yes'). Maybe I'm also a bit confused about the meaning of rawtrial vs. keeptrials. The tutorial on common filters tells the user to use rawtrial = 'yes' (not keeptrials) and that also leads to trial information in the output (just not for fourier input).

Jan-Mathijs Schoffelen - 2016-09-08 21:18:25 +0200

does it work with method = 'pcc'?

Jens Klinzing - 2016-09-10 14:24:43 +0200

(In reply to Jan-Mathijs Schoffelen from comment #10) No, PCC seems to do exactly the same, again leading to an error in line 555.

Jan-Mathijs Schoffelen - 2016-09-12 09:15:00 +0200

OK, @Jens: I suggest to make this into a separate bug, including Robert on the CC list. The problem can be circumvented by calling ft_sourceanalysis twice. The first time around with cfg.keepfilter = 'yes', and not asking for individual trials, the second time can then be called with the appropriate cfg, where I always forget whether it should be cfg.singletrial/rawtrial/keeptrials or some appropriate combination thereof. I typically compute the single trial power by hand, due to the computational clunkiness of the FT code. My suggestion would be, to clean up the deprecated stuff related to rawtrial/singletrial/keeptrials (I believe that even the original 'rawtrial' functionality does not work with a hard coded error in the code), so that the options behave as the user would expect. To this end I would ask you to get started on the following: -create a new bug out of this -make a branch on git, so that we can start working on this -make a description of the preferred solution -discuss what needs to be done code-wise to get to this solution -implement it

Robert Oostenveld - 2019-08-10 12:32:41 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on