Back to the main page.
Bug 2399 - ft_datatype_sens fails as of today (29-nov-2013)
| Status | CLOSED FIXED |
| Reported | 2013-11-29 16:12:00 +0100 |
| Modified | 2014-02-24 10:56:30 +0100 |
| Product: | FieldTrip |
| Component: | forward |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2013-11-29 16:12:31 +0100
At some revision since 8875, my calls to ft_sourceanalysis fail, with the following error: Error using ft_datatype_sens (line 361) inconsistent number of channels in sensor description Error in ft_checkconfig (line 243) cfg.grad = ft_datatype_sens(cfg.grad); Error in ft_preamble_trackconfig (line 31) cfg = ft_checkconfig(cfg, 'trackconfig', 'on'); Error in ft_preamble (line 54) evalin('caller', ['ft_preamble_' cmd]); Error in ft_prepare_sourcemodel (line 118) ft_preamble trackconfig Error in ft_sourceanalysis (line 333) grid = ft_prepare_sourcemodel(tmpcfg); There were quite a few commits since 8875, so I have not yet investigated what causes the error, in the hope that someone will recognize this. I did notice two things: in ft_datatype_sens, in revision 8755, size(sens.chanpos,1) is different from numel(sens.label) and some other fields (causing the error), and, for some reason, sens.chanpos contained non-NaN values, whereas they are NaN in my original data (ICA-->rejectcomponent was used).
Eelke Spaak - 2013-11-29 16:19:57 +0100
NOTE: in the last paragraph of my previous comment, I meant that in the *newest* revision (8924) this inequality holds and the NaNs are gone from chanpos, in 8875 this is still OK. Robert? JM? You two seem to have a lot of commits since yesterday afternoon. For now I have just rolled back to 8755 and everything works again, so for me there's no hurry (but maybe some DCCN people are encountering this).
Jan-Mathijs Schoffelen - 2013-11-29 16:47:54 +0100
Some more specifics would be helpful here. I.e. a grad structure that causes trouble and some more specifics as to how it was created. Is the inconsistency only present within the function, or does an inconsistent gradiometer structure enter the function Most of my commit yesterday were just cosmetic changes.
Robert Oostenveld - 2013-11-29 17:03:31 +0100
ah, this is my change "inconsistent number of channels in sensor description". The code that calls channelposition expects all channels in the output, so any occurrence of this is a potential bug. That is why I changed it (temporary) in an error. It should not happen, so the code needs to be fixed so that all channels are returned (as a nan if needs be). Please change the error at the end in channelposition back into a warning, but do give me the input to ft_datatype_sens/channelposition that causes it!
Jan-Mathijs Schoffelen - 2013-11-29 17:08:14 +0100
mooi verborgen in een rookgordijn van commits ;-). Maar in ieder geval is mijn lokale FT-versie weer bijna in sync met svn...
Eelke Spaak - 2013-11-29 17:15:52 +0100
(In reply to comment #3) I'm not entirely sure I understand your comment Robert. After a bit of debugging, I found out that the problem seems to happen at the level of ft_sourceanalysis. At line 286 a sens is taken from a call to prepare_headmodel, and this one is wrong: K>> sens sens = balance: [1x1 struct] chantype: {273x1 cell} chanunit: {273x1 cell} coilori: [546x3 double] coilpos: [546x3 double] coordsys: 'ctf' label: {273x1 cell} tra: [273x546 double] type: 'ctf275' unit: 'm' chanpos: [301x3 double] chanori: [301x3 double] even though both cfg.grad and data.grad (identical in this case) are correct: K>> cfg.grad ans = balance: [1x1 struct] chanori: [301x3 double] chanpos: [301x3 double] chantype: {301x1 cell} chanunit: {301x1 cell} coilori: [594x3 double] coilpos: [594x3 double] coordsys: 'ctf' label: {301x1 cell} tra: [301x594 double] type: 'ctf275' unit: 'm' See https://dl.dropboxusercontent.com/u/4023322/data-bug2399.mat (10MB) for a cfg and tl input for ft_sourceanalysis, which will generate the error. (En inderdaad JM, lekker rookgordijn :) Fijn weekend voor nu. Of tot vanavond natuurlijk, bij het grote feest!)
Robert Oostenveld - 2013-11-29 20:54:29 +0100
(In reply to comment #5) > I'm not entirely sure I understand your comment Robert. Oh, I now see that I did not yet commit the change of the warning into the error. I had doubts about it, hence your report immediately triggered me to think it was this change. But then it is another related change (nevertheless my fault).
Robert Oostenveld - 2013-11-29 21:14:32 +0100
I fixed it. mbp> svn commit test/test_bug2399.m forward/ Sending forward/ft_apply_montage.m Sending forward/ft_prepare_vol_sens.m Adding test/test_bug2399.m Transmitting file data ... Committed revision 8925.
Robert Oostenveld - 2013-12-02 09:11:29 +0100
I have reverted part of the change in commit 8922 and 8925. Rather than recomputing the channel positions for MEG, I keep the selected channel positions. That is much cheaper and less error-prone than recomputing them. They are still recomputed for EEG. mac001> svn commit forward/ test/ Sending forward/ft_prepare_vol_sens.m Sending test/test_headmodel_localspheres_new_old.m Transmitting file data .. Committed revision 8928. This is only marginally related to this bug, but the thought was triggered by it.