Back to the main page.
Bug 2883 - error('fixme: reorder data fields to match cfg.channel');
| Status | CLOSED WONTFIX |
| Reported | 2015-04-29 09:45:00 +0200 |
| Modified | 2016-05-06 07:49:53 +0200 |
| Product: | FieldTrip |
| Component: | inverse |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
- 2015-04-29 09:45:30 +0200
cfg = []; cfg.method = 'dics'; cfg.frequency = 25; cfg.grid = grid; cfg.vol = vol; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = 0; sourcePost_nocon = ft_sourceanalysis(cfg, freqPost); Within ft_sourceanalysis the error-message above occured. The data is a CTF 275 channel MEG recording. I will upload the corresponding matlab inputs.
Robert Oostenveld - 2015-05-05 10:21:43 +0200
Hi Esther, I look forward to receiving the mat file. If they are too large as attachment, please use one of the methods listed here http://www.fieldtriptoolbox.org/faq/how_should_i_send_example_data_to_the_developers best Robert
- 2015-05-05 12:51:16 +0200
Hi Robert, I had placed the .mat file on the ftp-server last week, when reporting the bug (bugreport_bug_2883). I also have send it now again. Thank you, Esther
Robert Oostenveld - 2015-05-05 13:02:16 +0200
(In reply to esther.florin from comment #2) thanks, I found it! For reference, I copied it to /home/common/matlab/fieldtrip/data/test/bug2883.mat
Jan-Mathijs Schoffelen - 2015-07-21 16:05:00 +0200
Hi Esther, What is it you want to do. I think the error is thrown to protect you against yourself, because the order of the channels in your data is different from the order of the channels in your pre-computed leadfields. Althought there seems to be some code in place (in ft_sourceanalysis) to match the channel order between data and precomputed leadfield, for some (no doubt valid) reason an error is thrown. How is it possible that the channel order in the data has been shuffled around? It looks as if your gradiometer array is 3d-order balanced, could this have led to a shuffled channel order?
Jan-Mathijs Schoffelen - 2015-07-21 16:14:09 +0200
I would ensure that the channel order is the same in both the data and the leadfields. For this I would re-order the channel order: % start from the time domain data, i.e. prior to calling ft_freqanalysis [a,b] = match_str(data.grad.label,data.label); tmpcfg = []; tmpcfg.channel = data.label(b); % this shuffles the labels according to grad.label, and keeps only the overlapping channels: if you need the EEGs as well, you have to add these to the list, think about whether you really need to keep the references (once your data is 3d-order balanced, you don't need them anymore). data = ft_selectdata(tmpcfg,data); % then do spectral analysis, where I recommend using cfg.output = 'fourier', rather than 'powandcsd'; % then pre-compute the leadfields, think about whether you need the leadfields to be computed for the reference coils as well: if your input gradiometer description is 3d-order balanced then the balancing is automatically applied to the leadfields. % then call ft_sourceanalysis. Could you provide some feedback as to whether this has worked?
- 2015-09-04 12:10:28 +0200
Hi, sorry for the delay. The fix works. I am not clear, why using the 3rd order gradient correction (recommended by CTF) produces this problem. I first thought this was due to the fact that the data set was rather old and there might have been changes in the way things are saved. However, I have now tried a newer data set (the auditory data set you used for the workshop together with the brainstorm team) and I get the same error. The order of the sensors is not really shuffled - the issue is that in one case the reference sensors are at the beginning and in the other at the end. I am not sure, why this is the case. Best wishes, Esther