Summary of what happened:
Hi,
I am running into an issue with multi-echo fMRI data being handled differently between my local setup and our HPC/container environment when using Dcm2Bids.
With the exact same DICOM dataset and same config file, the local setup groups the echoes correctly:
sub-XXX_task-rest_echo-1_bold.nii.gz
sub-XXX_task-rest_echo-2_bold.nii.gz
But on the HPC/container side, the same acquisition gets interpreted as separate runs:
sub-XXX_task-rest_run-01_bold.nii.gz
sub-XXX_task-rest_run-02_bold.nii.gz
So it seems the echoes are being interpreted differently in the containerized workflow.
I am already matching using both EchoNumber and EchoTime in the config.
Command used (and if a helper script was used, a link to the helper script or the command generated)
Command used:
dcm2bids \
-d /path/to/dicoms \
-p sub-XXX \
-c config.json \
-o /path/to/output
Version:
Version:
Local:
Dcm2Bids 3.2.0
dcm2niix v1.0.20250505
HPC/container:
Dcm2Bids 3.2.0
dcm2niix v1.0.20250506
Environment (Docker, Singularity / Apptainer, custom installation):
Local environment:
installed via pip
standard Linux workstation
HPC environment:
SLURM-based workflow
containerized execution using Docker
Same DICOM input and same Dcm2Bids config are being used in both environments.
Data formatted according to a validatable standard? Please provide the output of the validator:
Yes.
The locally generated dataset validates correctly and produces the expected echo-based naming.
The HPC-generated dataset also validates structurally as BIDS, but the multi-echo acquisitions are represented as separate runs rather than echo entities.
Relevant log outputs (up to 20 lines):
Expected:
sub-XXX_task-rest_echo-1_bold.nii.gz
sub-XXX_task-rest_echo-2_bold.nii.gz
sub-XXX_task-rest_echo-3_bold.nii.gz
sub-XXX_task-rest_echo-4_bold.nii.gz
Observed in HPC/container:
sub-XXX_task-rest_run-01_bold.nii.gz
sub-XXX_task-rest_run-02_bold.nii.gz
sub-XXX_task-rest_run-03_bold.nii.gz
sub-XXX_task-rest_run-04_bold.nii.gz
Screenshots / relevant information:
Example functional config entry:
{
"id": "task-rest",
"datatype": "func",
"suffix": "bold",
"custom_entities": ["echo", "task-rest"],
"criteria": {
"SeriesDescription": "Resting state me cmrr_mbep2d_xa60a",
"EchoNumber": 1,
"EchoTime": 0.0122,
"RepetitionTime": 1.32
},
"sidecar_changes": {
"TaskName": "rest"
}
}
Equivalent entries are defined for EchoNumber 2–4.
I also came across this related discussion:
rordenlab/dcm2niix#621
That issue seemed GE-specific, whereas in my case this is Siemens multi-echo data and explicit EchoNumber / EchoTime matching is already being used.
Would appreciate any suggestions on what might be causing this difference between the local and HPC/container environments.