Back to the main page.
Bug 2774 - OpenMEEG leadfield has erroneous sensor interpolations
|2014-12-05 18:57:00 +0100
|2015-02-11 10:40:52 +0100
Daniel Miklody - 2014-12-05 18:57:09 +0100Hello everyone! I've had some trouble figuring out what really went wrong: My leadfields for a 4-shell BEM got unstable, often changing polarity in the scalp potentials. The BEMs I first experienced this with were non star-shaped but then i managed to create a simple icosahedron642 with a small dent that had the same problem. This toy geometry was even star shaped. In the direction of the dent the leadfield would flip for some positions even deep within the "sphere". I first blamed OpenMEEG and found out that I get different leadfields on my linux versions, that weren't having these troubles but where having other troubles. In the end I found out that simply using OpenMEEG inert sensorinterpolation solves the issues. I don't know what exactly goes wrong but it must be in ft_prepare_vol_sens(..). Interestingly I haven't had these problems for 3-shells (even simply removing the outer layer of my 4-layer toy geometry and assigning standard 3-shell values banned the errors)... The difference between linux and win is due to an older version of fieldtrip on the linux. Still the windows version is up-to-date and produces the error. project_elec function is different on the older ft as far as I can see.. Maybe this is connected to the incorrect units problem in bug 2380?! My solution is, as I said, to simply use OpenMEEGs interpolation which works perfect. I can supply code for implementing this. Anyway thanks, guys, for this great toolbox in general! Daniel
Robert Oostenveld - 2014-12-08 09:49:00 +0100Hi Daniel, Thanks for the report. Could you provide a test script (with a small mat file with the data objects) that would allow me to reproduce the problem? I am not an openMEEG expert myself, so was not aware of the choice between having the interpolation done on the MATLAB or on the openMEEG side. I suppose it was implemented by default in MATLAB (ft_prepare_vol_sens) since the previous BEM models also had it there. Robert
Daniel Miklody - 2014-12-08 21:16:47 +0100Created attachment 683 Scalp Potential over sensor for same dipole in different lead fields
Daniel Miklody - 2014-12-08 21:17:59 +0100Robert, thank you for your reply. I have written a test script but I won't send it to you. Because it is emberassing! :D Sorry, but while creating it, I realized that it was my own fault! While reshaping the leadfields the dimensions got mixed up. I thought I had checked this. I obviously haden't. It was that in addition to that Alexande Gramfort told me he read about someone having different results between Win64 and Linux and my results were different on Linux than on Windows. I thought it was OpenMEEG causing the troubles, not realizing that the sensor interpolations were done within fieldtrip.. So never checked the ft version-no on the cluster. The dipole locations that caused trouble didn't make sense to me before, because I looked at the wrong locations (mixed up indeces). So thought deep whitin the brain something went wrong, although these where the points that where on the interfaces or outside... They of course can become unstable. Enough justifications for now! Sometimes it's a long journey to find out that a simple error in the beginning caused all that. Sorry for blaming fieldtrip. Sorry for blaming OpenMEEG in the past. So plese delete this bugreport. The results between using OpenMEEG's interpolation and your's differ in amplitude (rel MSE is 50%) but correlations are high (very close to 1).. Looking at the leadfield, I think this is due to the fact that fieldtrip uses a mean average reference while openmeeg just computes this as is. Thank you Daniel
Daniel Miklody - 2014-12-08 21:20:04 +0100Created attachment 684 Correlations between leadfields with sensor interpolation FT vs Openmeeg
Daniel Miklody - 2014-12-08 21:20:56 +0100Created attachment 685 MSE histogramm between FT vs openmeeg sensor interpolated leadfield
Daniel Miklody - 2014-12-08 21:23:35 +0100I guess this bug is resolved because it was not a bug but an erroneous script.
Robert Oostenveld - 2014-12-09 11:23:24 +0100(In reply to Daniel Miklody from comment #6) thanks for following up! I am glad that you were able to resolve it and that it was not a bug. Robert