Transition Matrix Question

[Mattlab-hub]

Hello, I am trying to use the transition matrix on an MEG dataset in sensor space. However, when I plot it the matrix is very uniform. For 5 states, the Observed transition matrix all the cells revolve between 0.24-0.26. So when I move on to the Controlled transition matrix the whole matrix is pretty much washed out and looks like there are no real meaningful transition differences.

Is the above matrix abnormal and I should be concerned about something like data quality? Or is there a deeper issue such as this not being meant to be used on sensor space MEG data? Or is this a normal matrix for the most part? The microstates themselves look normal.

Best,
Matt

[vferat]

Hey Matt,

From what I understand, you've calculated the transition matrix using compute_transition_matrix (for which you observe values between 0.24 - 0.26).
Then you calculated the matrix you'd observe if you shuffled the data using compute_expected_transition_matrix.

Given the diagonal of 0, I assume you've set ignore_repetitions=True. A state can therefore transit to 4 other states (5 states - itself), which explains the transition probabilities of around 0.25 (1 chance in 4).

The figure in your previous post shows the difference between these two matrices ?

• If that's the case, then it shows that there's no particular structure in the recording, and that the transitions from one state to the other are rather random. But this should be tested using statistical test ( For example, the 2% difference between observed and expected transition probabilities from state 0 to state 1 could be an important effect given that the observed transition probability is around 25%.)

• if not, please correct me

[Mattlab-hub]

Hi @vferat, I did not explicitly set the ignore_repititions=True, but it looks like that is the default setting. And yes, I did as in the tutorial where I take the Observed and then the Expected, and then subtract those two to get the one above matrix.

And also yes, the Observed being around 0.25 for all states means there is no significant difference in transitions, so my data essentially transition like white noise, and that gives the matrix above where everything hovers really close to 0. I am going to do more statistical tests, but wanted to ask this because I am getting these washed out looking metrices for all the participants and even when I do microstates as a group. To further confirm this I tried two other MEG datasets and am seeing the same thing. However, when I switch to using this on EEG data, then I get more of what the tutorial looks like. So I was starting to get concerned that there is a reason why almost all MEG microstate studies are not done in sensor space (being that they are not truly averaged referenced or something like that).

[mscheltienne]

I'm not very knowledgeable on MEG microstates, but for MEG sensor space analysis between subjects and/or between recordings/sessions, you should transform all your recordings towards a common head position, or in other words, towards a common device to head transformation.
Was this the case on your datasets?

[Mattlab-hub]

Yes, actually, that is why I am stuck in sensor space. The HCP MEG messed up on the sensor coordinates and was not able to release the forward model to anyone but Fieldtrip. Unfortunately, due to dependency issues I could not get Fieldtrip running on my school's high performance computer system. So to make up for the bad coordinates I had to make one from scratch using the MNE Magnus Layout. So all participants use the same sensor layout head model.

I will say the matrix above is from an individual participant, but I get the same thing when I do group level analysis as well.

From what I have read, it seems most MEG microstates are found by first transforming the data to source space and then all microstate classes are found and segmentation is applied on that transformed data.

[mscheltienne]

Again, not familiar that much with MEG microstates or the HCP dataset.
You do have mne-hcp to interact with this specific dataset. MAybe @Shrecki might be able to give you some hints regarding this forward model.

Rergardless, I'm a bit skeptical with the methodology for MEG data.

• If you apply microstates analysis to source space data, you should apply it to comparable dataset. Meaning, the source space should be designed in the same way and the source estimate should be morph to a common head geometry, e.g. fsaverage. I guess through mne.compute_source_morph including the src_to argument.

• If you compare source space maps, they should be also compared on the same source space and head geometry. Is their any litterature converging towards common source space maps?

• If you apply microstates analysis to sensor space data, you need to first transform the signal towards a common head position. Imagine that participant 1 has the head tilted on the left, and participant 2 has the head tilted on the right, the topographic maps of the sensor level activity will be completely different since the sensors position are fixed. I'm not sure what the MNE Magnus Layout is, but an mne.channels.Layout is just a common 2D representation of the sensor geometry. It includes no information about the head position within this sensor position, i.e. it includes no information of the device to head transformation. I would recommand to apply SSS to those dataset (see mne.preprocessing.maxwell_filter and the argument destination which you could set to (0, 0, 0.4) to get a default head position).

[Mattlab-hub]

Yes, I have used mne-hcp and there is even a warning about the location issue on their page. I misspoke, The layout is bad, and the dig file in epochs.info['dig'] was absent, at least in the minimally preprocessed data. With help on the mne form I was able to apply the correct swap of axis and apply a general dig file to get things where they should be, but with a standard dig file stored by MNE for the Magnus system.
Also, that is the case from what I have seen. Newer papers make an effort to control for such spatial differences. Unfortunately I am at the end of my studies and need to finish my dissertation so I doubt I will have the time anymore to fix the data further and bring it into source space. So, I am going to stick in sensor space if I can, or find another dataset that does not have this transition matrix issue.

This is specifically what I did to get the layout and dig information into each participant:
`# apply correct layout
for ch_idx in range(len(epoched.info['chs'])):
current_pos = copy.deepcopy(epoched.info['chs'][ch_idx]['loc'][:2])
epoched.info['chs'][ch_idx]['loc'][0] = current_pos[1]*-1
epoched.info['chs'][ch_idx]['loc'][1] = current_pos[0]

set DIG with Magnes 3600wh sensor loc for

bti_path = op.abspath('/N/u/mne-python-main/mne') + '/io/bti/tests/data/'
raws = {'Magnes 3600wh': read_raw_bti(op.join(bti_path, 'test_pdf_linux'),
op.join(bti_path, 'test_config_linux'),
op.join(bti_path, 'test_hs_linux')),}
dig=mne.channels.DigMontage(dig=raws['Magnes 3600wh'].info['dig'])
epoched.set_montage(dig) #set a digitization file `

I am not sure if this controls for the head position the same way a Maxwell filter would, but since participants originally had empty dig files, I assumed this standardized them. But correct me if that is not the case, however given all the coordinate issues with the data I would be afraid to load in head position info. But either way, I am getting this transition matrix issue on individual participant data as well, so head position should not matter at that level. I can also confirm this seems to be the case on other MEG datasets as well beyond the HCP MEG data, so this seems to be an MEG thing in general.

[mscheltienne]

The digitization gives you the sensor geometry, which for MEG is fixed. Thus, the fix of addijg the sensor geomtry manually to your files from another recording with the same MEG device is valid as the sensor geomtry is fixed.

But that does not give any informqtion about the head position. I am not talking about movement compensation but about the device to head transformation which should be present in .info["dev_head_t"].
All MEG systems should have a way to determine this coordinate transformation at the beginning of a new recording. For Elekta and MEGIN systems, 5 coils are attached to the patient head and digitized in the head coordinate frame. Then those same coils emit a known electromagnetic pulse at the beginning of the recording, localized by the MEG sensors in the device coordinate frame.
That creates the device to head transformation and tells you where the head is positioned at the beginning of the recording in the MEG helmet.

Note that some (actually many recording) assume constant head position during the entire recording.
Some systems do allow for continuous head position monitoring and this information can further be used to compensate for head movements (argument head_pos of the Maxwell filter).

Now the point of the processing I proposed above using Maxwell filter with the destination argument is to make sure that all your recordings are now measured in the same head position (at least the same beginning head position as I don't believe movement compensation is an option for you).

All that said, if you observe the same behavior at the individual recording level, then this might well be inherent to MEG microstates.

[Mattlab-hub]

Thank you @mscheltienne, I was not aware of that, I am more use to EEG myself, and I purposefully used the minimally preprocessed HCP data to make up for some of my lack of understanding, as I figured some of those things would have already been applied. Though, I do not know if that is something they would have applied at the minimal preprocessing step. I believe they did, but I will have to go back in and double check to be sure.

As for the main problem, yes, that is precisely what I am worried about, that because of some of the differences between MEG and EEG, it may be that MEG can only utilize this pipeline in source space. This does seem to be the case at both the individual level and the group level, since I get similar looking transition matrices either way.