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