Back to the main page.

Bug 2883 - error('fixme: reorder data fields to match');

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
Depends on:
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 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 = []; = 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

Jan-Mathijs Schoffelen - 2016-02-24 09:25:32 +0100

I consider this fixed right now, at least due to lack of activity in this bug it does not seem to be an urgent issue anymore. In the light of recent code changes, and explicit channel order checks I am not sure how 'real' this issue still is. I suggest to close, and reopen if need arises.