Back to the main page.

Bug 70 - rank-reduction of leadfield is not supported for openmeeg

Status CLOSED FIXED
Reported 2010-04-23 10:00:00 +0200
Modified 2012-06-12 12:58:40 +0200
Product: FieldTrip
Component: forward
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P2 normal
Assigned to: Cristiano Micheli
URL:
Tags:
Depends on: 1426
Blocks: 1414
See also:

Robert Oostenveld - 2010-04-23 10:00:10 +0200

somewhere around lne 450 in ft_compute_leadfield it states % optionally apply leadfield rank reduction if ~strcmp(reducerank, 'no') && reducerank<size(lf,2) && ~strcmp(ft_voltype(vol),'openmeeg') ... why should rank-reduction not be supported for openmeeg?


Alexandre Gramfort - 2010-04-25 17:54:58 +0200

yes it should be: if ~strcmp(reducerank, 'no') && reducerank<size(lf,2)


Alexandre Gramfort - 2011-06-15 15:15:04 +0200

I know I have been assigned this bug but I don't have commit rights on this part of the code.


Boris Reuderink - 2011-11-17 10:46:42 +0100

Changed the status of bugs without a specific owner to UNCONFIRMED. I'll try to replicate these bugs (potentially involving the submitter), and change confirmed bugs to NEW. Boris


Boris Reuderink - 2012-01-12 15:17:34 +0100

See forward/ft_compute_leadfield.m:445 in SVN revision 5104. Fairly easy fix apparently (I am running tests, so I can't change code right now).


Jan-Mathijs Schoffelen - 2012-01-27 08:34:04 +0100

assigned bug to get all bugs lined up before the grand bug binge


Cristiano Micheli - 2012-02-01 14:35:16 +0100

done!


Boris Reuderink - 2012-02-02 11:47:58 +0100

Fixed in SVN revision 5196. Closing this bug.


Robert Oostenveld - 2012-04-15 12:02:06 +0200

This bug has resurfaced after regression testing. See bug #1414 Looking at the test script, I see that it actually does not check for the computations being done correctly. I have changed the code into cfg=[]; % cfg.reducerank = 2; cfg.vol = vol; cfg.grid.pos = [0 0 .5]; cfg.elec = elec; lf = ft_prepare_leadfield(cfg); % use the defaults cfg.reducerank = 1; lf1 = ft_prepare_leadfield(cfg); cfg.reducerank = 2; lf2 = ft_prepare_leadfield(cfg); cfg.reducerank = 3; lf3 = ft_prepare_leadfield(cfg); assert(~isequal(lf1, lf2)); % these should be different assert(~isequal(lf1, lf3)); % these should be different assert(~isequal(lf2, lf3)); % these should be different assert( isequal(lf, lf3)); % these should be identical, i.e. the default should be rank 3 assert(size(lf,2)==3); assert(size(lf1,2)==3); assert(size(lf2,2)==3); assert(size(lf3,2)==3); assert(rank(lf)==3); assert(rank(lf1)==1); assert(rank(lf2)==2); assert(rank(lf3)==3); which should provide some safeguard against invalid rank-reductions. Since I am not able to execute the code, I am reopening this bug and assigning it to Cristiano.


Robert Oostenveld - 2012-04-15 12:03:36 +0200

(In reply to comment #8) this contains the enhanced tests: roboos@mentat001> svn commit test/test_bug70.m Sending test/test_bug70.m Transmitting file data . Committed revision 5621.


Cristiano Micheli - 2012-04-30 13:30:06 +0200

(In reply to comment #9) Now all assertions hold, apart the assert( isequal(lf, lf3)); Probably, due to how openmeeg generates the lead fields, a second calculation of the same leadfield is not perfectly identical to the first one (the numerical difference in minimal, inferior to eps, but anyway it's there!) Is there any random generated variable involved in the calculation of the lead fields? To overcome the problem I slightly changed the assertion into: assert( norm(lf-lf3)<eps); Alex, do you any idea why this happens?