Issue with denoising design matrix when fMRI runs have different file names

[erikglee]

Summary

Hello! I believe I have found a bug related to the XCP-D denoising process. I am thinking this bug is likely specific to cases where there are two runs of fMRI data, each with unique acquisition parameters such that there isn't a "run-label" in the file name.

Additional details

• xcp_d version:0.12.0

Command being used:
singularity run --cleanenv \
-B $deriv_dir:/deriv_dir \
-B $work_dir:/work_dir \
-B /XXXXXX/license.txt:/license.txt \
-B $filter_file:/filter_file.json \
/XXXXXX/xcp_d_0.12.0.sif \
/deriv_dir/fmriprep /deriv_dir/xcp_d participant -w /work_dir \
--input-type fmriprep --mode hbcd \
--dummy-scans 0 --despike y \
--smoothing 4 --motion-filter-type none --linc-qc \
--fs-license-file /license.txt \
--omp-nthreads 3 \
--nuisance-regressors 36P --fd-thresh 0.3 --warp-surfaces-native2std \
-vv

Example names of the two primary fMRIPREP cifti output files:
sub-001_ses-bch1_task-rest_space-fsLR_den-91k_bold.dtseries.nii
sub-001_ses-bch1_task-rest_acq-3echo_space-fsLR_den-91k_bold.dtseries.nii

What were you trying to do?

I was trying to run standard denoising on two types of multi-echo fMRI acquisitions, that had already been processed with fMRIPREP version 25.2.3.

What happened?

The connectivity matrices for one of the fMRI runs didn't look good. Based on this I started looking around and I noticed that the XCP-D files sub-001_ses-bch1_task-rest_design.tsv and sub-001_ses-bch1_task-rest_acq-3echo_design.tsv had the same contents, which I believe is causing issues with the denoising. To confirm that this issue is coming from XCP-D, I looked at the fMRIPREP confounds files and verified that the confound files for these two fMRI runs was different.

As a follow-up test I also ran some custom denoising routines using the incorrect design matrix that was saved out by XCP-D. When I use this, the results largely recreate what I see in the XCP-D outputs. And then when I switch over to a corrected design matrix the results get much better. So based on this, I am thinking that the incorrect design matrix is actually getting used by XCP-D.

Out of curiosity I have also checked to see if this bug occurs in other data that I have processed with XCP-D where there are multiple runs with "run-" in their name. When I looked at this data the design matrices were unique across runs so that is good.

[tsalo]

This isn't a scenario I had planned for, but I have noticed issues when one run's entities are a superset of another run's. To be honest, I've been treating this as a BIDS curation issue- e.g., I would have acq-1echo in the single-echo run's filename, as otherwise the inheritance principle technically applies (all things that apply to the single-echo run apply to the multi-echo run, since the single-echo run contains a subset of the multi-echo run's entities). That said, it seems like something XCP-D should handle, so I will take a look to see where the problem arises.

Any chance you can send me the stdout and stderr files from your run? My first guess is that the wrong confounds file is being selected by collect_run_data, in which case it would show up in the stdout with the Collected run data message.

[tsalo]

After taking a look at the relevant report.rst files from the working directory, it looks like the BOLD run without an acq entity grabbed the confounds file with acq-3echo in it.