FMRIPREP McFLIRT .par file different from when I run same order myself

I promise I keep asking questions only because I love the program so much I’m just trying to figure it out. Wish I could mail you guys a fruit basket or something.

I’m so sorry but I have to ask this question because it has been KILLING me for the last 3 days. It’s for peace of mind,.

Annnnnyway, for bold-bold transform processing, my graph1.json starts out generating a reference file and then running MCFLIRT as steps 5 & 6, respectively.

I tried to replicate this code with the following in a Jupyter notebook:

gen_ref = EstimateReferenceImage(in_file = func_filename).run()
mcflirt = fsl.MCFLIRT(in_file = func_filename, 
    ref_file = gen_ref.outputs.ref_image,
    save_mats=True, save_plots=True).run()

In this example func_filename is my raw functional EPI run. This seemed easy enough. The masks that come out of the gen_ref command are the same. The problem is that the parameters in the _mcf.nii.gz.par file are not the same between the FMRIPREP file and the one I generated with the above commands.

Now this may be the dumbest of dumb questions but, should they not be the same? I know algorithmic differences come into play between softwares and even within the same command sometimes but I didn’t think MCFLIRT was one of them. Also whenever I run this Jupyter code I get the same .par file so I’m not sure what exactly I’m missing here. The input parameters to my Jupyter stuff matches the report that came out of FMRIPREP.

Can anyone illuminate this because I am dying to know.

Aww. You should ask @oesteban what fruit does he like!

The project you are embarking on seems like a rabbit hole (perfect for xmas…). Here are some suggestions:

  1. Make sure you are comparing the right outputs (par file from FMRIPREP working directory)
  2. Evaluate the differences - are the outputs correlated? Off by a number?
  3. Make sure the two methods you are comparing have identical inputs.
  4. Make sure you are running the two methods in the same environment (container)

First thing I would try is reading the command.txt file under the node’s working directory after running fMRIPrep, and compare it to the output of mcflirt.interface.cmdline.

That will allow you to catch subtle differences in the command line.

Otherwise, I believe MCFLIRT should give you always the same results given the same inputs.

1 Like

So I know something is different from a stock mcflirt command because there is no actual .nii file outputted into the .tmp folder. When I check the command.txt this is the output:

mcflirt -in /data/sub-S03V1A/func/sub-S03V1A_task-compound_run-01_bold.nii 
-out /scratch/fmriprep_wf/single_subject_S03V1A_wf/func_preproc_task_compound_run_01_wf/bold_hmc_wf/mcflirt/sub-S03V1A_task-compound_run-01_bold_mcf.nii.gz 
-reffile /scratch/fmriprep_wf/single_subject_S03V1A_wf/func_preproc_task_compound_run_01_wf/bold_reference_wf/gen_ref/ref_image.nii.gz 
-mats -plots

I’m running this exact code with the output from my other folders which is equivalent to the files specified here (just in different folders). But still, in my own processing I get the .nii file associated with the -out flag but the FMRIPREP folder does not have it. Not sure what else could be messing this up.

Oddly, when I compare the .par files for each method the first 7 lines are identical but everything after that is different.

Yes, there has to be some minimal difference because this far we’ve never noticed any failed run-to-run reproducibility of MCFLIRT. If you are using containers there could be some other issues. E.g., are FSL within the container and your host on the same version?

Other than that, we would need then to go for even more subtle differences (maybe the schema file with registration parameters is changed in fMRIPrep, but I have no recollection of doing that), some environment variables (you can check them via the _report/report.rst file on the node folder where you found the command.txt file) or OS-level differences. To double check everything, you could go inside the container and run the command with your inputs to see whether there is some system-level setting acting out.

Other than that, I’d go for more mundane possibilities (e.g., you are using the same task but different run).

2 quick questions about this.

My FSL version on the host is 5.0.10. Is there a command I can run to see the FMRIPREP version? I run FMRIPREP via docker so I’d like to check as you advised.

Second question, and I’m sorry because this is a beginner question, how does one go ‘inside the container’ to run the command? I think I’m misunderstanding that.

(Secret third question: How many bananas do you want in your fruit basket or are you a citrus guy?)

Hi,

There’s plenty of good documentation on docker’s website. Long story short, the docker image contains a full OS stack, to a point that the recipe to create one image (e.g., fmriprep) looks almost the same the history after you have installed all the software on your own, on a physical or a virtual machine.

That means that fmriprep’s docker image not only contains fmriprep. It also shelters everything fmriprep depends on.

And docker allows you to play with all of that. You can “log in” into an fmriprep container, and you will get a shell prompt with fmriprep’s environment set up:

docker run -it --rm --entrypoint=/bin/bash poldracklab/fmriprep:1.2.5

Therefore you can also check FSL’s version:

docker run -it --rm --entrypoint=/bin/bash poldracklab/fmriprep:1.2.5 -c "cat $FSLDIR/etc/fslversion"

As you’ll see on the documentation, I’m playing with the --entrypoint option to change fmriprep’s default.

PS. fmriprep’s FSL version is 5.0.9.

This is insanely useful, @oesteban. I’m gonna go in there and have a look around. Thanks so much for taking the time to explain that to me because I’m honestly not sure I would’ve figured that out on my own (this is my first time using docker).

This also opens a lot of doors for me. Really, thanks so much for your explanation.

1 Like

The unfulfilling conclusion of the grand saga:
Running the identical command on my local machine and inside the container do, in fact, give different results where running the mcflirt command in the container gives the same parameters as those output by FMRIPREP (as it should). So it’s definitely a difference in software versions or something. I’m not entirely sure if there is a difference in how mcflirt works from 5.0.9 to 5.0.10. That would be weird.
I suppose at least I can take comfort in the fact that the output from running mcflirt on my local machine is not exactly WRONG when compared to the FMRIPREP pipeline, although it is different. Would that be a reasonable thing to say?

Thanks for accompanying me on my stupid journey of enlightenment!