Back to the main page.

Bug 2817 - bemcp output not 'sensible'

Reported 2015-01-30 12:30:00 +0100
Modified 2019-08-10 12:43:53 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P5 normal
Assigned to:
Depends on:
See also:

Johanna - 2015-01-30 12:30:35 +0100

Created attachment 695 test_ft_headmodel_bemcp.m Hello, Even after a recent change by Robert to make sure that vol.mat of the output of 'bemcp' was not NaN (see also bug 1954), the resulting leadfields from a vol created with 'bemcp' (still?) don't look 'sensible'. (By 'sensible', I mean the typical dipolar patterns, as seen in output from concentricspheres or dipoli on same data). I created test_ft_headmodel_bemcp.m, committed to SVN and also attached here. I don't think it's a 'units' issue, as I tested 'mm', 'cm', and 'm'. Although clearly the 'correct' units should be used, it is not clear to me which are the 'correct' units for input to 'bemcp'. See also 'comment 10' of bug 1794.

Johanna - 2015-01-30 12:43:39 +0100

Related to this, the 'standard_bem' provided by FT is the output of 'dipoli'. It would be great if a 'standard_bemcp' could also be provided, against which future testing could be made.

Vladimir Litvak - 2015-01-30 14:55:49 +0100

(In reply to Johanna from comment #1) Hi Johanna, Could this be related to the recently fixed bug in prepare_vol_sens. I.e. if you did your prepare_vol_sens during the bug period (mid Dec to mid Jan), saved the result and using it now it could screw up the dipolar patterns. Vladimir

Johanna - 2015-01-30 15:24:57 +0100

(In reply to Vladimir Litvak from comment #2) Hi Vladimir, I don't think so, as in, I only started running/testing this code in the past week with an up-to-date FT version, and the test function I made calls the template files existing in FT already (computed much earlier than Dec 2014).

Robert Oostenveld - 2015-08-19 15:30:23 +0200

I came across this bug and test script and decided to clean it up a bit (as some aspects were not correct). I have not solved the issue yet, but the test script should now be more helpful in finding the solution. mac011> svn commit template/ test/test_ft_headmodel_bemcp.m Adding (bin) template/headmodel/standard_seg.mat Sending test/test_ft_headmodel_bemcp.m Transmitting file data .. Committed revision 10606.

Jan-Mathijs Schoffelen - 2019-03-28 15:38:50 +0100

This test script has been demoted to failed_ft_headmodel_bemcp I fixed it, and can confirm the 'not sensible' output. This is probably because bemcp is not robust enough against mesh-related issues (e.g. problems with local curvature estimation or almost touching boundaries). It was however decided with Robert over tea just now, not to prioritize this. Rather, we have a generic functioning implementation of openmeeg.

Robert Oostenveld - 2019-08-10 12:43:53 +0200

This closes a whole series of bugs that have recently been resolved (either FIXED/WONTFIX/INVALID). If you disagree, please file a new issue on