Fmriprep template files download failure

, ,
1

Hi guys,

We installed fmriprep using a Manually Prepared Environment with all the dependencies installed via NeuroDebian. However we cannot download template files from the database when running fmriprep. Here’s the command and screen output:

fmriprep BIDS_DATA/ fmriprepout/ participant -w fmriprepwork

170627-14:48:22,587 niworkflows INFO:
Downloading data fromhttps://files.osf.io/v1/resources/fvuh8/providers/osfstorage//584123a29ad5a1020913609d ...
170627-14:48:22,589 niworkflows WARNING:
Resuming failed, try to download the whole file.
170627-14:48:22,589 niworkflows INFO:
Downloading data from https://files.osf.io/v1/resources/fvuh8/providers/osfstorage//584123a29ad5a1020913609d ...
170627-14:48:22,590 niworkflows WARNING:
Download failed, retrying (attempt 1)
170627-14:48:27,595 niworkflows INFO:
Downloading data from https://files.osf.io/v1/resources/fvuh8/providers/osfstorage//584123a29ad5a1020913609d ...
…

The niworkflows 0.1.3 was already installed and there was no problem when only using niworkflows functions to download the templates. Here’s the code running in python 2.7 and its output:

from niworkflows.data import get_ants_oasis_template_ras
get_ants_oasis_template_ras()

170627-15:09:04,286 niworkflows INFO:
Downloading data from https://files.osf.io/v1/resources/fvuh8/providers/osfstorage//584123a29ad5a1020913609d ...
Downloaded 28327936 of 56935974 bytes (49.8%, 17.1min remaining)

Actually we found the problem happened when niworkflows’ internal nipype module (v1.0.0) was loaded. With the code:

import niworkflows.nipype
from niworkflows.data import get_ants_oasis_template_ras
get_ants_oasis_template_ras()

We received the same download failure warning.

The error disappeared if we load an older version of nipype (0.10.0, installed separately from niworkflows)

import nipype
from niworkflows.data import get_ants_oasis_template_ras
get_ants_oasis_template_ras()

This code had no download errors. But if we load an latest version of nipype (0.13.1),we got the same error again.

Since fmriprep requires a niworkflows of version 0.1.3, which loads its internal updated nipype, we receive the download failure message. Does anyone know how to fix the problem?

I would greatly appreciate it if anyone could help.

2

Hi @blou. Sorry about the delay. I’m really not sure why this is happening, and cannot reproduce. Is it possible it was an issue on osf.io, and that it was a coincidence of timing?

Edit: And to be clear, what version of FMRIPREP are you using?

3

Hi effigies,

We installed fmriprep using pip and the current version is 0.5.0.
I’m not sure if it was a coincidence of timing but we tested this a few times on different days. Do you think it could be a proxy issue? We set up the proxy through environment variable “http_proxy” and “https_proxy”.

Thanks.

4

Hi Chris,

While a osf.io availability problem would be plausible, it isn’t that (as we were able to download separately via the browser, and via standalone python scripts).

The problem seems to be with niworkflows internal nipype module (which is the latest version, 0.13.1); it doesn’t happen with a standalone, earlier version of nipype (0.10.0).

If this proves too hard to reproduce we’re of course more than willing to take the docker route. My thought was more that this would be worth reporting since it happens with the most recent version of nypipe…

thank you!
Francisco

5

Hi @fpereira, @blou,

What’s strangest here is that I can’t find a dependency on nipype in the niworkflows.data module at all, either internal or external. It’s really unclear what effect nipype could be having here. Data fetching is really a function of urllib.

I created a new environment in Docker (continuumio/miniconda) to see if I could reproduce without any pollution from my laptop, but was able to get the template without any trouble.

$ docker run --rm -it continuumio/miniconda
% conda install lxml traits subprocess32
% pip install niworkflows==0.1.3
% python
>>> import niworkflows.nipype
>>> from niworkflows.data import get_ants_oasis_template_ras
>>> get_ants_oasis_template_ras()
170629-23:35:53,22 niworkflows INFO:
	 Dataset created in /root/.cache/stanford-crn/ants_oasis_template_ras
170629-23:35:53,23 niworkflows INFO:
	 Downloading data from https://files.osf.io/v1/resources/fvuh8/providers/osfstorage//584123a29ad5a1020913609d ...
Downloaded 56935974 of 56935974 bytes (100.0%,    0.0s remaining) ...done. (5 seconds, 0 min)
u'/root/.cache/stanford-crn/ants_oasis_template_ras'

However, there are a couple things that may be worth bringing up:

  1. While niworkflows still supports Python 2, we do not support it in fmriprep. It runs (thanks to a user a month or so back who sent in a patch to un-break it), but we don’t test it, and there may be subtle issues that we aren’t even trying to catch. So one possibility is to consider installing fmriprep with Python 3, and verify you’re still having the issue.

  2. It doesn’t seem very plausible to me that this should be the root of your issue, but one thing to be aware of with the niworkflows>=0.1.0 (with internal nipype) releases is that the internal nipype is not compatible with an external nipype, in the sense that an interface from one cannot be used in a workflow from the other (because they have different class hierarchies; isinstance checks fail). If you have an older version of niworkflows also installed on the system, there’s a chance you’re getting a conflict there, when niworkflows uses absolute imports. (This is a thing we should fix. But again, how this could be exhibiting as your issue is difficult to imagine.)

As to proxies, it’s entirely possible that that’s relevant; I have no experience here. I believe that urllib and friends were very heavily rewritten between Python 2 and 3, so it’s possible that there’s an interaction here, too.

I don’t know if this was very helpful. I guess this demonstrates why we encourage people to use Docker. As a bonus, we pre-fetch the templates when building the images.

Chris

6

Thank you very much for looking into this so thoroughly, Chris! We will try doing it with Python 3 (we are using 2.7 at the moment) and, failing that, switch to docker.

Francisco

7

For what it’s worth the container version of FMRIPREP (Docker or Singularity) already includes the templates (so the download problem should not happen).