MNI152NLin2009cAsym was used as the output spaces and I didn’t specify --use-aroma.
I’m not entirely sure whether or not this will help, but you could try re-running fmriprep with --output-spaces MNI152NLin6Asym. The MNI152NLin6Asym output space is the exact same as FSL’s MNI152. The one you used is slightly different. This may solve the issue you’re having when trying to analyze the data in FSL FEAT.
Thank you for the suggestion, but I preprocessed the data using fMRIPrep. Is there no way around this issue?
There’s nothing preventing you from re-processing your data with fMRIPrep, other than time constraints. To save time, you can reuse the same working directory from before (--w). If you incorporated FreeSurfer in your fMRIPrep pipeline, you can reuse that information by specifying the path in --fs-subjects-dir.
Again, this suggestion is simply to ensure that your fMRIPrep functional output is in the same space as FSL’s MNI152 standard space, which may be the cause of your issues.
Okay, I will re-process the data with fMRIPrep.
I have two follow-up questions:
- Would this code be correct to help me save time?
fmriprep-docker --w /mnt/c/Users/rubin/BIDS /mnt/c/Users/rubin/derivatives participant --participant-label sub-C0120061 --fs-license-file /mnt/c/Users/rubin/fs-license/license.txt --low-mem --output-spaces MNI152NLin6Asym
- Once I have pre-processed the data with fMRIPrep, and when I run FSL, do I have to change the standard space to MNI152NLin6Asym?
I really appreciate your help in pointing me in the right direction.
If that’s the same working directory path that you used before then you should be good.
Your fMRIPrep output will now be in MNI152NLin6Asym space; I don’t think you need to change anything from FSL FEAT’s perspective, other than making sure you’re feeding in the correct data.
After reading through dlevitas responses… I think our situations differ in that I did specify --use-aroma in fmriprep, which is why I guess I did not have this issue (although I cannot say for sure). In my case, when I specified ICA aroma, it created the output space for both MNI152NLin6Asym and MNI152NLin2009cAsym.
@aftonnelson when you specify --use-aroma fMRIPrep will automatically add MNI152NLin6Asym to --output-spaces even if it wasn’t explicitly specified. My hunch is that the error @Rubina is having is because she was trying to feed FEAT data that wasn’t in FSL’s MNI152 standard space.
Following up from the point you made,
- I re-processed the data to be in MNI152NLin6Asym space.
- I set up all the variables and save it in .fsf file format.
- When I run the first-level analysis, in the ‘Data’ tab, I include the preproc bold file in the MNI152NLin6Asym space from fMRIPrep, in ‘Pre-Stats’, I turn off the motion correction: none, I turn on the BET brain extraction and high-pass filter. In the ‘Stats’ tab, I choose ‘Full model setup’ and set up the EV and Contrasts and hit ‘Go’.
Is there something else I should add and or /remove that I’m not doing?
These are fine, you can also turn of slice timing correction, as this is done by fMRIPrep.
On the “Registration” tab, be sure to follow the instructions from the FEAT workaround video posted earlier in this thread.
This seems correct. If you haven’t, you can also view the design matrix as a visual check to ensure that everything has been set up properly.
On the “Stats” tab, I would strongly recommend selecting “Add additional confounds EVs” and add a text file where each column is a confound you would like to have regressed from the data. In your fMRIPrep output, each functional BOLD acquisition contains a corresponding desc-confounds_timeseries.tsv file with many confounds to choose from. You’ll want to select a subset of confounds to include in your design matrix. Specifically, since you’ve turned off motion correction in FEAT, you’ll want to include the motion confounds from the desc-confounds_timeseries.tsv files. For an example, see this post.
@dlevitas, thank you so much for your constructive feedback.
I took a look at the post but I’m not sure what regressors to add and what to modify in this specific code:
motion_confounds = [x for x in confounds_file.data if ‘trans’ in x or ‘rot’ in x]
This line of code extracts all columns in the desc-confounds_timeseries.tsv file that contain the sub-strings trans or rot, which in terms of head motion refer to translations and rotations. There are 6 head motion parameters (3 translations, 3 rotations), but the line of code will also extract head motion derivatives and quadratic terms, which can be used for your regression. At the bare minimum you would want to include the 6 head motion parameters, but including the derivatives and quadratic terms is good practice as well.
There are [probably] other confounds within each desc-confounds_timeseries.tsv that are good to include in your regression; however, which ones you choose are more dependent on the type of data you have (e.g. task vs rest functional BOLD data) and the kind(s) of denoising strategies you wish to employ. For more information on the confounds generated from fMRIPrep, see this documentation section.
Thank you for explaining the desc-confounds-timeseries.tsv file. I have a question related to the confounds. This is what the design matrix looks like when I run the first-level analysis:
Should the confounds look like this?
HI @Rubina,
The design matrix you’ve provided looks correct, though I’m not entirely sure which confounds you provided (I’m assuming the motion-related confounds). If you don’t receive any FSL FEAT warnings/errors then you should be good to begin your 1st level analysis.
I followed the Python code in the post you shared related to confounds, changed it accordingly and attached it as an additional confounds EVs in FSL FEAT. It didn’t throw me any error.
The confounds used are as follows: trans_x trans_x_derivative1 trans_x_power2 trans_x_derivative1_power2 trans_y trans_y_derivative1 trans_y_derivative1_power2 trans_y_power2 trans_z trans_z_derivative1 trans_z_derivative1_power2 trans_z_power2 rot_x rot_x_derivative1 rot_x_power2 rot_x_derivative1_power2 rot_y rot_y_derivative1 rot_y_derivative1_power2 rot_y_power2 rot_z rot_z_derivative1 rot_z_derivative1_power2 rot_z_power2
1 Like
I ran the higher-level analysis and the registration summaries for all 3 runs are still missing. I tried deleting the .mat files and also tried not deleting the .mat files and just replacing it with the identify matrix and yet to no avail 
I don’t know how to proceed next.
Is it okay that I attach the log file for your perusal?
Higher level analysis FSL.txt (28.4 KB)
I can’t really say much more about your issue unless I were to look at your .fsf files. For more thorough help, I would suggest posting your issue to the FSL support forum. They can do a much better job helping you.
I revisited your original error log that you posted for the higher level. I feel like I had a similar error at same point when I was creating ROI masks. It might be a long shot, but are you indicating a mask in the post stat stage?
Hi @Rubina,
The file extension for your fsf file should be .fsf, that way you can load it into your FSL FEAT GIU in the future (FEAT won’t recognize that it’s a fsf file with a .txt extension).
The only other thing I can recommend is to double check the workaround video to make sure you’ve performed the steps properly. Other than that, I can’t tell why you’re encountering a problem at the 2nd level analysis step. Hopefully the FSL developers will be able to able to provide an answer.