-
Notifications
You must be signed in to change notification settings - Fork 96
Slowly growing FAQ – will keep adding question as they come up.
-
If the code is able to use different state distributions, then why is it called HMM-MAR?
-
Why every time I run it I don’t get exactly the same solution?
-
Do you really think the brain has a discrete number of states?
-
Single states explain entire subjects or sessions, so that there is little or none state switching.
-
I am getting errors on the parfor loops (parallel computing).
-
In fMRI, how can I focus my decomposition on functional connectivity?
-
The length of the state time courses does not coincide with the data, what can I do?
We have applied the HMM to various types of data, including M/EEG and fMRI. For M/EEG, a good point to start is Quinn et al. (2018), and the associated tutorial. More examples can be found in the Examples section of this Wiki, and here – which can be easily tailored to other data sets and settings. For fMRI, this one can be used as a starting point.
Yes, please. But maybe after having a look to this FAQ and the rest of the Wiki.
That depends on the type of data and what aspects of the data one wants to focus on. If analysing MEG or EEG data with many sensors or sources, then the Time-Delay Embedded HMM is a sensible choice (options.embeddedlags) If using intracranial data or just a few sensors or channels, and especially if you care about directionality, then the HMM-MAR is adequate; note that this is a more complex model, so, if that causes problems, the Time-Delay Embedded HMM is a safe bet. When analysing fMRI data, we have always used an HMM with Gaussian-distributed states. If one just cares about connectivity, then the mean of the Gaussian distribution can be fixed to zero (options.zeromean=1). If the registration is not very good, then maybe the covariance matrix can be set to be equal for all states (options.covtype=’uniquefull’); see also QX.
The MAR (Multivariate AutoRegressive model) was the model used in our first publication with this toolbox, so in part this is for historic reasons. Also, the rest of the distributions can be considered a generalisation of the MAR.
Same than with ICA and many other computational methods, the inference process that is used to estimate the parameters of the model can be a bit complex. The optimisation problem that this process is trying to solve often has different local minima, and, since there is some randomness in the initial conditions of the inference, this can converge differently in each run. This depends on the data and the specification of the model, but, in our experience, the optimisation problem often has one single solution, sometimes two, and only occasionally more than that. In any case, these solutions are always valid, the information is there, but is represented slightly differently.
For this reason, we would recommend run the model various times and inspect every solution separately.
Using stochastic inference will make things much faster; see [Vidaurre et al. 2018] (https://www.sciencedirect.com/science/article/pii/S1053811917305487) and check the corresponding section of the User Guide.
Same answer.
There is not really an exact answer to this one. More states will give a more fine-grained solution; fewer states will be coarser. It depends on the question and data, but, in general, running the model in half-splits of the data and comparing the robustness of the estimations is a good way to decide an upper bound in the number of states.
I don’t know. This is just an analysis technique, giving you a certain perspective of the data. Whether the HMM is useful or not, depends on the aspect in the data that we aim to interrogate.
Sometimes warnings saying things like “Matrix is close to singular or badly scaled”, or an error informing of “Issues of precision”, can occur. There are two reasons because this might happen.
First, it is possible that your data has some huge artefact, like for example a large peak. If that is the case, then the likelihood for the states to explain this part of the data is so small that falls under the threshold of what Matlab can represent. When this happens, one normally sees the “singular matrix” warning. The only solution in this case is to clean these artefacts.
Second, it is possible that you are using a too complex model (e.g. a MAR model with too large order), which explains the data so well that the error falls under the precision threshold. This happens also when we are using a MAR model on too many channels. The solution is either to reduce the order of the MAR, or to use PCA (options.pca) on the channels, or to use the Time-Delay Embedded HMM.
The chosen model is too complex, and one single state explain a very large amount of variance so that the others become unnecessary. Most likely you are using the MAR model. Again: reduce the order of the MAR, or to use PCA (options.pca) on the channels, or to use the Time-Delay Embedded HMM.
This typically happens because the registration of the subjects is not very good. Specially, when using full covariance matrices (covtype=’full’), it might be that the (regions by regions) average functional connectivity matrices are so dissimilar between subjects that the best solution the HMM can come up with is to assign one state to each subject; that is, between-subject differences massively dominate within-subject changes. The best solution is to improve the registration, or, if not possible, to use covtype=’uniquediag’; see User Guide. When using models that contain spectral information (MAR or Time-Delay Embedded) this might also happen when the frequency profiles of the subjects are too distinct – but this is rare.
Matlab's parallel computing can be a temperamental creature, and also the error messages are not great to diagnose what happens. We have found errors for certain combinations of Matlab distributions and operating systems, which do not seem to be related to the HMM code. If the problem persists, disabling the parallel computing feature by setting options.useParallel=0 should solve the issue.
Changes in the variance of the signal are always going to affect the estimation, but the best we can do (for now) is to use options.zeromean=1 and options.covtype=’full’.
Yes, with options.DirichletDiag, which tweaks the prior probability of remaining on the same state. Unfortunately, this depends on how much data we have (how many time points), so it is difficult to provide a solid recipe. You might want to increase one order of magnitude at a time, starting from options.DirichletDiag=10.
This happens when using the MAR model or the Time-Delay Embedded HMM. The function padGamma can fill the state time courses to have the same length of the data, for convenience.