Back to the main page.
Bug 3029 - ft_sourceanalysis: failure when using 'dics' as method with fourier input
| Status | CLOSED FIXED |
| 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: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| 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 github.com/schoffelen/fieldtrip.git, 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