Fmriprep-docker call

[franklin]

Hi,

I am trying to get fmriprep-docker wrapper to run. I followed the instructions on the fmriprep readthedocs to run the docker container. I was able to get the pip install --user --upgrade fmriprep-docker to run. (Command line output below). However when I try to run the next step fmriprep-docker /Users/franklinfeingold/Desktop/BIDS_NKI_walkthrough/Nifti /Users/franklinfeingold/Desktop/BIDS_NKI_walkthrough/derivatives sub-2475376. However, the fmriprep-docker command cannot be found. I am able to run fmriprep through docker using my own crafted docker call, but would like to try and get the wrapper to work as well. I have the dependencies installed (i.e. Docker, python) Thank you!

pip install --user --upgrade fmriprep-docker
Collecting fmriprep-docker

Downloading https://files.pythonhosted.org/packages/f6/25/34a15a4d9979fb643b61a523cfdb236222890df770d172127adb954a4f2f/fmriprep-docker-1.2.6.post1.tar.gz

Building wheels for collected packages: fmriprep-docker

Running setup.py bdist_wheel for fmriprep-docker … done

Stored in directory: /Users/franklinfeingold/Library/Caches/pip/wheels/90/e8/a2/2139c201af73705a94a141f78a56ea800bb631b3952b46843b

Successfully built fmriprep-docker

Installing collected packages: fmriprep-docker

Successfully installed fmriprep-docker-1.2.6.post1

[emdupre]

Hi @franklin !

This might have to do with which Python environment it installed into. It’s hard to say without knowing more about your system, but one suggestion would be to create a Conda environment and install fMRIPrep-docker within that activated environment. Then you can be more certain it’s calling the right Python (i.e., the output of which python should trace back to that environment).

Hope that helps !

Elizabeth

[franklin]

Hi @emdupre!

Thank you for your quick response! I was digging deeper, and yup! One has to make sure everything is all up to date (I used Python 3.7, I am not sure if 3.0 would work, may recommend sticking to 3.7, reduce risks). The (possible) automatic alias (so you can call directly the fmriprep-docker) wouldn’t work, I had to go directly into the folder where it was download, chmod 775 (or +x) the .py script and then it would run. One last little quirk was the participant label doesn’t like my sub-2475376 participant tag, thoughts on what may be happening there?

Thank you!

[emdupre]

Glad you found a solution ! For the remaining issue, I’d try dropping the “sub” prefix in the call

[franklin]

Just tried dropping the “sub” prefix and it still didn’t like it. It appears it may be just a place holder? It gives just a choice of ‘participant’ in the command so maybe fmriprep_docker.py will grab the right subject? (If there are multiple not sure how it would handle that, my current test set just has 1). Other calls with fmriprep_docker.py has the consistent participant tag there too so that is curious. If I kept it as just participant it will start running so I am not sure. Thank you for your quick help!

[emdupre]

Ah, you’re right – I was thinking of the the --participant_label flag in fMRIPrep, but I don’t think fMRIPrep-docker has access to that !

That participant call is just to meet the BIDS App specification and set the analysis level. Glad you got it working !

[franklin]

That sounds good - I will just use participant then. Though, I am concerned of how it scales for more subjects and deciding who to run it on (all of them? if so, the storage issues will creep really quickly if that is the case). This should at least get me moving in a good direction! Thank you again for the quick help!

[brai]

BTW- Actually, the docker version does support the participant label option.

[effigies]

Just to clarify the situation, you would use:

fmriprep-docker \
    /Users/franklinfeingold/Desktop/BIDS_NKI_walkthrough/Nifti \
    /Users/franklinfeingold/Desktop/BIDS_NKI_walkthrough/derivatives \
    participant --participant-label 2475376

So you always use participant (it’s the only analysis level fMRIPrep has), and you specify the ones you want with --participant-label. And you don’t need the sub- prefix (though we do allow it because so many users made this mistake, we decided to just fix it for them).

[brai]

I think that the main obstacle I tackled when I first tried to use this option was that in the “help” the order of the options was reversed, at least in former versions (the ordered arguments were shown last while they must be first).

[emdupre]

Where is this behavior documented ? In the help for the fmriprep-docker wrapper, there’s no mention that you can pass along additional arguments from fmriprep. Unless I’m missing the reference ?

I don’t usually use the wrapper, so perhaps it’s known behavior I’ve just missed.

[effigies]

Fair point. That’s poorly documented. The whole point of the wrapper was to be called just like fmriprep, and translate it to the correct docker invocation, with all the mounting done for you.

[emdupre]

Yes, the behavior aligns with that vision, but I wasn’t aware it was available from the help !

It’d great to get that behavior better documented, to save any future confusion.

[brai]

Actually- there was already some documentation bug opened for this… I’ll look for it afterwards.

[effigies]

Just as an aside, it’s a little more complicated than that. Both the exact semantics of interpreting order of arguments and their positions in the help text are quirks of the argument parser, and not (AFAIK tweakable by us). It is possible to write the positional arguments at the end, if you choose to put in the effort, but putting them first means never having to think about those semantics, which is why I do it, personally.

[franklin]

Thank you @effigies, @emdupre and @brai for your clarifications and help! This all makes a lot of sense! I am writing up a fmriprep tutorial using this wrapper call so this great information will be integrated into that step