Fmriprep: crash related to slice timing

[dkp]

crash-20190430-210211-root-slice_timing_correction-1cb687c1-e8e7-44f2-bb02-bf021de4c6fd.txt

Hi all,
We are new to fmriprep. The data we have are recently collected on a Siemens skyra, converted to BIDS with heudiconv and behave well with MRIqc.

We downloaded the container with docker pull (1.3.2). We provided a license file for freesurfer.
The container is running on Docker 2.0.0.3 on Mac Sierra (10.12.6) with 35 GB of RAM allocated to docker. We ran the following command:

docker run --rm -it -v /Users/akielar/license.txt:/opt/freesurfer/license.txt:ro -v ${PWD}:/data:ro -v ${PWD}/derivatives2:/out poldracklab/fmriprep:1.3.2 /data /out participant --participant_label 312 --skip_bids_validation --cifti-output

and it crashed within 5 minutes.

We are trying again with --ignore slicetiming and it has been running about 20 minutes so far (fingers crossed)

Can you help us understand why we might have to ignore slicetiming?

Thank you,

Dianne

[oesteban]

Hi Dianne, welcome to the fMRIPrep community.

At the end of the crashfile you'll find:

** FATAL ERROR: tpattern file slice_timing.1D has 1 values but have 32 slices

In other words, the tool complains because the number of slice times and actual slices in your image do not match.

If you go up a little on the crash file you'll find the inputs to this node. In particular, you can see:

slice_timing = [0.0]

In other words, only one timing of 0.0 was given, instead of 32 corresponding to the 32 slices in your BOLD image.

This means that the sidecar metadata (either the task-rest_bold.json at the top level or some lower level json file) in your BIDS structure is wrong.

This would've been caught by the BIDS Validator, shouldn't you set the --skip_bids_validation flag.

On a final note, I am guessing by your naming that you are using motion corrected timeseries. I'm not sure that is a good idea with fMRIPrep.

[dkp]

Wow! Thanks.

-Dianne

On Tue, Apr 30, 2019 at 4:14 PM Oscar Esteban [e-mail]
wrote:

Hi Dianne, welcome to the fMRIPrep community.

At the end of the crashfile you'll find:

�[7m** FATAL ERROR:�[0m tpattern file slice_timing.1D has 1 values but have 32 slices

In other words, the tool complains because the number of slice times and
actual slices in your image do not match.

If you go up a little on the crash file you'll find the inputs to this
node. In particular, you can see:

slice_timing = [0.0]

In other words, only one timing of 0.0 was given, instead of 32
corresponding to the 32 slices in your BOLD image.

This means that the sidecar metadata (either the task-rest_bold.json at
the top level or some lower level json file) in your BIDS structure is
wrong.

This would've been caught by the BIDS Validator, shouldn't you set the
--skip_bids_validation flag.

On a final note, I am guessing by your naming that you are using motion
corrected timeseries. I'm not sure that is a good idea with fMRIPrep.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/1597#issuecomment-488148375,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHLUQBORCGB5LBT6MU4JYLPTDHFXANCNFSM4HJQYPZA
.

--
Dianne Patterson, Ph.D.
Research Scientist
[email protected] [e-mail]
or
[email protected]
University of Arizona
Speech and Hearing Science 314
1131 E 2nd Street, Building #71

(Just East of Harvill)

If you don't hear back from me (and you expected to),
I blame the University's new SPAM filter.

Please write to my gmail account.

Antipiphany: That moment when you realize how little you actually know

[dkp]

Just to confirm: removing the moco series made fmriprep happy.