Back to the main page.
Bug 1870 - ft_datatype_sens flags planar gradient data as inconsistent
| Status | CLOSED FIXED |
| Reported | 2012-12-05 14:45:00 +0100 |
| Modified | 2012-12-31 11:46:24 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2012-12-05 14:45:28 +0100
Run test script test_ft_megplanar to reproduce. The failure occurs with the following grad (sens) structure: sens = coilpos: [1184x3 double] coilori: [1184x3 double] tra: [296x1184 double] label: {296x1 cell} chanpos: [148x3 double] chanori: [148x3 double] unit: 'cm' cfg: [1x1 struct] type: 'bti148_planar' chantype: {296x1 cell} chanunit: {296x1 cell} because size(sens.chanpos,1) ~= length(sens.label) (ft_datatype_sens, line 159). The correct solution is not immediately apparent to me. One option: check whether grad type is planar, if so, make the check 2*size(sens.chanpos,1) ~= length(sens.label) ?
Jörn M. Horschig - 2012-12-05 14:48:02 +0100
not sure if this will always work, e.g. when reference sensors are present which were not transformed maybe, if planar then do not check this?
Robert Oostenveld - 2012-12-05 17:42:10 +0100
>> test_ft_megplanar Error using ft_datatype_sens (line 164) inconsistent number of channels in sensor description Error in ft_compute_leadfield (line 107) sens = ft_datatype_sens(sens); Error in ft_megplanar (line 204) lfnew = ft_compute_leadfield(pos, planar.grad, vol); Error in test_ft_megplanar (line 46) data5 = ft_megplanar(cfg, data); where sens = coilpos: [1184x3 double] coilori: [1184x3 double] tra: [296x1184 double] label: {296x1 cell} chanpos: [148x3 double] chanori: [148x3 double] unit: 'cm' cfg: [1x1 struct] type: 'bti148_planar' chantype: {296x1 cell} chanunit: {296x1 cell} this is inconsistent in more than one way. I have created a separate test script with a small piece of data. mac001> svn commit test_bug1870.m Adding test_bug1870.m Transmitting file data . Committed revision 7108.
Robert Oostenveld - 2012-12-05 21:32:34 +0100
I tracked it down, it had to do with the rarely used sourceproject method for ft_megplanar, which makes use of the private/constructplanargrad function to craft a planar gradiometer array. This was implementedin 2004, well before we started considering to process non-ctf data. However, the bug also applies to CTF and had to do with chanpos not representing both planar channels, but only for one axial channel. Idem for ori. mbp> svn commit private/constructplanargrad.m Sending private/constructplanargrad.m Transmitting file data . Committed revision 7111.
Robert Oostenveld - 2012-12-05 22:06:43 +0100
I also made some other cleanups mbp> svn commit forward/ft_apply_montage.m Sending forward/ft_apply_montage.m Transmitting file data . Committed revision 7112. mbp> svn commit forward/ test/ ft_*m Sending ft_combineplanar.m Sending ft_megplanar.m Sending test/test_bug1870.m Transmitting file data ... Committed revision 7114. the specific test script now runs fine.
Robert Oostenveld - 2012-12-05 22:16:35 +0100
removed the requirement for neighbours in the sourceproject method mbp> svn commit ft_megplanar.m Sending ft_megplanar.m Transmitting file data . Committed revision 7115.
Robert Oostenveld - 2012-12-05 22:24:05 +0100
test_ft_megplanar runs through until line 151, where a plot is made. ft_topoplotER does not seem to like the single-valued input. This is due to avgFIC.mat containing a single-value timelock structure. To me this seems a matter for another bug... closing this one!