Back to the main page.
Bug 3184 - getdimord fails on pcc output
| Status | CLOSED FIXED |
| Reported | 2016-10-12 20:19:00 +0200 |
| Modified | 2016-11-29 09:00:18 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jens Klinzing - 2016-10-12 20:19:41 +0200
Ok, this one is very specific (and because of it kept me busy for most of the day). When called on wavelet PCC data (ft_sourceanalysis with method=pcc on data frequency-transformed with Morlet wavelets), getdimord(data, 'mom') results in a wrong result. In my case this is '{pos}_freq_unknown' while it should actually be '{pos}_freq_rpt'. This leads to all kinds of problems, e.g. when forwarding the data to ft_connectivityanalysis. Interestingly, even if the beamformer output contained the correct dimord field this does not change the problem. I attached two example source structures. One was frequency-transformed with mtmfft one with wavelet. Both datasets were then projected to source space using cfg=[]; cfg.method = 'pcc'; cfg.grid = grid; cfg.headmodel = vol; cfg.keeptrials = 'yes'; cfg.pcc.keepfilter = 'yes'; cfg.pcc.realfilter = 'yes'; cfg.fixedori = 'yes'; source = ft_sourceanalysis(cfg, freq); getdimord(source,'mom') gives the correct answer for the mtmfft source but not the wavelet one. I cant find a structural difference between the two datasets, other that one contains data from more than one taper (and that they have different numbers of filter channel labels because they come from different datasets but structurally i do not see any other difference).
Jens Klinzing - 2016-10-12 20:26:49 +0200
Example data: https://www.dropbox.com/s/znwhcilnjprfvi7/exampledata.mat?dl=0
Jan-Mathijs Schoffelen - 2016-10-13 10:59:30 +0200
Hmmm, I have noticed this, too. Thanks for reporting and filing the bug. I'll look into it
Jan-Mathijs Schoffelen - 2016-10-13 11:24:59 +0200
Actually, they're both incorrect should be {pos}_ori_rpttap in both cases, no freq.
Jan-Mathijs Schoffelen - 2016-10-13 11:28:07 +0200
Hmmm, it seems also that the source structure is kind of unexpected, it lacks a 'csdlabel' field. could you upload the grid/vol/freq_mtmfft/freq_wvlt, too? thanks
Jens Klinzing - 2016-10-13 12:08:38 +0200
I see, yes the csdlabel field is removed when subselecting trials (ft_selectdata). grid and vol are different for the two datasets, the mtmfft is from the beamformer tutorial, the wavelet one is one of my eeg datasets. I can try to create two analogous datasets based on the beamformer tutorial later today.
Jan-Mathijs Schoffelen - 2016-10-13 12:20:41 +0200
no worries. Can you then upload your eeg based vol/grid. I'll grab some data from somewhere for the mtmfft stuff.
Jan-Mathijs Schoffelen - 2016-10-13 13:17:30 +0200
Hi Jens, I suspect that your initial bug report was inspired by you getting stuck on a higher level function call? (e.g. ft_connectivityanalysis). Could you confirm?
Jan-Mathijs Schoffelen - 2016-10-13 13:20:25 +0200
I have now verified, that the following should work: source_wvlt.avg.csdlabel = {'scandip'}; getdimord(ft_datatype_source(source_wvlt), 'mom') this should return {pos}_ori_rpt I have changed ft_selectdata, so that csdlabel does not get lost along the way. I am not sure whether getdimord is expected to work fine when data has not been passed through ft_datatype_source (effectively getting rid of the '.avg.' as an intermediate field. I suggest to PR the changes I made to ft_selectdata, and to follow up potentially on a newly generated bug if your original problem still persists...
Jan-Mathijs Schoffelen - 2016-10-13 13:48:34 +0200
I merged it into the master branch
Jens Klinzing - 2016-10-13 16:26:35 +0200
Hey, thanks for picking up that issue so quickly. It has resolved the issue in ft_connectivityanalysis because there the data is restructured before getdimord is called (all fields in data.avg are moved one level up and then getdimord is able to guess the correct dimensions). I still cant get a correct result by calling getdimord on the original source-level data (getdimord still gives '{pos}_freq_unknown') but this might be because I failed in bringing the data in the correct form before calling ft_sourceanalysis (I turned all timepoints into repetitions because sourceanalysis wasnt able to deal with my variable-length trials). Thats still odd, though, because the resulting source-level datasets looked identical to me, in everything but the number of tapers. Concerning your other question, yes the whole issue arose when I tried to calculate connectivity using the powercorr_ortho method. This still failes, this time at line 927 where ft_connectivityanalysis tries to directly access data.dimord which is not present in the data (i think it is never present in DICS or PCC data). At this part of the code dtype is 'freq', not 'source'. Just in case this is the reason for the problem.
Jan-Mathijs Schoffelen - 2016-10-13 16:29:49 +0200
Thanks for the feedback Jens. Well, I think you can work around this by explicitly removing the 'label' field. After conversion (i.e. after the call to ft_datatype_source) the structure may contain a label-field (if filters/leadfields are kept), leading fieldtrip to recognize it as 'freq', which is incorrect in this case.
Jens Klinzing - 2016-10-13 16:53:48 +0200
Yes thanks that works!