Dear All,
Do you know whether we can compute a single (brain) or 2 compartment BEM (brain/CSF) for Ecog applications with OpenMEEG functionality. If not directly, can we trick it by giving equal conductances for outer compartments with the 3 layer BEM provided? Anyone has some experience with it?
Thank you
octavian
Dear Dr Lie,
Alex forwarded me this message from the Brainstorm user forum. I’m one of the senior developers of OpenMEEG (at Inria, France), and glad to see that OpenMEEG is triggering your interest.
ECoG has been implemented in OpenMEEG just recently (so recent that it’s not documented yet and it’s not integrated in Brainstorm) but in a model in which the CSF is neglected: the ECoG grid is assumed to be very close to the inner skull surface, which is the innermost surface in the 3-layer BEM model, and we neglect the CSF conductivity.
If you want to try this one out, I can show you how to (but outside of Brainstorm).
If you want to explore incorporating CSF some more work has to be done, which I think I see how to do.
But first you should try out how OpenMEEG handles your model with CSF, for EEG, to check that the meshes are correct, etc.
There is no problem for OpenMEEG to handle more than 3 layers.
Best regards
Maureen Clerc
Thank you, Francois,
2 related questions:
a) I was suggested by OM team to save BEM meshes generated by Brainstorm as .tri files to be further imported in OM for BEM generation (ecog not implemented yet in Braistorm). Are these tri files saved in mm, CTF coordinates, or both, and how do I export them to Matlab?
b) related to a: I have a list of electrode coordinates (vertex RAS coodinates, generated in Freesurfer). I want to import them in Brainstorm, and save them in the same coordinate system as the tri files above (or do the transform in Matlab). Can you provide the transform for the tri files (original surfaces are also Freesurfer RAS).
I would appreciate your insight with this.
Best Regards,
Octavian
All the files that are passed to OpenMEEG are saved to your user folder: $HOME/.brainstorm/tmp/*.tri
You can start the OpenMEEG computation from the Brainstorm interface, then copy the files from this folder (they are deleted when the OpenMEEG process is done).
Alternatively, you can convert a Brainstorm .mat surface to an OpenMEEG .tri file using the function out_tess_tri.m:
out_tess_tri( BstFile, OutputFile, 1)
The .tri files do not have to be in any particular coordinates system, they just need to be coherent with the dipoles locations (openmeeg_dipoles.txt) and the electrodes positions (openmeeg_loc_eeg.txt).
When exported from Brainstorm, the position of the vertices is just converted to millimeters, but they are still in Brainstorm/CTF/SCS coordinates system.
Note that the position of the electrodes are not saved in a .tri file (which include faces), but in a regular text file with just lists of x,y,w coordinates.
Converting from the FreeSurfer coordinates system requires the MRI, as show in the lines 84-92 in file in_tess.m
Cheers,
Francois
Dear Francois,
Thank you for the prompt info, as always.
Thank you,
Octavian.
a) Oops, I’m sorry, I read my code a little too fast…
Yes, you’re right, for the OpenMEEG .tri files, the values stay in meters. The only thing that changes is the indices of the faces ([1,N] in Brainstorm, [0,N-1] in OpenMEEG).
b) Start by creating a file similar to what you want from the Brainstorm interface.
Francois
Dear Francois,
Another question about BEM, excuse its basic attribute. Say I have 124 channels in the channel file matching the number of channels in the EEG file.
If on inspection of the tracings I see some channels are bad, and mark them as bad, then I create the BEM, do the bad channels still figure as sensors in the BEM (are they still maintained in the channel file, then ieeg). If they are, does this matter in how the BEM performs (I assume not, but please confirm). In other words, do I have to exclude the bad channels manually by editing the channel file before the BEM creation, or not?
I assume not, since different channels may be bad in different epochs and I do not imagine creating BEMs for every epoch, please comment.
Thank you,
Octavian.
The forward model is independent from the list of bad channels, as is consider each channel independently. We calculate the influence that the sources activity would be on each sensor.
The list of bad channels is only taken into account when calculating the inverse model: at that point, only the good channels are selected and kept in the model.
Dear Francois,
I have BST installed on a PC, and the full/ latest OM code/package on a linux to calculate the ecog BEM (not yet implemented in BST). I want to import the ecog BEM into BST for source localization.
To summarize, I generated BEM meshes in BST (1922 vertices each for inner and outer skull meshes, and 812 for skin, with a higher no for the inner boudaries since electrodes are snapped to the inner skull). I followed your instructions and initialized BEM from BST to obtain the tri, cond, geom, and txt files (ecog and dipoles coordinates), extracted them from the .brainstorm mp and went ahead and computed the gain matrix on the linux box. All went well thus far.
I then wanted to compute the regular BEM (h2em) in BST, so that I then can export the headmodel_surf_openmeeg.mat from the gui into matlab, and replace the EEG gain with the ecog gain file computed on the linux machine. However, my PC crashed while trying the compute the regular BEM, probably due to the high no of vertices selected.
Questions:
In this circumstances, can I compute a regular (EEG) BEM in BST (on my PC) using less vertices, but same ecog and source space (ecog electrode locations and dipole txt files), then replace the obtained gain with the gain matrix already calculated in linux with the higher no of vertices? In other words, does BST use just the gain matrix, ecog locations and source space files to calculate the inverse solutions, where the headmodel_surf_openmeeg is just a wrapper, or the other files need to be in accord as well?
If the BEM models in BST and on linux have to be the same (except the gain file to be replaced), I will have to settle for a smaller no of vertices (higher for inner skull, lower for the skin). There is a comment in BST GUI that for optimal performance, the no of vertices outer skull= no of vertices inner skull. Is this a requirement for the BEM ecog as well, or can I select a smaller no of vertices for the outer skull (say 2000 inner, 800 outer, 800 skin); is there a certain proportion among the no of vertices selected for the BEM meshes for an “optimal” BEM performance?
Related somewhat: calculating the regular BEM in BST with the default no of vertices (624, 624, 1000) works well on my PC, so om_load_full function is used somehow, however, I could not find in the matlab file, or elsewhere on my computer, so it must be embedded in one of the exe OM binaries which were downloaded when I first calculated an OM BEM in BST. How can I use it as standalone when trying to read the ecog gain matrix in matlab?
Thank you,
Octavian.
Hi Octavian,
Brainstorm just needs the Gain matrix. You can compute the initial Brainstorm forward matrix the way you want (other models), but with the same sensors and the same source space.
Then in the Brainstorm headmodel file, you just need to change the fields Gain (replace with your own gain matrix) and the field EEGMethod (replace with ‘openmeeg’)
For the details about the BEM surface: ask on the OpenMEEG side
om_load_full: The code is at the end of the bst_openmeeg.m function
We are still wondering why you got those pathological results with OpenMEEG, we cannot reproduce this behavior. Could you send me (FTP or dropbox) the anatomy of the subject + the OpenMEEG (bug) and 3sphere (working) head models? So we can investigate what the problem is…
If it’s not too big, the easiest way is to right click on the subject node > File > Export subject.
Thanks
Francois
Dear Francois,
I only had problems with OM BEM calculation vis BST on my PC, and only when selecting a high no of vertices (1922, 1922, 842). I do not have this issue with smaller no of vertices, such as 1422, 1422, 1082 and less. So I assume this is a memory issue of my PC, and not a BST/OM problem. I can get BEM models with high no of vertices on my linux box using the OM command line fine.
On a related issue I could not get too much tutorial on, after calculating the sources for a given EEG, I have the option to simulate the model, which returns a simulated EEG tracing. What should I do with it, other than interpreting it visually for goodness of fit with the original tracing? Also, can we do souce simulations in Brainstorm (placing source dipoles as point sources or cortical patches and evaluating the inverse solution maxima/spread from the locations of the simulated sources?).
Thank you,
Octavian.
Can you please me the subject for which you got those problems anyways? It would help us understand the bug.
You can use simulated EEG to evaluated the model. You can export to Matlab the original EEG and the simulated EEG (ie. what is explained by the model), and calculate an error metric of your choice.
About the simulation: http://neuroimage.usc.edu/forums/showthread.php?974-Sources-simulations&p=4134
Francois
Dear Francois,
I realize that the vertices of the BEM meshes generated in BST differ in coordinates from the original BEM surfaces imported from MNE. I verified this by displaying pairs of images (say MNE outer_skull_surface and BST’ bem_outerskull_1922V, for example) in the same view, or after exporting coordinates in matlab; so BST’s BEM surface creation is not a simple downsampling of the original meshes, I understand it as the meshes fed to OpenMeeg have to be nonintersecting, which is not true with the MNE meshes. It seems that the differences in coordinates affect more the skull layers, as opposed to the skin. So while the relatioship between scalp sensor coordinates and skin does not change from the original surface to the BST’s BEM skin mesh, this is not true if using ecog electrodes snapped to the inner skull, as in my case. The snapping algorithm works with FS or MNE meshes, so I either have to transform the BST’s bem_innerskull_1922v to a FS or MNE surface which can be fed to the algorithm before OpenMEEG BEM creation, or I have to multiply the channel coordinates to a transform matrix (from MNE surface to BST innerskull BEM surface).
Is either doable, do you have other suggestions?
Thank you,
Octavian.
Indeed, the BEM surfaces generated with Brainstorm and MNE are totally different. They are generated based on a very different, and for different application. Indeed, the Brainstorm ones are aimed to be compatible with OpenMEEG, not the MNE ones.
If you already have the MNE BEM surfaces, you don’t need to calculate the Brainstorm ones. Just set properly the type of each layer with the database explorer (inner skull, outer skull, scalp), and just run the head model computation with OpenMEEG. You don’t need to do (as shown in the tutorial) the “Generate BEM surfaces”. This is only in the case were you don’t have any other surfaces, and it doesn’t use the existing inner and outer skull surfaces, it just generates new ones.
Can’t you just use the MNE surfaces?
What is this snapping algorithm doing?
Dear Francois,
Projecting my ecog electrodes on the BST bem_innerskull_1922V mesh: I found a way to do it in matlab, I can run the snapping code (uses CT artifacts as base to mark electrode positions, then snaps them onto the preoperative MR& surfaces) in debug mode using the BST mesh vertices and faces variables. So all is well.
I wanted to calculate a BEM model with the BST-based OpenMeeg binaries using MNE generated meshes… I downsampled the meshes to 1082 skin, 1922 outer and inner skull, respectively, like I would do when calculating BST bem meshes… I ran OpenMeeg in BST… I got the following error:
** Error: OpenMEEG error #1:
** om_assemble version 2.1.0 (799) compiled at Aug 17 2011 20:27:19
**
** | ------ om_assemble
** | -HM
** | C:\Users\ovl.brainstorm mp\openmeeg.geom
** | C:\Users\ovl.brainstorm mp\openmeeg.cond
** | C:\Users\ovl.brainstorm mp\openmeeg_hm.bin
** | -----------------------
** Read name: C:\Users\ovl.brainstorm mp\openmeeg_2.tri
** Read name: C:\Users\ovl.brainstorm mp\openmeeg_3.tri
** Read name: C:\Users\ovl.brainstorm mp\openmeeg_1.tri
** Sorted List : 1 0 2
** Sorted Domains : Brain Skull Scalp Air
** Total number of points : 4929
** Total number of triangles : 9846
** Checking
** Mesh 0 : internal conductivity = 1 and external conductivity = 0.0125
** Mesh 1 : internal conductivity = 0.0125 and external conductivity = 1
** Mesh 2 : internal conductivity = 1 and external conductivity = 0
** triangles 175 and 219 are intersecting
** triangles 390 and 832 are intersecting
** !!!
** !!! WARNING !!!
** !!!
** Mesh is self intersecting !
** Mesh Info :
** # points : 1923
** # triangles : 3842
** Euler characteristic : 2
** Min Area : 5.05958e-007
** Max Area : 0.000105678
** Self intersection for mesh number 0
** !!!
** !!! WARNING !!!
** !!!
** 2 meshes are intersecting !
** Mesh Info :
** # points : 1923
** # triangles : 3842
** Euler characteristic : 2
** Min Area : 5.05958e-007
** Max Area : 0.000105678
** Mesh Info :
** # points : 1923
** # triangles : 3842
** Euler characteristic : 2
** Min Area : 2.03883e-007
** Max Area : 0.000538496
** !!!
** !!! WARNING !!!
** !!!
** 2 meshes are intersecting !
** Mesh Info :
** # points : 1923
** # triangles : 3842
** Euler characteristic : 2
** Min Area : 5.05958e-007
** Max Area : 0.000105678
** Mesh Info :
** # points : 1083
** # triangles : 2162
** Euler characteristic : 2
** Min Area : 2.06077e-006
** Max Area : 0.000405814
** triangles 234 and 890 are intersecting
** triangles 234 and 2045 are intersecting
** triangles 234 and 2046 are intersecting
** !!!
** !!! WARNING !!!
** !!!
** Mesh is self intersecting !
** Mesh Info :
** # points : 1083
** # triangles : 2162
** Euler characteristic : 2
** Min Area : 2.06077e-006
** Max Area : 0.000405814
** Self intersection for mesh number 2
**
Fortunately, the routine got past the initial steps, so the .tri files were in the tmp folder. I imported them in the OpenMeeg per se on my linux box, and I had no problem and no error in getting the leadfield matrix, which then I imported into BST and all went well.
About the error, I checked the OpenMeeg forum, and it seems the error occurs when using older binaries and regards coplanar triangles. It looks that Maureen has updated the github code (I have the latest version on my linux box, so I could compute the BEM). It looks that the BST OpenMeeg binaries have to be updated for (some) MNE meshes to be used directly for BEM calculation… I hope this helps,
Octavian.
Thanks for the update
I will ask Alexandre if we can get newer binaries for Brainstorm.
Francois