fMRIPrep error with output path

[Yeshim_Onipede]

I am having an issue with running fmriprep. I keep getting this error:

fmriprep: error: The selected working directory is a subdirectory of the input BIDS folder. Please modify the output path.

But here is my script
module load fmriprep
fmriprep /restricted/projectnb/cd-lab/yesh/processing /restricted/projectnb/cd-lab/yesh_output participant

[tsalo]

fMRIPrep defaults to using a work subfolder of your current working directory. Are you running fMRIPrep from /restricted/projectnb/cd-lab/yesh/processing?

[Jon_Brooks]

Hi,

Apologies for revisiting an old topic… I’m running fmriprep using apptainer (formerly singularity) and getting the following annoying message:

fmriprep: error: The selected working directory is a subdirectory of the input BIDS folder. Please modify the output path.

The input data were converted using dcm2bids.

For reference here is the directory structure:

$ tree -L 2
.
├── CHANGES
├── code
│ └── convert_it_semsoc.json
├── dataset_description.json
├── participants.json
├── participants.tsv
├── README
├── sourcedata
│ ├── TD4.zip
│ └── TD5.zip
├── sub-004
│ ├── anat
│ └── func
├── sub-005
│ ├── anat
│ └── func
├── tmp_dcm2bids
│ ├── log
│ ├── sub-004
│ └── sub-005
└── work
├── 20250812-151247_f41d8f2c-cca1-4f39-888a-5fc3a31f8fab
├── 20250814-153033_14669ec8-e752-4b9c-bb3d-164352db78c4
└── 20250814-153033_4700980e-f8df-4180-b073-173390388e5a

The call to fmriprep is as follows:

PYTHONPATH="" 
apptainer run \
-B /mnt/fastscratch/users/jonb/bin/fs_license.txt:/opt/freesurfer/license.txt \
-B $dirp:/base /opt/apps/pkg/applications/containers/fmriprep/25.1.3/fmriprep_25.1.3.sif \
/base /base/derivatives participant \
--participant-label sub-"$zpid" \
-w /base/work \
--fs-no-reconall \
--me-output-echos \
--ignore t2w sbref \
--skip-bids-validation \
--fs-license-file /opt/freesurfer/license.txt \
--output-spaces func:res-native \
--fd-spike-threshold 0.3 

Given that dcm2bids generates the work directory within the bids folder when it’s doing its stuff, I’m not sure what fmriprep’s problem is with using a pre-existing work folder, or even using a work folder within the bids folder. Seems like a really sensible place to keep it imho.

Short of binding a different folder to dump the working data into what are my options…?

Cheers, Jon

[Steven]

Hi @Jon_Brooks

@Jon_Brooks

or even using a work folder within the bids folder

You should not put work folder in BIDS root. That creates problems when creating BIDS layout index. The tmp2dcmbids folder is added to a .bidsignore by dcm2bids.

@Jon_Brooks

Short of binding a different folder to dump the working data into what are my options…?

Just specify an outside folder.

@Jon_Brooks

--fs-no-reconall \

This flag is generally not recommended (even if you are not using surface outputs) unless you have subjects with whom FS generally fails (e.g., bad lesions).

You should also specify -e or --containall flag in your singularity run command.

Best,
Steven

[Jon_Brooks]

Hi Steven,

Thanks for getting back to me. Some follow-on thoughts/questions:

• couldn’t the “work” folder be added to .bidsignore? If it’s good enough for dcm2bids, why not fmriprep?
• if I’m not registering the output from fmriprep to a standard, is there still an advantage to removing “–fs-no-reconall” - what is the advantage of keeping this in (apart from roasting a few more polar bears).
• what does “-e or --containall” do? FYI I’m running on slurm (not sure if that’s relevant to this though).

Thanks for your advice/help.

Forgot to say, thanks for formatting my original question properly!

Cheers, Jon

[Steven]

Hi @Jon_Brooks

@Jon_Brooks

couldn’t the “work” folder be added to .bidsignore? If it’s good enough for dcm2bids, why not fmriprep?

Is there a particular reason you want work to be inside your BIDS dir? I imagine the pybids layout calculation by fmriprep is confounded by having workdir inside BIDS dir. dcm2bids isn’t a “BIDS-app” per se, and doesn’t use the pybids mechanism for anything.

@Jon_Brooks

if I’m not registering the output from fmriprep to a standard, is there still an advantage to removing “–fs-no-reconall” - what is the advantage of keeping this in (apart from roasting a few more polar bears).

Boundary-based BOLD to T1w registration.

@Jon_Brooks

• what does “-e or --containall” do? FYI I’m running on slurm (not sure if that’s relevant to this though).

Makes sure environment variables are not carried in from your local computing environment. These could be things defined by local installations of softwares that could point fMRIPrep to incorrect software installations.

Best,
Steven

[Jon_Brooks]

@Steven

Is there a particular reason you want work to be inside your BIDS dir? I imagine the pybids layout calculation by fmriprep is confounded by having workdir inside BIDS dir. dcm2bids isn’t a “BIDS-app” per se, and doesn’t use the pybids mechanism for anything.

Mostly for reasons of tidiness - just wanted to keep temporary working directories co-located with data from which it derives, but that’s probably just my problem. I will move it outside of the bids folder…

@Steven

Boundary-based BOLD to T1w registration.

I’m going to do that in FSL.

@Steven

Makes sure environment variables are not carried in from your local computing environment. These could be things defined by local installations of softwares that could point fMRIPrep to incorrect software installations.

This is helpful and probably explains some unexpected behaviour!

Thanks again…

[Steven]

@Jon_Brooks

I’m going to do that in FSL.

I wouldn’t recommend doing any post-hoc registration as that introduces unnecessary interpolation.

Best,
Steven

[Jon_Brooks]

@Steven

I wouldn’t recommend doing any post-hoc registration as that introduces unnecessary interpolation.

I think this is the reason why FSL does first level analysis in acquired space.

The only time registration to T1, then to standard is done is when performing group analysis of the computed beta/variance maps. This always seemed more intuitive to me than jumping straight to standard space, but I’m sure there’s pros/cons for both approaches.

To be clear, the BBR step will still happen - the only things that’ll have already been done is motion correction with mcflirt (I think that’s what fmriprep uses) and SDC (if I can persuade the PI to add this to their protocol).

The other slightly complicating factor is that these are multi-echo data, which I think are probably best left in func space for the purpose of denoising, prior to reading in the motion corrected and denoised version of the data into FSL. That would then provide the reference image that’s used for BBR reg to the T1.

So, it’s a lttle (lot) convoluted, but should work - I hope!

Cheers, Jon

[Steven]

Hi @Jon_Brooks,

@Jon_Brooks

The other slightly complicating factor is that these are multi-echo data,

I do not use multi-echo data, so I cannot speak to that point, sorry! But in general…

@Jon_Brooks

I think this is the reason why FSL does first level analysis in acquired space.

FSL analyses can happen in any space (native, standard, or otherwise), it is just that fMRIPrep combines all transformations and resampling into a single one-shot process. It is true that native space outputs will not involve nonlinear correction as in MNI normalization. But even then, the whole process of registration and motion correction happens in a single step.

@Jon_Brooks

The only time registration to T1, then to standard is done is when performing group analysis of the computed beta/variance maps

Warping these statistical parametric maps to standard space may introduce unwanted smoothing. I would personally recommend just standardizing space in fMRIPrep and do all first and second-level modeling there.

@Jon_Brooks

SDC (if I can persuade the PI to add this to their protocol).

If the PI won’t, you can use SynBOLD Dis-Co to make a synthetic BOLD fieldmap. Empirically has worked well for others.

Best,
Steven

[Jon_Brooks]

@Steven

FSL analyses can happen in any space (native, standard, or otherwise), it is just that fMRIPrep combines all transformations and resampling into a single one-shot process. It is true that native space outputs will not involve nonlinear correction as in MNI normalization. But even then, the whole process of registration and motion correction happens in a single step.

Think this might be slightly moot given that the first level pre-processing involves smoothing, but I take your point.

In general I think it’s probably better to stay in acquired space when determining noise components to be removed, as the effect of warping/interpolating to standard space will alter their structure, making it harder (?) to unambiguously identify them. However, that’s just a gut feeling I don’t have evidence to back that up. So perhaps take with a pinch of …

Cheers, Jon

[Steven]

@Jon_Brooks

Think this might be slightly moot given that the first level pre-processing involves smoothing

Sure, but it is better to have more control over the smoothing rather than impose unquantified smoothing by normalizing the maps later.

@Jon_Brooks

In general I think it’s probably better to stay in acquired space when determining noise components to be removed

fMRIPrep does determine the noise components (e.g., compcor) in acquired space, as far as I know. Can’t speak to anything multi-echo though.

Best,
Steven