I’m trying to calculate a simple first level analysis using nistats. However, for some of our subjects, not all runs have the same number of different trial_types (e.g. for run 1 there might be condition_1 and condition_2, while for run 2 there is condition_1, condition_2 and condition_3). While fitting the model works fine, computing the contrasts doesn’t:
ValueError: t contrasts should be length P=37, but this is length 38
I’m quite a newbie so I’d like to apologize if my two questions seem stupid:
I was under the impression that nistats fits the model for all provides runs simultaneously - so wouldn’t be missing regressors for parts of the model problematic? Why does fitting even work?
Hi Marc,
Indeed at the moment we do not support missing regressors in nistats glm. What should be returned in case of a missing regressor is actually unclear…
The best way to proceed is probably to fit glms separately for the different sessions, and then run the cross-session fixed effects analysis “manually”.
Does it make sense to you ?
B
thanks for your answer. Your suggestion sounds reasonable but I wonder if it would be possible to just concatenate the design matrices? Meaning to model each run/session separately and then create a large design matrix where all bold regressors “span” over all runs and regressors that are run-specific (e.g. drift-correction, confounds, motion outliers etc.) are set to 0 for all runs except those they were modeled for?
I’m a little bit unsure what this would mean in statistical terms. It feels like this would add a little bit of power because the model has more data to be fitted on, but there is probably a caveat to this approach I’m not seeing here.
Note sure what you want to do, but indeed there is the possibility to handle all you data as if it were one single session by creating a large block-diagonal design matrix, in which each block is the design matrix for one sessions.
Note that in this case, even the confounds of the different blocks are handled cleanly.
The only caveat I can see is memory cost for the fit.
I’m so glad you’ve posted this, as I’m running into the same error! In my case, my runs have the same conditions but different confounds (I added regressors for high motion TRs above a certain FD threshold). As Marc mentioned, fitting the GLM seems to work, but I get a ValueError when making the contrasts.
I’m new to this too, and not quite sure how to run the cross-run fixed effects analysis and compute the resulting contrasts manually. Does anyone have an example of how to do this? Or thoughts on whether it would be worth it to take out the additional confounds just use FD as a continuous regressor?
OK, there’s an ongoing PR on Nistats on this topic (https://github.com/nistats/nistats/pull/386) .
If you know how to do this, simply clone the corresponding branch and use it…
thanks for the efforts you already made. I looked at the changes you made and that were recently merged and decided to give it another try. However, the problem seems to persist. I’m wondering if I’m doing something wrong because this seems like a very common scenario to me. If you use FMRIPREP, you will inevitably get different numbers of nuisance regressors per run (e.g. motion outliers) and there is currently no way to handle this, excepts for maybe building a design matrix that spans multiple runs (and then stack the events & images) yourself. As far as I know, this is the way SPM and AFNI solve this problem.
Sure, but if you fit separately for each session, you can generate the GLM output (contrast image and variance), and then compute the fixed effects model on these images — outside of the FirstLevelModel.
Does that make sense ?
Where does the code break ?
Sorry, I just had brief look on your changes and was under the impression that this is handled automatically now. Please excuse my lack of attention there.
So I guess it will work if I compute contrasts and variances manually for each run and then combine them in a fixed effects model? This sounds like a working solution but (at least for me) one questions remains open: How does this (statistically) compare to just fitting a large design matrix that spans all runs? I’d imagine fitting one matrix over all runs would be problematic if there is considerable variance between runs because then the β estimates would suffer… (please correct me if I’m wrong). Yet, this seems to be the approach other available software packages have taken.
And there is still an unsolved problem with the fit-independently-combine-later-approach: If there is a missing condition in one of the runs, obliviously no contrasts can be computed that include that condition. This can happen if the conditions depends on the reaction of the participant (e.g. detected vs undetected) and can be handled easily if you just fit one matrix over all runs…
Normally, running this “summary statistics” model is equivalent to the “block-diagonal” model if the variance is the same across blocks. If the variance varies across blocks, this won’t change much the effect size estimates , but possibly their fixed-effects variance & significance.
In any case the fixed effects approach is valid, and actually more so than the ‘block diagonal’ one.
I agree that the missing contrast problem is pending. The only solution is to compute fixed effects only across blocks for which the contrast have been estimated.
I’m running in the same issue: when fitting GLM on the 2 runs I get 2 design matrices with different number of columns (specifically, the number of drift columns is different).
If I perform a fixed effects analysis as specified in the tutorial: https://nilearn.github.io/auto_examples/04_glm_first_level/plot_fixed_effects.html
I get as output 3 images: fixed_fx_contrast_img, fixed_fx_variance_img, fixed_fx_t_img.
What is fixed_fx_contrast_img in this context?
Should I use fixed_fx_t_img for the following second-level analysis (where I’ll compare activity pre- and post- intervention)?
Should I convert it to z-map before running second-level analysis?
fixed_fx_contrast_img is the beta estimate of the fixed effects (essentially the sum of the per-run “betas” ) fixed_fx_variance_img is the corresponding variance estimate fixed_fx_t_img is the corresponding t statistic
In general, it is recommended to perform second-level analysis on the beta estimates rather than t/z statistics.
The conversion of t to z requires the number of degrees of freedom to be known, but in case of fixed effects, it is rather large, so that t~z, so I’d not worry about that (the differences are minor in view of the between-subject variance anyhow).