Back to the main page.

Bug 1368 - leadfield normalization fails for openmeeg forward solution

Status CLOSED FIXED
Reported 2012-03-13 10:12:00 +0100
Modified 2012-06-12 13:00:18 +0200
Product: FieldTrip
Component: forward
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 minor
Assigned to: Cristiano Micheli
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2012-03-13 10:12:40 +0100

In case of openmeeg the high-level ft_prepare_leadfield will try to compute all leadfields with one call to the low-level ft_compute_leadfield function. The problem is that ft_compute_leadfield then does not know how to separate the leadfields of the individual dipole positions and will scale the concatenated leadfield matrix by a single number.


Robert Oostenveld - 2012-03-13 10:15:25 +0100

I have added the following to ft_prepare_leadfield to prevent people from getting incorrect leadfields at the moment. + if ~strcmp(cfg.normalize, 'no') + % See http://bugzilla.fcdonders.nl/show_bug.cgi?id=1368 + % + % The problem is that ft_compute_leadfield does not know how to + % separate the leadfields of the individual dipole positions and will + % scale the concatenated leadfield matrix by a single number. + error('leadfield normalization is currently not supported in combination with the openmeeg forward solution'); + end manzana> svn commit ft_prepare_leadfield.m Sending ft_prepare_leadfield.m Transmitting file data . Committed revision 5445.


Cristiano Micheli - 2012-03-21 14:50:45 +0100

(In reply to comment #1) Now the ft_compute_leadfield is able to manage the normalization of both single dipole leadfields and batch ones. A test script has been added to check for this functionality both qualitatively (the routine does not crash) and quantitatively, i.e. the Frobenius norm is 1. ( see FT/test/test_bug1368.m) The check is run both on vectorial lf normalization and column-wise normalization (resp. cfg.normalize='yes' and cfg.normalize = 'column')


Cristiano Micheli - 2012-03-21 15:02:13 +0100

(In reply to comment #2) resolved