Dear colleagues,
Because recently I found some strange result while I did not compute signal-space projection(SSP) at the beginning, I decided to re-analyze the data with SSP.
As my understanding from the Fig 3.1 of the manual (the workflow), the steps of mne_setup_mri, alignment, mne_watershed, mne_setup_forward_model are independent from the calculation of average and noise-covariance. On the other hand, it seems that only in the averaging and noise covariance steps I need to explicitly use the SSP, I thought I could do only the averaging and noise covariance calculation without the above steps, and use the bem and surface files generated in the last analysis to go on to mne_do_forward_solution and mne_do_inverse_operator. However, after I did these, in the mne_analyze interface, it did not allow me to view the source estimate on the surface (whenever I click on the timecourse manager window, it pops up to say "Surfaces do not match the source spaces. Cannot display estimates.") But when i click on the surface, the signal of that vertex can be displayed in the bottom-left window.
When I checked the log file of the outputs of the mne_do_forward_solution and mne_do_inverse_operator from the two times of analysis, it seems there are no difference except for the part of SSP and the SVD result due to that. All the correct files are used when I redo the analysis.
Does any one has a clue of what is the reason? And am I right that I do not need to redo those early steps if I only want to add SSP in my analysis?
As my understanding from the Fig 3.1 of the manual (the workflow), the steps
of mne_setup_mri, alignment, mne_watershed, mne_setup_forward_model are
independent from the calculation of average and noise-covariance.
correct.
On the
other hand, it seems that only in the averaging and noise covariance steps I
need to explicitly use the SSP, I thought I could do only the averaging and
noise covariance calculation without the above steps, and use the bem and
surface files generated in the last analysis to go on to
mne_do_forward_solution and mne_do_inverse_operator. However, after I did
these, in the mne_analyze interface, it did not allow me to view the source
estimate on the surface (whenever I click on the timecourse manager window,
it pops up to say "Surfaces do not match the source spaces. Cannot display
estimates.") But when i click on the surface, the signal of that vertex can
be displayed in the bottom-left window.
it means vertices in your source space are not present in the surface.
Are you sure you properly defined the SUBJECT and that you did not mess
with this part?
When I checked the log file of the outputs of the mne_do_forward_solution
and mne_do_inverse_operator from the two times of analysis, it seems there
are no difference except for the part of SSP and the SVD result due to that.
All the correct files are used when I redo the analysis.
SSP is independent of the source space and the forward operator.
So it is a bit weird.
Does any one has a clue of what is the reason? And am I right that I do not
need to redo those early steps if I only want to add SSP in my analysis?
that's right.
maybe you can share the lines you used in your analysis. We might be able
to spot a pb in your pipeline.
When I checked the log file of the outputs of the mne_do_forward_solution
and mne_do_inverse_operator from the two times of analysis, it seems there
are no difference except for the part of SSP and the SVD result due to that.
All the correct files are used when I redo the analysis.
SSP is independent of the source space and the forward operator.
So it is a bit weird.
As Alex said, SSP is independent from the source/forward calculations,
so SSP should not affect that. However, it sounds like you might also
be doing the inverse calculation (mne_do_inverse_operator). This step
will depend on the SSP because the inverse operator requires the noise
covariance matrix (which should have SSP applied to it).
Attached are my scripts. Usually what I do is first use mne_browse_raw to look at each epoch and remove the epochs that seem to have eye blinking in the event list. Then run meg_process1_2.tcsh which calls ave_cov_2.tcsh and meg_setup.tcsh. After that I align MRI and sensors in mne_analyze and then run meg_process2_2.tcsh. When I reanalyze the data, I commented out the meg_setup part and did not align. Just run meg_process1_2.tcsh and meg_process2_2.tcsh separately.
Each subject has a folder, in which MEG data are saved in a folder called meg, other folders are generated by freesurfer. When I run my script, I call a for loop to pass the subject id to the script as the first parameter. The environment variable SUBJECT is only set within the script, but not before I call the script. Could this cause problem?
Another question is, it seems to me that sLORETA is influenced by the number of trials while MNE is not (the sLORETA response of all trials is larger than that of every subset of the trials) . When you average across subjects, which one do you prefer to average?
Hi,
I wouldn't get a chance to go through your scripts but I'm attempting to
answer just the last question about #trials:
MNE is only weakly affected by the #trials especially when you have a
larger #trials to start with since it enters the calculation only as a
weighting between data fit and the prior (the norm penalty). Ultimately it
is in units of real current (nA).
dSPM and sLORETA on the other hand normalize the MNE further by the
estimated source noise variance and since that goes down with increase in #trials, one would expect the dSPM and sLORETA to sort of go up
proportional to sqrt(N) where N = #trials.
If the estimate of the noise covariance has converged and good (i.e large
degree of freedom), then I personally don't have a particular preferance
for MNE or dSPM when it comes to group level averaging since MNE is nA and
dSPM/sLORETA are z-scores (when source orientation is fixed apriori).
I don't find something obviously wrong in your scripts.
My only recommendation is to make sure that the source space that is
used to generate the forward and inverse solutions are the same and are
actually coming from the very same subject that you use in mne_analyze.
Hi Alex,
Thanks very much. I just read my log files again. And I think the possible reason is that I once used different way of naming the subject ID, and then I unified the way of naming and changed all the surface file names accordingly. Although the contents of the files are for the correct subjects, maybe there is still information in the file that reflects the previously used subject IDs. This did not cause problem in all the processing scripts but maybe mne_analyze checked for it. Good lesson for me to learn. And sorry for the time it takes you to help checking the scripts.