[FieldTrip] Questions on Functional Connectivity results using debiased wPLI
SERGIO OSORIO GALEANO
srosorio at uc.cl
Thu Sep 23 15:15:40 CEST 2021
Dear Jan,
Your first trial only has a single sample. It is impossible to spectrally
transform a single sample time course, this causes all kinds of low-level
errors, the one you reported below.
No, not quite. Let me explain myself again: ft_selectdata is outputting one
sample and one value for the first trial alone when using the short
latency. It is not the case that the first trial had only one sample in the
input data to begin with.
Here's the input to ft_selectdata:
data =
struct with fields:
fsample: 1024
trial: {1×117 cell}
time: {1×117 cell}
label: {100×1 cell}
cfg: [1×1 struct]
data.trial
ans =
1×117 cell array
Columns 1 through 9
{100×1251 double} {100×1251 double} {100×1251 double}
{100×1251 double} ......
data.time
ans =
1×117 cell array
Columns 1 through 10
{1×1251 double} {1×1251 double} {1×1251 double} {1×1251
double} .......
As you can see, the first trial is just fine and looks like any other
trial. When I call ft_selectdata with cfg.latency = 0:1, this is the output
data (below). Note that the function works as expected shortening the time
vector to the desired length/latency for all trials.
data.trial
ans =
1×117 cell array
Columns 1 through 9
{100×251 double} {100×251 double} {100×251 double} {100×251
double}
data.time
ans =
1×117 cell array
Columns 1 through 11
{1×251 double} {1×251 double} {1×251 double} {1×251 double}
However, this is the output if I use any cfg.latency parameter shorter than
one second (e.g. .15-.25, 0-.5, .5-1, etc). As you can see in that case,
ft_selectdata operates in the first trial alone in an unexpected manner.
data.trial
ans =
1×117 cell array
Columns 1 through 9
{100×1 double} {100×1251 double} {100×1251 double} {100×1251
double}
data.time
ans =
1×117 cell array
Columns 1 through 10
{[0.1480]} {1×1251 double} {1×1251 double} {1×1251 double}
So my question is whether there is any reason why ft_selectdata behaves
like this when using cfg.latency parameters shorter than one second. Sorry
if I wasn't clear enough.
Best,
*Sergio A. Osorio*
Laboratory for Cognitive and Evolutionary Neuroscience
Center for Medical Research - Faculty of Medicine
Pontificia Universidad Católica de Chile
El jue, 23 sept 2021 a las 4:07, Schoffelen, J.M. (Jan Mathijs) via
fieldtrip (<fieldtrip at science.ru.nl>) escribió:
> Hi Sergio,
>
> Yes, you are doing something wrong:
>
> % select the portion of the data I want to compute the wPLI for
> cfg = [ ];
> cfg.latency = .15:.25; <<<<<<<<<<<<<<
> if I use 0:1 or 1:1.5, *ft_freqanaylisis* runs without any problem, but
> if I use any other latency within 1 second it doesn't work.
> data = ft_selectdata(cfg,data);
>
> % here's the output structure
>
> data =
>
>
> struct with fields:
>
>
> fsample: 250
>
> trial: {1×117 cell}
>
> time: {1×117 cell}
>
> label: {100×1 cell}
>
> cfg: [1×1 struct]
>
> data.trial
>
>
> ans =
> 1×117 cell array
> Columns 1 through 9
>
> {100×1 double} {100×1251 double} {100×1251 double} % averaged
> first trial in the 2nd dimension instead of selecting the time interval of
> interest
>
>
>
> Your first trial only has a single sample. It is impossible to spectrally
> transform a single sample time course, this causes all kinds of low-level
> errors, the one you reported below.
>
> I don’t know what you mean with the statement that ft_selectdata does not
> work with ‘any other latency within 1 second’, but I suggest you first
> inspect your data, and specifically the time axes of the individual trials.
>
> Best wishes,
> Jan-Mathijs
>
>
>
>
> data.time
>
> ans =
> 1×117 cell array
> Columns 1 through 10
>
> {[0.1480]} {1×1251 double} {1×1251 double}
>
>
> % Now call the ft_freqanalysis function
> cfg = [ ];
> cfg.output = 'fourier';
> cfg.method = 'mtmfft';
> cfg.taper = 'dpss';
> cfg.foi = linspace(1,31,60);
> cfg.tapsmofrq = 4;
> tf_data = ft_freqanalysis(cfg,data);
>
> Error using dpss>parseinputs (line 308)
> Time-bandwidth product NW must be a positive number.
>
>
> Error in dpss (line 62)
> [method,k,Ni,traceFlag,N,NW] = parseinputs(N,NW,varargin{:});
>
>
> Error in ft_specest_mtmfft>double_dpss (line 362)
> tap = dpss(double(a), double(b), varargin{:});
>
>
> Error in ft_specest_mtmfft (line 151)
>
> tap = double_dpss(ndatsample,ndatsample*(tapsmofrq./fsample))';
>
>
> Error in ft_freqanalysis (line 563)
>
> [spectrum,ntaper,foi] = ft_specest_mtmfft(dat, time, 'taper',
> cfg.taper, options{:}, 'feedback', fbopt);
>
>
> Error in Connectivity_wPLI (line 68)
>
> tf_data = ft_freqanalysis(cfg,data);
>
>
>
> All best,
>
> *Sergio. *
>
>
>
> El mié, 15 sept 2021 a las 15:09, SERGIO OSORIO GALEANO (<srosorio at uc.cl>)
> escribió:
>
>> Yes, you made a mistake in the (assumptions underlying) the
>> implementation: the cfg.toi that you supply before ft_freqanalysis is not
>> going to have any effect if you use ‘mtmfft’ as a method, since this method
>> just provides a single estimate of the spectrum using the whole ’trial’ for
>> the estimation.
>>
>>
>> Oh, that makes perfect sense. Cheers Jan! Really appreciate it.
>>
>> *Sergio.*
>>
>>
>>
>> El mié, 15 sept 2021 a las 14:29, Schoffelen, J.M. (Jan Mathijs) via
>> fieldtrip (<fieldtrip at science.ru.nl>) escribió:
>>
>>> Hi Sergio,
>>> >
>>> > 1) Regardless of whether I use my full time window of interest (0-1.5
>>> s) or whether I estimate wPLI for two separate shorter time windows (0-.7 s
>>> and .7-1.5 s), the results are always identical to one another. Is this
>>> normal behaviour in wPLI analyses or is there something potentially wrong
>>> with how I've implemented it?
>>>
>>> Yes, you made a mistake in the (assumptions underlying) the
>>> implementation: the cfg.toi that you supply before ft_freqanalysis is not
>>> going to have any effect if you use ‘mtmfft’ as a method, since this method
>>> just provides a single estimate of the spectrum using the whole ’trial’ for
>>> the estimation.
>>>
>>> > 2) I notice that wPLI values are way lower for low-frequencies (4-7hz)
>>> than for higher-frequencies (8-12hz and 15-30hz). While this could be a
>>> real effect associated with my task, the fact that this result is
>>> consistent across different conditions makes me wonder whether I've done
>>> something wrong in the ft_freqanalysis configuration.
>>>
>>> I think that this is just a property of the data.
>>>
>>> Best wishes,
>>> Jan-Mathijs
>>>
>>>
>>> >
>>> > Thanks a lot in advance for any help anyone can provide!
>>> >
>>> > -----------
>>> >
>>> > cfg = [ ];
>>> > data = ft_preprocessing(cfg,rwdata);
>>> >
>>> > %resample data
>>> > cfg = [ ];
>>> > cfg.resamplefs = 250;
>>> > data = ft_resampledata(cfg, data);
>>> >
>>> > data =
>>> > struct with fields:
>>> >
>>> > fsample: 250
>>> > trial: {1×117 cell}
>>> > time: {1×117 cell}
>>> > label: {100×1 cell}
>>> > cfg: [1×1 struct]
>>> >
>>> > % next, call the ft_freqanalysis function in our source data
>>> > cfg = [ ];
>>> > cfg.output = 'fourier';
>>> > cfg.method = 'mtmfft';
>>> > cfg.taper = 'dpss';
>>> > cfg.foi = linspace(4,30,30);
>>> > cfg.tapsmofrq = 4;
>>> > cfg.toi = 0:.02:1.5; % try 0:.02:.7 and .7:.02:1.5
>>> > tf_data = ft_freqanalysis(cfg,data);
>>> >
>>> > tf_data =
>>> > struct with fields:
>>> >
>>> > label: {100×1 cell}
>>> > dimord: 'rpttap_chan_freq'
>>> > freq: [1×30 double]
>>> > fourierspctrm: [4563×100×30 double]
>>> > cumsumcnt: [117×1 double]
>>> > cumtapcnt: [117×1 double]
>>> > cfg: [1×1 struct]
>>> >
>>> > % estimate wPLI values
>>> > cfg = [ ];
>>> > cfg.method = 'wpli_debiased';
>>> > connect_data = ft_connectivityanalysis(cfg,tf_data);
>>> >
>>> > connect_data =
>>> > struct with fields:
>>> >
>>> > label: {100×1 cell}
>>> > dimord: 'chan_chan_freq'
>>> > wpli_debiasedspctrm: [100×100×30 double]
>>> > freq: [1×30 double]
>>> > cfg: [1×1 struct]
>>> >
>>> > Best,
>>> >
>>> > Sergio.
>>> >
>>> > _______________________________________________
>>> > fieldtrip mailing list
>>> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>> >
>>> https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!v6GcyYsHF6VUmzXm8BB3M6rFfwWnSYCxD7hg5IzSXjBU2SvnlyfRyykO5BhpyzahCLvCtBzdjU2HPc4$
>>>
>>>
>>>
>>> _______________________________________________
>>> fieldtrip mailing list
>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>> https://doi.org/10.1371/journal.pcbi.1002202
>>> <https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!usewI1PbndK5LPja3Ngfqvfn3tRpdRV73OimKW6NrcohdNrX6G3vkgQuzYR9QRioc7pHSLvRNfscdfs$>
>>>
>> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>
> https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!usewI1PbndK5LPja3Ngfqvfn3tRpdRV73OimKW6NrcohdNrX6G3vkgQuzYR9QRioc7pHSLvRNfscdfs$
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20210923/c63d643b/attachment.htm>
More information about the fieldtrip
mailing list