[GSOC] Store multivariate connectivity filters #192
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
One requirement of the decoding module we will introduce in the GSoC project is access to the multivariate filters, which are currently computed in the connectivity estimator class, but never stored. Discussed in more detail in #182.
I thought submitting this as a separate PR from the wider decoding module would help keep diff size small and make reviewing the changes easier.
Solution
Add a
filters
attribute to the multivariate connectivity estimator classes similar to the existingpatterns
attribute.However, since this will only be required in the case of the connectivity estimator being used in the decoding module (not with
spectral_connectivity_epochs/time()
functions), also add astore_filters
flag which is by defaultFalse
.mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 197 to 202 in fc7e2a7
When
store_filters=True
, thefilters
attribute will be set as a placeholder array where filters can be stored (again, similar to howpatterns
works), however whenFalse
,filters
will remain asNone
to reduce memory usage.mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 220 to 223 in fc7e2a7
It would be sufficient to pass
store_filters
to the_MultivariateCohEstBase
estimator class and have thefilters
attribute there, however I have passedstore_filters
to the parent_EpochMeanMultivariateConEstBase
class and have thefilters
attribute here. This keeps things in line with thepatterns
attribute which is also currently only used for daughters of the_MultivariateCohEstBase
, but this may not be the case in the future if other filter-based non-coherency methods are implemented, so this approach is more flexible and forward-looking.mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 103 to 119 in fc7e2a7
Other than that, it's a very simple case of just storing the filters when appropriate.
MIC
mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 474 to 476 in fc7e2a7
CaCoh
mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 672 to 674 in fc7e2a7
Since
store_filters
is by defaultFalse
, no behaviour has been changed. Since this is also an internal feature there are no new unit tests to add at this stage (would all come when the decoding module is implemented proper).Other points
When implementing this, I also realised it was also possible to refactor the
reshape_results()
method in the multivariate connectivity estimator classes which were separately implemented for the coherency and Granger methods but doing the same thing, so that has been cleaned up.mne-connectivity/mne_connectivity/spectral/epochs_multivariate.py
Lines 182 to 189 in fc7e2a7