[FieldTrip] LCMV giving conflicting results vs SAM and DICS

Tue Oct 29 00:02:25 CET 2013

Hi Eelke,
I have now run a test which I think does what you describe.
cfg.keeptrials='yes'  for the calls to ft_timelockanalysis and
ft_sourcenalysis that generate the filter.
cfg.keeptrials='no' for all the other calls to these 2 functions (those
that generate the 2 conditions to be compared).
The result is still the same (ie not what I would call the 'correct' one,
but rather what seems to be based on an evoked response covariance matrix).
I should stress again that how I set keeptrials in ft_timelockanalysis is
also how I set it for the "matched" call to ft_sourceanalysis (It didn't
seem to me that this matters anyway as unless cfg.rawtrial='yes',
ft_sourceanalysis handles both cases so that what is used further down is
the same but I may be wrong in this) .
Best,
Haris

Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych
University of Minnesota Dept of Neuroscience and Brain Sciences Center

On 28 October 2013 05:26, Eelke Spaak <eelke.spaak at donders.ru.nl> wrote:

> Hi Charidimos,
>
> If I understand you correctly, you specified cfg.keeptrials = 'no' in
> the calls to ft_timelockanalysis prior to the *first* call of
> ft_sourceanalysis, right? Could you try what happens when you specify
> it in ft_timelockanalysis prior to the second call to
> ft_sourceanalysis (so the step where the precomputed filter is
> applied)?
>
> Thanks,
> Eelke
>
> On 25 October 2013 01:06, Charidimos Tzagarakis <haristz at gmail.com> wrote:
> > Hi Eelke,
> > Thank you for looking into this!
> > The piece of code I commented out is indeed [790:836] (changing line 784
> > accordingly or alternatively adding a copy of 785-789 after 790).
> > I did try running ft_timelockanalysis with keeptrials='no' for all 3
> calls
> > and that resulted in the same behaviour as before for LCMV (ie not the
> > "correct" one). I also tried it   setting keeptrials='no' in
> > ft_sourceanalysis at the same time (ie keeptrials='no' for both
> > ft_timelockanalysis and ft_sourceanalysis) which had the same outcome (I
> > actually had run these tests before posting but wanted to 2ble check).
> > I may however be confused here because there are some other possible
> > combinations with keeptrials since for each subject there is a total of 6
> > calls to functions that accept it as an input and the filter is estimated
> > with only 2 of them.
> > Do let me know if there is another combination I should run and I will do
> > that.
> > Best,
> > Haris
> >
> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych
> > University of Minnesota Dept of Neuroscience and Brain Sciences Center
> >
> >
> > On 24 October 2013 03:08, Eelke Spaak <eelke.spaak at donders.ru.nl> wrote:
> >>
> >> Hi Charidimos,
> >>
> >> Thanks for your elaborate e-mail. We discussed this issue in
> >> yesterday's FieldTrip meeting. It is very reasonable that you expect
> >> the three methods to produce the same results, and the code/interface
> >> indeed suggests that this would be the case. In other words, we need
> >> to clean up this part of the code to produce consistent results;
> >> however, this might take a while.
> >>
> >> We believe the discrepancy is caused by the fact that you compute the
> >> covariance while specifying cfg.keeptrials = 'yes', which is
> >> unnecessary while computing the filter. This results in a covariance
> >> matrix with dimensions trial X channel X channel, which then is
> >> subsequently averaged over trials during ft_sourceanalysis. Likely the
> >> filter is still in fact computed on the averaged covariance, as it
> >> should be. However, the subsequent projection of data through the
> >> filter will not first average the covariance, and will in essence only
> >> project the first trial through the filter. (This is because the dip{}
> >> fields will be struct arrays of dimension nTrial X 1, and in an
> >> assignment a(1).b = 2; a(2).b = 3; x = a; then x will be 2, so
> >> everything but the first element of a struct array is ignored in an
> >> assignment statement.)
> >>
> >> Could you try to compute the covariance with cfg.keeptrials = 'no' and
> >> then run LCMV again? This will still compute the covariance on the raw
> >> traces, not on the average. If our hunch is right, you should get the
> >> correct results then.
> >>
> >> As said, this is indeed messy and unclear, our apologies for that.
> >>
> >> Finally, could you tell us what part of the code you commented out to
> >> make the results consistent? We suspect it will be between lines 790
> >> and 835, but it would be helpful to know for sure.
> >>
> >> Best,
> >> Eelke
> >>
> >>
> >> On 23 October 2013 21:43, Charidimos Tzagarakis <haristz at gmail.com>
> wrote:
> >> > Hi Don,
> >> > Thanks for your reply. I do agree that some of these beamformers
> >> > are probably better suited than others to study beta
> desynchronisation,
> >> > or
> >> > generally questions in the frequency domain. I in fact started from
> >> > DICS.
> >> > The reason I looked at LCMV and SAM is to be sure that I get
> consistent
> >> > results (and also because my experiment can also address some
> additional
> >> > time domain questions, so I wanted to see what happens when my data
> goes
> >> > from one to the other). I therefore tried to set them up so I that the
> >> > results from all 3 are similar. So you are correct in pointing out
> that
> >> > my
> >> > question is why SAM and LCMV produce different results. Based on their
> >> > description within the fieldtrip website and mailing list (if I have
> >> > interpreted these correctly) they should be treating the covariance
> >> > matrix
> >> > in the same way (to get a true evoked response covariance matrix you
> >> > would
> >> > normally need the extra call to ft_timelockanalysis that I show at the
> >> > last
> >> > piece of code in my post). Also , if the covariance matrix is indeed
> the
> >> > issue, it seems that the change in how it is treated in the
> >> > ft_sourceanalysis code (based on the "hack" I described) is unique to
> >> > LCMV
> >> > (none of the other beamformer options share that piece of code) and is
> >> > active only when LCMV is given a precomputed filter which is (I think)
> >> > unusual.
> >> > Hence my question!
> >> > Best,
> >> > Haris
> >> >
> >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych
> >> > University of Minnesota Dept of Neuroscience and Brain Sciences Center
> >> >
> >> >
> >> >
> >> > On 23 October 2013 13:31, Rojas, Don <Don.Rojas at ucdenver.edu> wrote:
> >> >>
> >> >> Haris,
> >> >>
> >> >> Sorry - In my last post, I mistakenly put DICS and the Fieldtrip
> >> >> implementation of SAM into the same frequency domain category. In
> >> >> Fieldtrip,
> >> >> SAM is a time-domain technique and is not the same as the
> >> >> implementation of
> >> >> SAM that has been used in the published literature for beta ERD. So,
> >> >> are you
> >> >> then wondering why the two time-domain approaches produce differing
> >> >> results?
> >> >> That probably does depend on how the covariance matrix is calculated.
> >> >> Although I still think it is a bad idea to use a time-domain
> beamformer
> >> >> on
> >> >> motor beta ERD/ERS.
> >> >>
> >> >> Best,
> >> >>
> >> >> Don
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> fieldtrip mailing list
> >> >> fieldtrip at donders.ru.nl
> >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > fieldtrip mailing list
> >> > fieldtrip at donders.ru.nl
> >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> >> _______________________________________________
> >> fieldtrip mailing list
> >> fieldtrip at donders.ru.nl
> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> >
> >
> >
> > _______________________________________________
> > fieldtrip mailing list
> > fieldtrip at donders.ru.nl
> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131028/ea657271/attachment.html>