Multi-echo fMRI grouped as run-XX instead of echo-XX in Dcm2Bids HPC/container environment

Software Support
, , , ,
1

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.

2

Silly question maybe, but are you using the same Dcm2Bids and dcm2niix versions between local and HPC environments? Tagging @SamGuay in case he just knows the answer regardless.

3

Yes, Dcm2bids is the same version in both environment (3.2.0),but there is a small dcm2niix version difference
Local:v1.0.20250505
HPC/container:v1.0.20250506
we were wondering if the difference could potentially affect how the multi-echo series are being grouped

4

Since the Dcm2Bids folks have not chimed in, I have one testing proposal and one suggestion to resolve this for you. I did this recently and it worked for me.

The testing proposal is to try explicitly defining the echo number in your custom entities, like that one above would be:

“custom_entities”: [“echo-1”, “task-rest”],

My suggestion if that still changes nothing is to reach out to the Dcm2Bids developers directly on a GitHub issue.

Good luck!

5

Hello,

Sorry for long delay… @shashank-519 can you share with us the difference between the output json files you get ? (sub-XXX_task-rest_echo-1_bold.json vs sub-XXX_task-rest_run-1_bold.json) My guess is dcm2niix slight changes should explain your different behaviors.

Best,

Arnaud

6

Thanks for the suggestion. I tried updating the config to explicitly define the echo labels, and it did change the output. Previously I was only getting separate run-* outputs, but now I am seeing outputs like run-01_echo-1_bold, run-01_echo-2_bold, and so on.The issue is that the resting-state scan is still being split into multiple runs in the HPC environment.

7

Hi Arnaud,

Thanks for taking a look. The behavior I’m seeing is that the same dataset and Dcm2Bids configuration produce different outputs between my local environment and the HPC/container environment. Locally, the resting-state acquisition is grouped as expected and generates task-rest_echo-1_bold through task-rest_echo-4_bold. In the HPC/container environment, the same acquisition is being split into multiple runs.

I also tried explicitly defining the echo labels in custom_entities based on a suggestion from Earl in this thread. That partially changed the output to run-01_echo-1_bold, run-01_echo-2_bold, etc., but the extra run grouping is still present.

8

Hey @shashank-519 ,

Can you share with me the json files associated please?

Thank you

Arnaud

9

Hi Arnaud,

I’ve included a subset of fields from one of the HPC output JSON sidecars below. Please let me know if there are any additional fields or files that would be useful for comparison.

{
  "SeriesNumber": 37,
  "EchoNumber": 1,
  "EchoTime": 0.0122,
  "RepetitionTime": 1.32,
  "ImageType": ["ORIGINAL", "PRIMARY", "FMRI", "NONE"],
  "ImageTypeText": ["ORIGINAL", "PRIMARY", "M", "MB", "TE1", "DIS2D"],
  "BidsGuess": [
    "func",
    "_acq-epfid2p3_dir-AP_run-37_echo-1_bold"
  ],
  "Dcm2bidsVersion": "3.2.0",
  "TaskName": "rest"
}

Thanks,
Shashank

10

Hey @shashank-519 ,

Sorry I meant the json files that go along with the nifti files.

I would need those files.

Thank you in advance.

Arnaud

11

I can share the JSON files directly.Would it be possibe to send them by email? If so,please let me know the best email address to send them.