How to uniform list of channels

Discussions
1

Hi,

I’m having a trouble to uniform the channels across subjects.
Since some of the subjects had a different number of channels (e.g., 370, 371, 373, or 384), I can’t combine the subjects to create an average file.

Problem 1

For the subjects who had 60 EEG caps and MEG (370 vs. 371, vs. 373)

I tried: Run–> Standerdize --> Uniform list of channels

But then I got an error (please see attached file).

Problem 2

Although I got an error, they could uniform the channels for 10 out of 11 subjects (i.e., 370 channels). Thus I could make an average file of 10 subjects.
(the subject who had 373 channels gave me an error.)

Then I made an average file for other group who had 74 EEG caps and MEG (384 channels).

However, because of different number of channels between two groups (i.e., 370 vs. 384), I can’t open the average file which I created before the other group.
Please see the attached file “error message 2”.

Problem 3

For the subject who failed to uniform the channels, “MN: MEG ALL(Constr)” won’t open anymore.
Please see the attached file “error message 3”.

Since all the subjects have the same MEG channels, I tried to uniform the MEG channels across the subjects, but I got the same error message and I couldn’t open “MN: MEG ALL(Constr)” for all the subjects.

Could you please let me know how to fix these problem?

Thank you,

Miwako

2

Hi Miwako,

It looks like you used this procedure correctly.
Unfortunately I cannot tell why it crashed for one of the subject without having a look at your database or your data files. I don’t know what combination of input and output list of channels would not be handled by the process “Uniform list of channels”.

What I could suspect would be that the two acquisition runs in subject VTF had initially different numbers of sensors. If so, you should have configured your subject with the option (Default channel file: No).
In general, unless the runs have been registered to the same head position with some Neuromag tools (that we don’t trust so much) you should be using this option for all your subjects.

Can you try to reproduce this crash with two subjects (one that worked, one that didn’t work): create a new protocol, leave the anat to the default, create two subjects and import a few seconds of recordings in each one.
Then try to run the process again. If you get the same crash, please send me the two files you imported, together with a screen capture of the process option window.

Now, to fix the broken subject:

  1. if you have a recent backup of the database (which you should…), just replace the existing files with the backup.
  2. make sure that the none of the recordings files were modified (right-click on data file > File > View file contents, you should see the original number of sensors in the F matrix).
  3. in a new subject, import a small block of a recordings from subject VTF just to get a channel file, copy-paste the channel file to the broken subject
  4. if this sounds complicated to you or you are not sure of what you are doing, maybe it would be faster for you to delete and re-imported the subject that crashed.

Note for the future: always do a complete backup of your data before running this process, it can damage the data seriously if something goes wrong. And make daily automated backups of everything you re working on. Painful to set up, but worth it in the long run.

Please let me know how this goes.

Cheers,
Francois

3

Hi Francois,

Thank you for your reply.

>>What I could suspect would be that the two acquisition runs in subject VTF had initially different numbers of sensors. If so, you should have configured your subject with the option (Default channel file: No).

Yes, I did.

Before I created the scout etc (overlapping, noise covariance etc), there was no problem. MIT007_VFT = VFT_007B
Please see the attachment “global_common_files_Success”.
(Note: I hope this is not the problem for this problem, but just in case the filtering raw data were slightly different for this version vs. new version.
session1_tsss + session 2_tsss vs. session1_tsss + session 2_trans_tsss)

In addition, if the problem was something to do with “initially different numbers of sensors”, then why did it work for JPII_008B (who also had initially different numbers of sensors just like VFT_007_B).

HOWEVER, initially JPII_008B also gave me an error. I just kept re-run the same procedure for a few times, and SOMEHOW/Eventually?? brainstorm accepted JPII_008B in the averaged file.
So I simply thought this might be some sort of bug for brainstorm, but I tried to do the same thing for VFT_007_B for many times (I tried the same procedure from fresh start, but brainstorm somehow won’t accept VFT_007_B in the averaged file.)

>>Can you try to reproduce this crash with two subjects (one that worked, one that didn’t work): create a new protocol, leave the anat to the default, create two subjects and import a few seconds of recordings in each one.
>>Then try to run the process again. If you get the same crash, please send me the two files you imported, together with a screen capture of the process option window.

Pease see the attached files:

twoSubj_Error1 (I dropped the subject VFT_007_B first and then JPII_009_B)
twoSubj_Error2 (I dropped the subject JPII_009_B first and then VFT_007_B)
twoSubj_Error3 & 4: You can tell that the problem subject is VFT_007_B (i.e., scout is collapsed)

Now I tried the following.

Before, I did not include control subject (Control001~006) for uniforming the channels.
I tried to do it separately. But as I mentioned previous message, I couldn’t open the averaged file for both groups at the same time because the number of channels (384) and the data file (370) do not match. Control group had 74 EEG channels and others had 60 EEG channels. Because of that, I’m using their MEG data only for the analysis.

Thus, I tried to uniform the channels across all the subjects. So I did and got an error as you can imagine.

“uniform the channels” process: I got the same message as before. But “Neuromag channels” became 370 for all the subjects internally, just like before (please see error_A).

I tried to average all the subjects and see what happened. I got an error. Please see “error_ProcessAve”. Problem subjects were Control 002~006 and JPII_008B and VFT_007_B.
Control 001 was not in that list, but as you see “error_MN MEG ALL (Constr)”, Control001 is also a problematic subject.
But there is difference between Control 001 and “Control 002~006 & JPII_008B & VFT_007_B”.
Control 001 gave me only one error message while “Control 002~006 & JPII_008B & VFT_007_B” gave me two error message (please see error_1 and error_2). First error message is the same as Control001.

I tried to make an average file, one for control group and one for others. But each group gave me an error message. Please see error_B and error_C.

I can see the reason for JPII_008B and VFT_007_B as you know. But I don’t see the consistent reason for Control 001 vs. Control 002~006 since Control 001~006 had the same channels.

Please help.

Miwako

4

Since I couldn’t send all the attachments, I’m sending the rest here.

5

Hi Miwako,

I think that there is some confusion in the way you are using this process. The workflow is supposed to be the following:

  1. Start with a protocol where all the subjects are configured with the option “Default channel: NO, use one channel file per subject”.
  2. Link all the continuous files to the database, run the pre-processing operations you need on the continuous files.
  3. Import the epochs in the database
  4. Delete all the link to the continuous files (the number of channels cannot be modified in the FIF files)
  5. At this step you have one channel file per folder for all the folders of your database. Do NOT do any source analysis now.
  6. Do a backup copy of all the imported database
  7. Run the process Uniform list of channels
  8. now you can do your source analysis and your averages.

I’m sorry, it’s very difficult to follow those explanations and the successive steps without having the data in hand. I cannot help you fixing your existing database without sitting directly at your computer. And because the successive errors might be impossible to track and fix, it’s probably safer if you start over.

If you can find two FIF files that cannot be matched together (for which the process crashes), please send to me both files with a detailed notice explaining how to reproduce the bug from an empty database. Then I will work on fixing the bug.

Thanks,
Francois