[BUG] Enable averaging connectivity over tapers instead of averaging PSD over tapers

[adam2392]

As of v1.0 MNE-Python, there was a bug fix to not average the tfr in multitaper analysis unless the user specified. So using that in mne-connectivity, we need to compute the power in multiple tapers, and then compute connectivity and then average across tapers.

I see. Thanks for this comment. Perhaps that is why there are some issues in #73

Originally posted by @adam2392 in #82 (comment)

[adam2392]

@Div12345 and @Avoide

mne-connectivity/mne_connectivity/spectral/time.py

Lines 269 to 282 in 711ccce

	# get the supported connectivity function
	conn_func = {'coh': _coh, 'plv': _plv, 'sxy': _cs}[method]
	# computes conn across trials
	# TODO: This is wrong -- it averages in the complex domain (over tapers).
	# What it *should* do is compute the conn for each taper, then average
	# (see below).
	if collapse is not None:
	out = np.mean(out, axis=collapse)
	this_conn = conn_func(out, kernel, foi_idx, source_idx, target_idx,
	n_jobs=n_jobs, verbose=verbose, total=n_pairs)
	# This is where it should go, but the regression test fails...
	# if collapse is not None:
	# this_conn = [c.mean(axis=collapse) for c in this_conn]

These lines possibly are contributing to the discrepancy we see. Before, we were averaging multi taper analysis across tapers before we computed connectivity. We should instead be computing connectivity for all tapers and then averaging.

[Div12345]

@adam2392 Is there a regression test that already covers this? Because I commented out 276,277 and uncommented 281,282 and all tests seem to pass.. If not, I could try writing a regression test and checking it out..

[adam2392]

No unfortunately there is not. The issue that made it not a "trivial fix" is that the conn_func needs to be applied for each taper, but right now the API doesn't support doing something like that.

I would first identify what pieces of code need to change and propose a quick pseudocode here to see if it makes sense.

[ruuskas]

I'm currently working on this issue and probably have already solved it, barring testing.

[adam2392]

Sure sounds good! @ruuskas lmk if there's a PR you would like help iterating on. I can suggest help for testing if needed.

[ruuskas]

Sure @adam2392 , I would like some help with the upcoming PR. I'm in the process of making the API more similar to spectral_connectivity_epochs and also fixed the issue with PLV computation, mentioned in #90 and #73.

[adam2392]

Awesome excited to see the PR! Feel free to start it early as a "WIP" Draft.

[ruuskas]

@adam2392 I have submitted the PR. Could you have a look when you have time?

[ruuskas]

Hi @adam2392, @larsoner. I came back to this after finding some quite peculiar behaviour with the connectivity function. Are you sure that this conclusion is correct?

 # TODO: This is wrong -- it averages in the complex domain (over tapers). 
 # What it *should* do is compute the conn for each taper, then average 
 # (see below). 

I did some testing with this, and the connectivity results do not appear smooth at all. See plots below. Most importantly, there's a dip in connectivity at 10Hz, which is the only actual coupling frequency in the simulated data. Morlet convolution for comparison.

These were computed with the implementation found in #104.

I'm just guessing, but perhaps the cross-spectral density should be averaged and connectivity computed from that instead of averaging connectivity matrices? I will go through the code tomorrow to check for other potential bugs that could cause this.

[larsoner]

Are you sure that this conclusion is correct:

In principle yes it seems like a reasonable conclusion to me.

I agree that the first plot looks buggy, though -- I wouldn't expect it to look like that. Have you tried using multitaper with exactly one taper? That should look more like the morlet case. Then I'd try with one taper again, but this time just using the second taper instead of the first. (This will be a pain to code potentially but it should be doable.) Both of these should be smooth, similar to the Morlet case. If they are, the aggregate should also be smooth. From there you could use exactly two tapers (first and second) and see that the result is smooth. If it isn't, then it seems like there is some bug in the code that combines these values. If it is smooth, I'd gradually increase the number of tapers until I started seeing problems, then try to understand why they arise...