Back to the main page.
Bug 1309 - Cannot determine geometrical units of volume conduction model
| Status | CLOSED FIXED |
| Reported | 2012-02-02 12:20:00 +0100 |
| Modified | 2012-06-12 12:59:26 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 blocker |
| Assigned to: | Cristiano Micheli |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1306 |
- 2012-02-02 12:20:59 +0100
After updating FieldTrip from 11 January to 31 January the dipole fitting holds on a error: Error using ft_convert_units (line 78) cannot determine geometrical units of volume conduction model Error in ft_prepare_sourcemodel (line 255) sens = ft_convert_units(sens); Error in ft_dipolefitting (line 330) grid = ft_prepare_sourcemodel(tmpcfg); Error in dipool (line 25) dipolen = ft_dipolefitting(cfg, data.mmn); I am using as configuration the included templates: cfg.elec = ft_read_sens('standard_1020.elc'); cfg.vol = ft_read_vol('standard_bem.mat'); I reduced it to the problem that the type of the electrode model equals 'ext1020' and the script gets stuck in trying to compare this type of electric model with types of volume conducting models, like 'dipoli'. Earlier this was never a problem.
Boris Reuderink - 2012-02-02 14:59:03 +0100
Dear M. Koeneman, Could you make a minimal example script to reproduce this problem? That would simplify finding the cause for this issue. Best regards, Boris
- 2012-02-02 15:29:03 +0100
Thank you for the response. cfg = []; cfg.elec = ft_read_sens('standard_1020.elc'); cfg.vol = ft_read_vol('standard_bem.mat'); cfg.grid.resolution = 3; cfg.model = 'regional'; cfg.latency = [0.14,0.17]; cfg.numdipoles = 1; dip = ft_dipolefitting(cfg, timelock_data); timelock_data label: {31x1 cell} avg: [31x500 double] time: [1x500 double] fsample: 500 dimord: 'chan_time' cfg: [1x1 struct] Best regards, Mats
Boris Reuderink - 2012-02-03 11:25:23 +0100
I can indeed confirm this bug in SVN revision 5232 with the script presented below. -- clear all; ft_defaults; % artifically create timelock data timelock_data.fsamepl = 500; timelock_data.dimord = 'chan_time'; timelock_data.time = zeros(1, 500); timelock_data.avg = zeros(31, 500); for i = 1:31 timelock_data.label{i} = sprintf('label%d', i); end cfg = []; cfg.elec = ft_read_sens('standard_1020.elc'); cfg.vol = ft_read_vol('standard_bem.mat'); cfg.grid.resolution = 3; cfg.model = 'regional'; cfg.latency = [0.14,0.17]; cfg.numdipoles = 1; dip = ft_dipolefitting(cfg, timelock_data);
Boris Reuderink - 2012-02-03 11:37:35 +0100
Probably someone else should handle this bug.
Robert Oostenveld - 2012-02-06 15:43:14 +0100
(In reply to comment #3) This particular example script causes a correct error message, because there is no overlap in channels. Subsequently it cannot determine the geometrical units of the channels. >> timelock_data.label ans = Columns 1 through 12 'label1' 'label2' 'label3' 'label4' 'label5' 'label6' 'label7' 'label8' 'label9' 'label10' ... >> cfg.elec.label' ans = Columns 1 through 16 'LPA' 'RPA' 'Nz' 'Fp1' 'Fpz' 'Fp2' 'AF9' 'AF7' 'AF5' 'AF3' 'AF1' 'AFz' 'AF2' 'AF4' ...
Robert Oostenveld - 2012-02-06 15:53:12 +0100
(In reply to comment #5) doing timelock_data.label = cfg.elec.label(1:31) before the dipolefitting call fixes the problem of having no sensors. Then it becomes clear that ft_voltype(obj) returns ext1020, which is obj.type. However, it is not a type of volume conductor. It is a type of the sensor array. Had ft_voltype returned unknown, then the units would have been correctly estimated further down in the code. What needs to be done is to improve the flow of the logic in ft_convert_units. Instead of type = ft_voltype(obj); if ~strcmp(type, 'unknown') switch type ... it should do elseif ft_voltype(obj, 'infinite') ... elseif ft_voltype(obj, 'singlesphere') ... i.e. include the handling of a volume conduction model in the same if-elseif-elseif chain as the handling of ft_senstype.