Fixed-Effects FSL from fMRIPrep



I have been working off this example by @ChrisGorgolewski which has been extremely helpful in generating a first-level model from my fMRIPrep outputs. I now need to add a second level / fixed-effects level to merge runs for each participant. In another post @nataliavelez adapted and reworked Chris’ script as a Nipype workflow. I prefer not to do that since I am new to Nipype and FSL, and would rather to add to the Chris’ example script.

I have run the first-level workflow on a few participants (each with 2 runs). I now have all my outputs (copes, varcopes, etc.) for both runs for each participant. I understand that fixed-effects is more-or-less an averaging of the copes for each participant’s runs. Does anyone have any suggestions on how to do so? Can I apply something like this to Chris’ example? Is that the correct use? If so, how do I apply this Nipype code to Chris’ example, since it’s structured/worded slightly differently? At what point would I apply create_fixed_effects_flow() ?

Thank you for the help.


Hello again,

A follow-up question regarding applying Nipype workflows. I would like to apply create_fixed_effects_flow(), but don’t now how to apply it to this style of coding/example.

For example, in the notebook above, SpecifyModel() is set like this:

s = model.SpecifyModel()

Whereas in a more traditional Nipype the same is done like this:

modelspec = pe.Node(modelgen.SpecifyModel(),

Then components of SpecifyModel are added to s. Similar issue for Level1Design, and other key FSL components. I’ve tried to add create_fixed_effects_flow(), but don’t know how to. If I could just figure out how to add this workflow, then I think I could likely add to it and figure out the rest.

Thanks for the help.


If you would like to add to chris’ example, you could do the full first level processing with nistats’ compute glm function without using FSL.

regarding the second question this has to do with differences between how Interfaces are used in a standalone manner or in a Node within a Workflow. in chris’ example you will also notice mem.cache version, which is also a Node like form.

these are all valid forms of operation, but make different assumptions. your usage will depend on, whether you need caching, whether you want to manage data characteristics or whether you want nipype to handle the dataflow.

I would recommend the nipype tutorials, to at least go through the basic components and concepts, which should clarify the situation a lot more.

1 Like

Thank you for the clarification. I read the documentation on caching and I think this is what I would like to continue with due to the fact that it allows regular Python code rather than workflows, and since I have already adapted Chris’ notebook to my data. However, I still can’t figure out a way to get the second level/fixed effects done.

Since create_fixed_effects_flow is a workflow, does this mean I can’t combine it with the caching style? If that is the case, should I just redo the first level in a pure Nipype workflow and then add on create_fixed_effects_flow like this example.