Back to the main page.
Bug 3144 - ft_checkdata_sens returns error when using MEG structs that worked fine last week
| Status | CLOSED FIXED |
| Reported | 2016-06-13 14:43:00 +0200 |
| Modified | 2018-05-08 14:30:14 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P5 critical |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Maarten - 2016-06-13 14:43:59 +0200
Hi, I tried to execute my script just now, and it didn't work. I receive the following error: Error using ft_datatype_sens (line 282) unexpected channel unit "" in channel 117unexpected channel unit "nknown" in channel Error in ft_datatype_freq (line 118) freq.grad = ft_datatype_sens(freq.grad); Error in ft_checkdata (line 223) data = ft_datatype_freq(data); I think it is no longer recognizing my data-struc as containing channel-labels. I don't know whether something recently changed? I have attached a file that will produce the same error, with the following code: % enter correct path to file "data.mat" here load('~/maarten/matlab/scripts/temp/data.mat'); ft_checkdata(data); I'm really sorry if this turns out to be on my end, rather than yours, but I couldn't find anything, and none of my MEG data is working anymore. Best, Maarten Edit: Woops forgot the attachment
Maarten - 2016-06-13 14:50:47 +0200
I can't add the struct because of filesize, but for those at the Donders, it is currently at: H:\common\temporary\4bugzilla\data.mat Also, I made a typo in the title: I meant ft_checkdata, and specifically ft_datatype_sens. Mondays.... ;)
Jan-Mathijs Schoffelen - 2016-06-13 14:52:32 +0200
I don't have permission to read the data. Please put it on /home/common/temporary
Maarten - 2016-06-13 14:56:25 +0200
Oh, I thought that's where I put it. Under 4bugzilla. Put it in the /home/common/temporary/data.mat now as well. Does load('home/common/temporary/data.mat'); or load('home/common/temporary/4bugzilla/data.mat'); ft_checkdata(data); not work? Anyhow, I think it results from the same bug as #3143 reported just before (Which I missed. Sorry).
Maarten - 2016-06-13 14:57:56 +0200
... sorry, I could edit my comments I would: load('/home/common/temporary/4bugzilla/data.mat'); is what I meant.
Jan-Mathijs Schoffelen - 2016-06-13 15:00:05 +0200
So this is another occurrence of the (recently introduced: see bug 3143 for instance) attempt to more explicitly require the sensors in the grad array to have correct physical units. Apparently, this needs to be thought through a bit more, because the code should not start failing.
Jan-Mathijs Schoffelen - 2016-06-13 15:00:31 +0200
No need to apologize :o)
Jan-Mathijs Schoffelen - 2016-06-13 15:02:14 +0200
I guess the issue is that your data is planar gradient combined TFR data, which was computed on 3D order gradient balanced component-rejected data.... In other words: even I wouldn't know what the correct unit of the channels now would be...
Jan-Mathijs Schoffelen - 2016-06-13 15:03:05 +0200
As a workaround for now you could try and remove the grad-field from your data structure before proceeding to your next analysis step
Maarten - 2016-06-13 15:32:02 +0200
Ah, yes, that seems to work. I don't know about the units either ;). Thanks!
Robert Oostenveld - 2016-06-14 17:17:01 +0200
for reference, I did > cp data.mat /home/common/matlab/fieldtrip/data/test/bug3144.mat I see that it contains >> data.grad ans = chanpos: [302x3 double] chanori: [302x3 double] chantype: {302x1 cell} chanunit: {302x1 cell} label: {302x1 cell} unit: 'cm' which is (as already commented by JM) remarkably similar to one I just encountered in bug 3143 by Nick (now CC). We could also consider that the "chanpos" style sensor description should be supported by ft_datatype_sens as well. It could not be used by any (forward) computation, but can for plotting and neighbors. E.g. we could consider that our sensor descriptions are either grad (only coilpos, coiloir, label, tra) elec (only elecpos, label, possibly, tea) opto (something similar as above) or grad+chanpos elec+chanpos opto+chanpos or simply only chanpos
Maarten - 2016-06-17 17:05:53 +0200
Hey, I can't get passed ft_rejectcomponent by deleting the grad structure. I get the error in the description whether I remove it or not. I call ft_rejectcomponent(cfg,ica,meg), and I have tried all combinations of deleting the grad field (remove it in ica but keep in in meg, remove in both, etc.). Any clues on how I can convince fieldtrip to work as it did before?
Robert Oostenveld - 2016-06-20 09:30:25 +0200
I have replaced the error by a warning. It should be updated on /home/common/matlab in 15 mins or so. mac011> git commit -a [master f5ff9cf] FIX - use warning instead of error in case of unknown chantype. This is less strict than desired, but a.o. needed to deal with data structures that have been ICA cleaned. See http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3144 1 file changed, 42 insertions(+), 43 deletions(-) mac011> git push upstream master X11 forwarding request failed on channel 0 You're about to push master, is that what you intended? [y|n] y Counting objects: 4, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 939 bytes | 0 bytes/s, done. Total 4 (delta 3), reused 0 (delta 0) To git@github.com:fieldtrip/fieldtrip.git 899b0ea..f5ff9cf master -> master
Robert Oostenveld - 2016-06-20 09:33:36 +0200
(In reply to Robert Oostenveld from comment #12) mac011> git commit -a [master 32a794f] ENH - added test script for http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3144 1 file changed, 13 insertions(+) create mode 100644 test/test_bug3144.m
Weiyong Xu - 2016-06-21 16:48:36 +0200
Hi Robert, I got a similar error to this BUG: Reference to non-existent field 'tra'. Error in ft_datatype_sens (line 292) coil = find(abs(sens.tra(i,:))~=0); Error in ft_datatype_timelock (line 102) timelock.grad = ft_datatype_sens(timelock.grad); Error in ft_checkdata (line 229) data = ft_datatype_timelock(data); Error in ft_combineplanar (line 318) data = ft_checkdata(data, 'datatype', 'timelock'); Error in AV_APV_light (line 209) timelock_cgra_A = ft_combineplanar(cfg, timelock_gra_A); I did ICA artifact rejection and then try to combine planar gradient using ft_combineplanar().
Robert Oostenveld - 2016-06-21 16:50:33 +0200
(In reply to Weiyong Xu from comment #14) could you share the input cfg and data that you are passing into ft_combineplanar?
Weiyong Xu - 2016-06-21 17:20:48 +0200
I uploaded the data to: https://www.dropbox.com/s/36egh22lnvy38l7/timelock_gra_A.mat?dl=0 the cfg is a empty configure as : cfg=[]; timelock_cgra_A = ft_combineplanar(cfg, timelock_gra_A);
Robert Oostenveld - 2016-06-22 09:07:00 +0200
(In reply to Weiyong Xu from comment #16) for reference, I did mac011> cd /home/common/matlab/fieldtrip/data/test/ mac011> cp ~/Downloads/timelock_gra_A.mat bug3144b.mat there was already the first bug3144.mat file, which I renamed to "a". I will add it to the test script and see what is wrong.
Robert Oostenveld - 2016-06-22 12:51:32 +0200
mac011> git commit -a -m "ENH - improve combined planar MEG sensor handling, see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3144" [master 882dba3] ENH - improve combined planar MEG sensor handling, see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3144 15 files changed, 232 insertions(+), 143 deletions(-) this resolves the concrete error. I think we still have an issue with the sensor representation not meeting the expectation. In this last case it was because of combineplanar, elsewhere because of ICA cleaning. I expect this to re-surface, but it is difficult to deal with it (except for simply discarding sensor information in case the updating of the sensor array fails).
Robert Oostenveld - 2017-01-17 11:29:44 +0100
closed multiple bugs that were resolved some time ago
Eelke Spaak - 2018-05-04 13:45:21 +0200
The warning that is now raised in ft_datatype_sens line 266 (e.g. 'Warning: unexpected channel unit "unknown" in channel 186') can be quite annoying. ft_datatype_sens is always called by ft_checkdata in case a grad/elec is present in the data, and many functions always call ft_checkdata (sometimes several times). Data that has been e.g. cleaned using ICA will have no grad.chanunit anymore, and will therefore always trigger this warning. Since the warning text additionally contains the channel index, the warning will be triggered num_chan times per call to ft_checkdata. Proposed solution: simply remove the warning. If we really need a unit in the data, check this outside ft_checkdata/ft_datatype_sens. Or perhaps add a flag to ft_datatype_sens like 'requireunit' or so.
Eelke Spaak - 2018-05-04 14:00:16 +0200
(In reply to Eelke Spaak from comment #20) I now read in ft_datatype_sens that chantype and chanunit are required. Am I correct in asserting that the units of an ICA decomposition are the same as the original data (e.g. T)? Then we could just add this info to the grad in ft_componentanalysis. (Though maybe it depends on the type of component analysis being performed.)