Back to the main page.
Bug 2230 - ft_connectivity_granger/csd2transfer: redesign handling of blockwise and blockwise/conditional
| Status | CLOSED FIXED |
| Reported | 2013-08-01 13:20:00 +0200 |
| Modified | 2014-01-15 14:45:11 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2013-08-01 13:20:46 +0200
Right now, blockwise is dealt with in a different way than blockwise/conditional, which is a bit weird. for conditional we need to factorize the csd matrix a few times, once with all 3 blocks, and once with only 2 of the blocks (the third block consisting of the chunk of channels that is to be partialed out). Note that a 'block' can consist of just a single channel. for block we need only a specification of which channels belong to which block, but we need to factorize only once (the full matrix containing all channels). at the moment ft_connectivityanalysis behaves inconsistently, where cfg.block should contain different information when doing blockwise, compared to conditional (blockwise). proposed changes (not backward compatible): -cfg.conditional = 'yes' (was a 3-column matrix specifying in the first 2 columns the (directional) block-pair, and in the 3d column the block that is partialed out). It would be safe to assume that the user would want all block pairs (bi-directional) with all other blocks partialed out. This can be done automatically. -cfg.blockindx = nlabelx1 numeric, indexing the block to which each input channel belongs. If not specified, defaults to 1:nlabel (meaning that in case of conditional all channel pairs should be computed, partialing out the rest) (was a cell-array with in the first column the labels, and in the second the indices) -cfg.block = 'yes'/'no' (default: 'no') if cfg.blockindx is specified (and different from 1:nlabel). The following scenarios are possible: cfg.block='yes',cfg.conditional='yes' -> blockwise conditional cfg.block='no',cfg.conditional='no' -> blockwise conditional (where some blocks only have 1 channel) cfg.block='yes',cfg.conditional='no' -> blockwise (taken care of by ft_connectivity_granger) cfg.block='no', cfg.conditional='no' -> 'normal case' functions to be changed: ft_connectivityanalysis ft_connectivity_granger ft_connectivity_csd2transfer
Jan-Mathijs Schoffelen - 2013-08-01 13:38:06 +0200
hmm, the block thing may be solved more elegantly, when doing it cfg.neighbours style, i.e. provide a struct-array: cfg.block(i).name = 'name-of-block' cfg.block(i).label = {}; % containing the list of labels that belong to that block if cfg.block is not specified when cfg.conditional='yes', it defaults to: cfg.block(i).name = 'labelx'; cfg.block(i).label = {'labelx'}; etc.
Jan-Mathijs Schoffelen - 2013-08-07 16:27:16 +0200
bash-4.1$ svn commit -m "enhancement - updated experimental code pertaining to blockwise and blockwise conditional granger causality" ft_connectivityanalysis.m private/blockindx2cmbindx.m connectivity/ test/test_ft_connectivityanalysis.m Sending connectivity/ft_connectivity_csd2transfer.m Sending connectivity/ft_connectivity_granger.m Sending connectivity/private/blockwise_conditionalgranger.m Sending connectivity/private/sfactorization_wilson.m Sending ft_connectivityanalysis.m Adding private/blockindx2cmbindx.m Sending test/test_ft_connectivityanalysis.m Transmitting file data ....... Committed revision 8383.
Jan-Mathijs Schoffelen - 2013-08-07 16:28:08 +0200
Created attachment 500 testscript for connectivityanalysis
Jan-Mathijs Schoffelen - 2013-08-07 16:33:12 +0200
Andre, Please check out the last part of the testscript that I just attached. If you grab the latest version of Fieldtrip (through googlecode, or ft_version) then probably you can figure out how you can specify the cfg to do blockwise and blockwise conditional granger. On simple examples the conditional seems to work quite nice, although I don't understand really the blockwise (non-conditional) results too well. A lot of spurious things seem to go on there, even leaking to nodes that are essentially unconnected in the simulation. I checked and re-checked the code, but all seems OK. I noticed that the multivariate decomposition starts working pretty badly once too many channels are included. I won't favour averaging csd across channels within a ROI (because of polarity differences and/or because each ROI won't let itself be accurately described by just a single component). Perhaps projecting the N channels per ROI onto a lower dimensional subspace (e.g. do PCA on the time domain data and keep only the largest X components: take care not first to do the ft_channelnormalise in this case).