Issue forward modelling with OpenMEEG BEM

Bugs
, , ,
1

Hi everyone!

I would like to create a forward model using the BEM approach, but i'm having a problem...

I start by loading the "Colin27" template (Same issue with ICBM152), and then I generate three BEM surfaces. I load manually my signals and I mark as "Bad channels" those that I don't want to use (EEG and other channels). Finally I will take 160 out of 224 channl. I'm using a Yokogawa 160 channel system.

I click on my channel file and "Create a forward model" using OpenMEEG, with the following configuration...

Captura

...and I obtain this error:

Unable to perform assignment because the size of the left side is 160-by-45006 and the size of the right side is 320-by-45006.

Error in bst_openmeeg (line 458)
Gain(OPTIONS.iMeg, : ) = om_load_full(meggain_file);

Error in bst_headmodeler (line 470)
[Gain, errMessage] = bst_openmeeg(OPTIONS);

Error in panel_headmodel>ComputeHeadModel (line 647)
[OPTIONS, errMessage] = bst_headmodeler(OPTIONS);

Error in panel_headmodel (line 27)
eval(macro_method);

Error in panel_protocols>TreeHeadModel (line 1159)
[OutputFiles, errMessage] = panel_headmodel('ComputeHeadModel', iChanStudies);

Error in panel_protocols (line 44)
eval(macro_method);

Error in tree_callbacks>@(h,ev)panel_protocols('TreeHeadModel',bstNodes) (line 2344)
gui_component('MenuItem', jPopup, , 'Compute head model', IconLoader.ICON_HEADMODEL, , @(h,ev)panel_protocols('TreeHeadModel',
bstNodes));

I have no idea of how to solve it... I have tried this in two different computers, with the same error... Maybe a problem with the channel file? I'm attaching it.

https://drive.google.com/file/d/1wi-APPE2qmmhAX38LQfs4aTHKtNqdyyT/view?usp=sharing

Thank you all in advance!

PS: The computers have enough space on disk and 64GB RAM

2

Hi Victor,

  1. The .pos file you sent is empty. Can you please share with us the channel.mat file from the Brainstorm database, to check if we can reproduce this on our end?
  2. Do you get the same error if you use lower number of points for the BEM surfaces (eg. 642/482/482)?
  3. Can't you see any other warning or error message immediately before this one in your command window?
  4. What OS and Matlab versions are you using?

@Alexandre @sik There are similar unresolved issues that were discussed previously, maybe this is related to one of them:

Cheers
François

3

Hi!

Thank you for your reply. I have read all the threads that you show me, but I haven't find a solution.

  1. My channel file is here (sorry for the previous file):
    https://drive.google.com/file/d/17vTYjPNMmAWmc65ld8uj332iY-tNaCdU/view?usp=sharing

  2. Yes... Im getting the same error. I dont think that is a memory issue (1TB free space of storage, 64GB RAM)

  3. All the errors/warnings obtained are those that I put in the first post.

  4. I have tried on Win x64, Mac and Linux.

Also, I have find something that should be mentioned.
By surfing in the code, I have find that when calling OpenMEEG BEM, a .squid file is generated. This file has 320 lines (2 lines for each sensor, based on the first element of each row, that is a number, there are two 1, two 2... and two 160). I think that the problem appear when generating this file. It prints 2 lines per sensor (Two different positions for each sensor, I dont know why), and probably, in the next steps OpenMEEG detects the 320 lines as 320 different sensors:
https://drive.google.com/open?id=1v3jpZqA9klzYf3MLJApw3MVbFvhkbz8u

Thank you very much for your help!!!

4

Thank you for the file and for helping with the debugging.
We will look at this in the next few days.

What version of Matlab are you using?

5

Are the Yokogawa sensors gradiometers? If so the two positions are for the two coils per sensor. That part is normal. What could be missing is combining the 320 coil solutions back into 160 channels.

6

Thank you Francois!

In all my devices Im using MATLAB 2018a

7

Yes! My sensors are gradiometers!

You are right, probably the problem is when combining the sensors.

Thank you very much!

8

I found out that OpenMEEG 2.4 does not behave as the previous versions. This causes all the sensors with multiple integration points not to be correctly handled in Brainstorm at the moment.
I opened an issue on the OpenMEEG github for trying to solve this issue:

In the meantime, use of the overlapping spheres model instead. Note that this is the model we recommend for MEG instead of the OpenMEEG BEM:
https://neuroimage.usc.edu/brainstorm/Tutorials/HeadModel#Forward_model

9

Side question: why do you convert your data with SPM before importing it in Brainstorm?
You should avoid this step and link directly your continuous Yokogawa recordints to the Brainstorm database. Otherwise, it leads your recordings not to be correctly handled as Yokogawa files in Brainstorm, it impacts various computation and display features.

10

While many consider spheres to be good enough, BEM shouldn't be discouraged since it is more accurate. Going to spheres adds an error on the order of 10% to the forward solution. (shameless self-reference)

11

Oh okay, so there is the error. Thank you!!!!

I need a BEM model because I want to apply the SOUND algorithm (MutanenNI2018) to clean the MEG signals, and this algorithm performs greatly better when using a BEM model. Could I use OpenMEEG 2.3 in order to get a BEM forward model or I will obtain the same error?

The doctors that are sharing the MEG data with me give me the SPM converted data. I ask them for the Yokogawa files, but they contain information from the patients, and should be annonimized, so they prefer to send me the SPM files (that have been alredy anonimized). Do you think that is mandatory having the Yokogawa files? I can ask for them again, but maybe is trouble for the doctors to process them to remove the patients information.

Thank you again!

12

True!

Also, in some cases a BEM model is almost mandatory,it depends on the analyses that you are going to perform later!

However, probably, for the majority of the users, Overlapping Spheres could be more than enough!

Thanks!

13

I see... It's a bit sad if the Yokogawa software doesn't include a program to anonymize the recordings.
Just keep in mind that the processing and display of the MEG recordings won't be optimal because of this initial limitation.

14

this PR https://github.com/brainstorm-tools/brainstorm3/pull/183 should fix the pb. I am in the mean time trying to avoid breaking backward compatibility in openmeeg but at least this should help brainstorm users.

sorry for this

Alex

1 Like
15

@VictorRodriguez
Thanks to the reactivity of the OpenMEEG team, we already have a solution for this bug:

Menu Update > Update Brainstorm, then try again.

1 Like
16

Thank you! Problem solved!!

Thank you very much :slight_smile:

17

Hi again, and sorry for asking you once again.

I was worndering what you exacly mean when you say that when using the converted SPM files "the processing and display of the MEG recordings won't be optimal because of this initial limitation".

How could this issue affect my results exactly? Would the changes in the processing and display caused by using the SPM converted files be significant?

Thanks again!

18

When importing directing from the native MEG format (Yokogawa, Elekta...), Brainstorm has access to the precise geometry of each type of sensor. Each gradiometer is modeled by 8 integration points, and each magnetometer with 4 integration points, to compute a forward model with a higher accuracy. The forward model is computed for each integration point, and then averaged per sensor.
To get an illustration, go back to the introduction tutorials, right-click on the channel file > Edit channel file, and see the number of location/orientation columns you have per sensor:

image
image1341×299 12.9 KB

When importing from a SPM .mat/.dat file, this information is not available. SPM already decided that gradiometers would be represented by one point only, and gradiometers by two points (one for each coil, at the center of the coil). Right-click on your channel file > Edit channel file, you should see a maximum of 2 location and 2 orientation columns.

How much overall precision do you lose because of this: I have no idea. Maybe not much, but we haven't quatified this formally.

--

Another slightly annoying display limitation is that the device not being identified, there is not correct display of the MEG helmet in the 3D views.
image
This is something you can fix manually with the following procedure:

  • Rename the channel from the Brainstorm database explorer (ie. change the comment of the file) to: "KIT channels"
  • Rename the channel file from your file explorer (ie. the actual file name) to: "channel_kit.mat"
  • Right-click on folder > Reload
19

Okay!!

Thank you very much for yout help!!! :grin::grin::grin: