cfg.channel needed?

Robert Oostenveld r.oostenveld at FCDONDERS.RU.NL
Wed Feb 22 10:50:06 CET 2006


Hi Tom,

The default for freqanalysis is cfg.channelcmb='all', which means all-
with-all. If you do cfg.channel='MEG' in preprocessing and use the
default in freqanalysis, you'll hence get MEG-with-MEG.
Alternatively, preprocessing with cfg.channel='all' should also work
and you should be able to get MEG-with-MEG using cfg.channelcmb as
you have specified it.

I am not sure what the problem is in your case, but I can explain
what is happening: The idea is that sourceanalysis (and the
underlying prepare_freq_matrices) should not make assumptions on the
configuration that was used in freqanlysis, but has to rely on the
output freq structure. Freqanalysis computes powsctrm and crsspctrm
seperately and store them in arrays. To prevent excess memory use,
only one copy of each channel combinations is strored (i.e. ch1-ch2,
but not ch2-ch1). When you do sourceanalysis (which triggers
prepare_freq_matrices ), a selection along the time and frequency
dimension is made. In the nchanXnchan CSD matrix that is constructed,
the powspctrm should be on the diagonal and the crsspctrm should be
assigned to both off-diagonal sides of the CSD matrix. This is a
large reshuffling of numbers coming from the two (pow/csspctrm)
arrays. Since there is no guarantee that all elements of the CSD
matrix can be found somewhere in either of the arrays, the CSD matrix
is first filled with nans and then all elements that can be found are
copied in. If, at the end, there is still a nan somewhere in the CSD
matrix, then that means that the output of freqanalysis was not
complete enough for sourceanalysis. See prepare_freq_matrices lines
147-175.

I hope that this provides enough information for you to find the
underlying problem in your case.

Robert

PS The code is not very readible, and is pretty old. I would
implement it differently (although with the same basic idea) if I had
to do it again. All the string comparisons between all channel
combinations make it very slow. I would now do it using the cmb2label
and label2cmb subfunctions that are currently only used inside the
prepare_timefreq_data function.



On 21-feb-2006, at 15:41, Tom Holroyd wrote:

> Hi; just exploring some of the recent changes, I noticed that if
> you let cfg.channel default in preprocessing, you'll get all the
> channels, MEG + junk, as expected.  But then if I'm doing cross-
> power and specify channel combinations of all MEG by all MEG,
> strange things happen.  I get an error saying "The cross-spectral-
> density matrix is not complete" from prepare_freq_matrices().  This
> is because there are more channels in cfg.channel than in the csd
> matrix.  I was thinking it might be nice for it to default to only
> the channels specified in the csd, but it looks like there's too
> much going on previously, and it's better to use cfg.channel in
> preprocessing.  But the error message could be nicer.
>
> If you leave the call to channelcombination() out, that is, omit
>     cfg.channelcmb = channelcombination({'MEG' 'MEG'}, data.label);
> from freqanalysis(), does it default to 'all' by 'all' so that if
> you said
>     cfg.channel = { 'MEG' };
> to preprocessing() you'll get 'MEG' by 'MEG'?
>
> Basically I just want to ask if cfg.channel is now more-or-less
> required to preprocessing()?
>
> Thanks
>
> Dr. Tom Holroyd
> The 9th Amendment of the U.S. Constitution:
> "The enumeration in the Constitution, of certain rights, shall not be
> construed to deny or disparage others retained by the people."
>



More information about the fieldtrip mailing list