Back to the main page.
Bug 2817 - bemcp output not 'sensible'
| Status | CLOSED WONTFIX |
| 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: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1954http://bugzilla.fcdonders.nl/show_bug.cgi?id=1794 |
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.