Hcp_bold_dcmethod parameter setting

Hi, Jure

I find that I have more diverse field map data at hand, and I think I should choose the appropriate --hcp_bold_dcmethod parameter depending on the field map sequence being scanned. Thanks to your previous help, I have figured out the parameter setting choice --hcp_bold_dcmethod=SiemensFieldMap when the field map data is MAG_IMAGES and PHA_IMAGES. But I am not sure how to set the --hcp_bold_dcmethod parameter when the field map data is dual echo field map data or otherwise. I didn’t find any specific parameter setting explanation and mapping naming suggestions for different field map sequences in the documentation.

Sincerely hope to get your help.

Best, YJia

Could you upload your session file here, so I can see a bit more what your data looks like?

Best, Jure

Sorry for the late reply, Jure.

Here are the session files corresponding to my five scanning sequences.

bold_rest + fieldmap_rest + Mag_Images + Pha_Images ph

device: SIEMENS|Verio|MRC40752

11  : ABI1_localizer [1/3] i00001 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
12  : ABI1_localizer [2/3] i00002 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
13  : ABI1_localizer [3/3] i00003 : TR(0.0086): PEDirection(j-): DwellTime(6.1e-06)
21  : ABI1_localizer2 [1/3] i00001 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
22  : ABI1_localizer2 [2/3] i00002 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
23  : ABI1_localizer2 [3/3] i00003 : TR(0.0086): PEDirection(j-): DwellTime(6.1e-06)
31  : t1_tirm_sag               : TR(1.23): PEDirection(i): DwellTime(6e-06)
41  : ABI1_t1iso_mprage         : TR(2.53): DwellTime(8.2e-06)
51  : t2_tse_tra_320_p2         : TR(4.21): PEDirection(i): DwellTime(7.1e-06)
61  : t1_tirm_tra               : TR(1.53): PEDirection(i): DwellTime(6e-06)
71  : ep2d_diff_3scan_trace_p2  : TR(16.265): PEDirection(j-): EchoSpacing(0.000545015): DwellTime(3.1e-06)
81  : ep2d_diff_3scan_trace_p2_ADC : TR(5.4): PEDirection(j-): EchoSpacing(0.000545015): DwellTime(3.1e-06)
91  : t2_tirm_tra_dark-fluid    : TR(5): PEDirection(i): DwellTime(6.9e-06)
101 : ABI1_fieldmap_rest [1/2] e1 : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
102 : ABI1_fieldmap_rest [2/2] e2 : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
111 : ABI1_fieldmap_rest e2_ph  : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
121 : ABI1_bold_rest            : TR(2): PEDirection(j): EchoSpacing(0.000530002): DwellTime(3.3e-06)
131 : ABI1_fieldmap_hardi [1/2] e1 : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
132 : ABI1_fieldmap_hardi [2/2] e2 : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
141 : ABI1_fieldmap_hardi e2_ph : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
151 : ABI1_diff_hardi_b0        : TR(13.755): PEDirection(j): EchoSpacing(0.000475): DwellTime(2.6e-06)
161 : ABI1_diff_hardi           : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
171 : ABI1_diff_hardi_ADC       : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
181 : ABI1_diff_hardi_TRACEW    : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
191 : ABI1_diff_hardi_FA        : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
201 : ABI1_diff_hardi_ColFA     : EchoSpacing(0.000344999)
221 : Mag_Images                : TR(0.028): DwellTime(1.3e-05)
231 : Pha_Images ph             : TR(0.028): DwellTime(1.3e-05)
241 : mIP_Images(SW)            : TR(0.028): DwellTime(1.3e-05)
251 : SWI_Images                : TR(0.028): DwellTime(1.3e-05)
261 : ep2d_tra_pasl_p2          : TR(3.5): PEDirection(j): EchoSpacing(0.000265001): DwellTime(3.4e-06)
271 : Perfusion_Weighted        : TR(3.5): PEDirection(j): EchoSpacing(0.000265001): DwellTime(3.4e-06)
281 : relCBF                    : TR(3.5): PEDirection(j): EchoSpacing(0.000265001): DwellTime(3.4e-06)

bold_rest + fieldmap_rest

device: SIEMENS|Verio|MRC40752

11  : ABI1_localizer [1/3] i00001 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
12  : ABI1_localizer [2/3] i00002 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
13  : ABI1_localizer [3/3] i00003 : TR(0.0086): PEDirection(j-): DwellTime(6.1e-06)
21  : ABI1_localizer2 [1/3] i00001 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
22  : ABI1_localizer2 [2/3] i00002 : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
23  : ABI1_localizer2 [3/3] i00003 : TR(0.0086): PEDirection(j-): DwellTime(6.1e-06)
31  : t1_tirm_sag               : TR(1.23): PEDirection(i): DwellTime(6e-06)
41  : ABI1_t1iso_mprage         : TR(2.53): DwellTime(8.2e-06)
51  : t2_tse_tra_320_p2         : TR(4.21): PEDirection(i): DwellTime(7.1e-06)
61  : t1_tirm_tra               : TR(1.53): PEDirection(i): DwellTime(6e-06)
71  : ep2d_diff_3scan_trace_p2  : TR(16.265): PEDirection(j-): EchoSpacing(0.000545015): DwellTime(3.1e-06)
81  : ep2d_diff_3scan_trace_p2_ADC : TR(5.4): PEDirection(j-): EchoSpacing(0.000545015): DwellTime(3.1e-06)
91  : t2_tirm_tra_dark-fluid    : TR(5): PEDirection(i): DwellTime(6.9e-06)
101 : ABI1_fieldmap_rest [1/2] e1 : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
102 : ABI1_fieldmap_rest [2/2] e2 : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
111 : ABI1_fieldmap_rest e2_ph  : TR(0.4): PEDirection(j): DwellTime(2.69e-05)
121 : ABI1_bold_rest_31         : TR(2.01): PEDirection(j): EchoSpacing(0.000530002): DwellTime(3.3e-06)
131 : ABI1_fieldmap_hardi [1/2] e1 : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
132 : ABI1_fieldmap_hardi [2/2] e2 : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
141 : ABI1_fieldmap_hardi e2_ph : TR(0.727): PEDirection(j): DwellTime(7.9e-06)
151 : ABI1_diff_hardi_b0        : TR(13.755): PEDirection(j): EchoSpacing(0.000475): DwellTime(2.6e-06)
161 : ABI1_diff_hardi           : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
171 : ABI1_diff_hardi_ADC       : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
181 : ABI1_diff_hardi_TRACEW    : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
191 : ABI1_diff_hardi_FA        : TR(13.7): PEDirection(j): EchoSpacing(0.000344999): DwellTime(2.6e-06)
201 : ABI1_diff_hardi_ColFA     : EchoSpacing(0.000344999)

cmrr_mbep2d_bold-rsfMRI-3mmISO + cmrr_mbep2d_bold-rsfMRI-3mmISO_SBRef + Mag_Images + Pha_Images ph

device: SIEMENS|Verio|MRC40754

11  : localizer [1/3] i00001    : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
12  : localizer [2/3] i00002    : TR(0.0086): PEDirection(i): DwellTime(6.1e-06)
13  : localizer [3/3] i00003    : TR(0.0086): PEDirection(j-): DwellTime(6.1e-06)
21  : MPRAGE                    : TR(2.53): DwellTime(1.03e-05)
31  : cmrr_mbep2d_bold-rsfMRI-3mmISO_SBRef : TR(2): PEDirection(j-): EchoSpacing(0.000510002): DwellTime(2.9e-06)
41  : cmrr_mbep2d_bold-rsfMRI-3mmISO : TR(2): PEDirection(j-): EchoSpacing(0.000510002): DwellTime(2.9e-06)
51  : MB_ep2d_diff-DTI_2.0mmISO_AP_SBRef : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
61  : MB_ep2d_diff-DTI_2.0mmISO_AP : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
71  : MB_ep2d_diff-DTI_2.0mmISO_AP_ADC : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
81  : MB_ep2d_diff-DTI_2.0mmISO_AP_TRACEW : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
91  : MB_ep2d_diff-DTI_2.0mmISO_AP_EXP : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
101 : MB_ep2d_diff-DTI_2.0mmISO_AP_FA : TR(5.62): PEDirection(j-): EchoSpacing(0.000475012): DwellTime(3.2e-06)
111 : MB_ep2d_diff-DTI_2.0mmISO_AP_ColFA : EchoSpacing(0.000475012)
131 : gre_field_mapping e2_ph   : TR(0.488): PEDirection(j-): DwellTime(3e-05)
141 : t2_blade_tra              : TR(4): PEDirection(i): DwellTime(4.3e-06)
151 : t2_tirm_tra_dark-fluid    : TR(8.5): PEDirection(i): DwellTime(6.8e-06)
161 : t2_spc_da-fl_irprep_sag_p2_iso : TR(5): PEDirection(i): DwellTime(2.5e-06)
171 : t1_tir_cor real           : TR(2.5): PEDirection(i): DwellTime(6.2e-06)
181 : t2_tse_cor_384            : TR(4): PEDirection(i): DwellTime(5e-06)
191 : Mag_Images                : TR(0.028): DwellTime(1.3e-05)
201 : Pha_Images ph             : TR(0.028): DwellTime(1.3e-05)
211 : mIP_Images(SW)            : TR(0.028): DwellTime(1.3e-05)
221 : SWI_Images                : TR(0.028): DwellTime(1.3e-05)

restfMRI_mb7_240_iso2.5mm + restfMRI_B0map_Echo2

11  : restfMRI_B0map_Echo2 [1/6] : TR(0.7)
12  : restfMRI_B0map_Echo2 [2/6] Eq_1 
13  : restfMRI_B0map_Echo2 [3/6] : TR(0.7)
14  : restfMRI_B0map_Echo2 [4/6] : TR(0.7)
15  : restfMRI_B0map_Echo2 [5/6] Eq_1 : TR(0.7)
16  : restfMRI_B0map_Echo2 [6/6] 
2011: t1_gre_fsp_3d_sag_iso1_NIF : TR(0.00694)
2021: t1_gre_fsp_3d_sag_iso1    : TR(0.00694)
2031: t1_gre_fsp_3d_sag_iso1_MPRCOR : TR(0.00694)
2041: t1_gre_fsp_3d_sag_iso1_MPRTRA : TR(0.00694)
5011: restfMRI_mb7_240_iso2.5mm_SaveBySlc : TR(2): PEDirection(j): EchoSpacing(0.00055)
8011: qsm_tra_0.65_2mm_MinIP [1/8] e10.4 : TR(0.0346)
8012: qsm_tra_0.65_2mm_MinIP [2/8] e14.1 : TR(0.0346)
8013: qsm_tra_0.65_2mm_MinIP [3/8] e17.8 : TR(0.0346)
8014: qsm_tra_0.65_2mm_MinIP [4/8] e21.5 : TR(0.0346)
8015: qsm_tra_0.65_2mm_MinIP [5/8] e25.2 : TR(0.0346)
8016: qsm_tra_0.65_2mm_MinIP [6/8] e28.9 : TR(0.0346)
8017: qsm_tra_0.65_2mm_MinIP [7/8] e3 : TR(0.0346)
8018: qsm_tra_0.65_2mm_MinIP [8/8] e6.7 : TR(0.0346)
8021: qsm_tra_0.65_2mm_SWI [1/8] e10.4 : TR(0.0346)
8022: qsm_tra_0.65_2mm_SWI [2/8] e14.1 : TR(0.0346)
8023: qsm_tra_0.65_2mm_SWI [3/8] e17.8 : TR(0.0346)
8024: qsm_tra_0.65_2mm_SWI [4/8] e21.5 : TR(0.0346)
8025: qsm_tra_0.65_2mm_SWI [5/8] e25.2 : TR(0.0346)
8026: qsm_tra_0.65_2mm_SWI [6/8] e28.9 : TR(0.0346)
8027: qsm_tra_0.65_2mm_SWI [7/8] e3 : TR(0.0346)
8028: qsm_tra_0.65_2mm_SWI [8/8] e6.7 : TR(0.0346)
8031: qsm_tra_0.65_2mm_M [1/8] e10.4 : TR(0.0346)
8032: qsm_tra_0.65_2mm_M [2/8] e14.1 : TR(0.0346)
8033: qsm_tra_0.65_2mm_M [3/8] e17.8 : TR(0.0346)
8034: qsm_tra_0.65_2mm_M [4/8] e21.5 : TR(0.0346)
8035: qsm_tra_0.65_2mm_M [5/8] e25.2 : TR(0.0346)
8036: qsm_tra_0.65_2mm_M [6/8] e28.9 : TR(0.0346)
8037: qsm_tra_0.65_2mm_M [7/8] e3 : TR(0.0346)
8038: qsm_tra_0.65_2mm_M [8/8] e6.7 : TR(0.0346)
8061: qsm_tra_0.65_2mm_DeltaP ph : TR(0.0346)
8071: qsm_tra_0.65_2mm_QSM [1/2] : TR(0.0346)
8072: qsm_tra_0.65_2mm_QSM [2/2] Eq_1 
9011: t2_mx3d_sag_flair_fs_NIF  : TR(4.8)
9021: t2_mx3d_sag_flair_fs      : TR(4.8)
10011: gre_fact_3d_tra_1.2x1.2x3.0_FF : TR(0.01883)
10031: gre_fact_3d_tra_1.2x1.2x3.0_water : TR(0.01883)
10041: gre_fact_3d_tra_1.2x1.2x3.0_fat : TR(0.01883)
10051: gre_fact_3d_tra_1.2x1.2x3.0_IP : TR(0.01883)
10061: gre_fact_3d_tra_1.2x1.2x3.0_OP : TR(0.01883)
11051: gre_WB_tra_IP             : TR(0.01463)
11061: gre_WB_tra_OP             : TR(0.01463)
11071: gre_WB_tra_M [1/6] e10.3  : TR(0.01463)
11072: gre_WB_tra_M [2/6] e12.4  : TR(0.01463)
11073: gre_WB_tra_M [3/6] e2.1   : TR(0.01463)
11074: gre_WB_tra_M [4/6] e4.1   : TR(0.01463)
11075: gre_WB_tra_M [5/6] e6.2   : TR(0.01463)
11076: gre_WB_tra_M [6/6] e8.3   : TR(0.01463)
11081: gre_WB_tra_P [1/5] e10.3_ph : TR(0.01463)
11082: gre_WB_tra_P [2/5] e12.4_ph : TR(0.01463)
11083: gre_WB_tra_P [3/5] e4.1_ph : TR(0.01463)
11084: gre_WB_tra_P [4/5] e6.2_ph : TR(0.01463)
11085: gre_WB_tra_P [5/5] e8.3_ph : TR(0.01463)
12011: pc_vessel_scout_CD        : TR(0.0163)
14021: asl_3d_tra_Ctrl           : TR(5)
14031: asl_3d_tra_Sub            : TR(5)
14061: asl_3d_tra_Tag            : TR(17.8796)
80011: T1_HIPPO                  : TR(0.00694)

restfMRI_mb8_PA_1.8mm_Ref + restfMRI_mb8_PA_1.8mm + se_epi_field_AP_1.8mm + se_epi_field_PA_1.8mm + B0fieldmap_B0Map + B0fieldmap_Echo1
This session is from uMR890 from UIH, and for some reason the number of sequences imported in session.txt is not the same as the real number of scans (many scan sequences are not loaded correctly). I will provide you with session.txt and the full serial scan folder separately. I will provide you with session.txt and the full serial scan folder separately. But since it has spin echo data, I thought I’d set --hcp_bold_dcmethod to TOPUP

device: UIH|uMR  890|uMR890

3011: t1w_A3.22_iso0.8mm_CBCP_NDC : TR(0.0065)
3021: t1w_A3.22_iso0.8mm_CBCP   : TR(0.0065)
4011: t2w_A3.83_iso0.8mm_CBCP_NDC : TR(3)
4021: t2w_A3.83_iso0.8mm_CBCP   : TR(3)
8021: B0fieldmap_Echo2 e2       : TR(0.697)
9021: restfMRI_mb8_PA_1.8mm_CBCP_SaveBySlc : TR(0.8): PEDirection(j): EchoSpacing(0.00061)
11011: dMRI_b0_mb4_AP_1.5mm_CBCP_SaveBySlc : TR(3.28): PEDirection(j-): EchoSpacing(0.00068)
13011: dMRI_3_1_0.5K_mb4_AP_1.5mm_CBCP_SaveBySlc : TR(3.28): PEDirection(j-): EchoSpacing(0.00068)
15011: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_T1Map e6 : TR(0.0481)
15031: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_PDW e6 : TR(0.0481)
15041: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_T1W e6 : TR(0.0481)
15051: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_PDMap e6 : TR(0.0481)
15061: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_R2Star e6 : TR(0.0481)
15081: MTP_ACS_0.8x0.8x1.6_CBCP_MTP_B1Map e6 : TR(0.0481)
15121: MTP_ACS_0.8x0.8x1.6_CBCP_SWI : TR(0.0481)
15131: MTP_ACS_0.8x0.8x1.6_CBCP_DeltaP [1/2] ph : TR(0.0481)
15132: MTP_ACS_0.8x0.8x1.6_CBCP_DeltaP [2/2] ph_Eq_1 
15141: MTP_ACS_0.8x0.8x1.6_CBCP_QSM [1/2] : TR(0.0481)
15142: MTP_ACS_0.8x0.8x1.6_CBCP_QSM [2/2] Eq_1 
80011: Motion Curve [1/5]        
80012: Motion Curve [2/5]        
80013: Motion Curve [3/5]        
80014: Motion Curve [4/5]        
80015: Motion Curve [5/5]

For the above five cases, case ① can set --hcp_bold_dcmethod to SiemensFieldMap as you suggested to me before, and use MAG_IMAGES and PHA_IMAGES for correction.

In case ② I’m not sure how to set the --hcp_bold_dcmethod parameter, and what sequence to use as the field map, and the naming scheme of mapping.txt.

Case ③ is multi-band fmri data and it has reference images and MAG_IMAGES and PHA_IMAGES, how should I set it up and is it the same as case ①?

Case ④ is also multi-band data and it has restfMRI_B0map_Echo data, since it comes from UIH, I am not sure if I can set the --hcp_bold_dcmethod parameter correctly and name it correctly in mapping.txt.

Case ⑤ is still multi-band data (from UIH) and it has a B0fieldmap_B0Map image, a reference image
and se-epi image, is it best to use the se-epi image for TOPUP correction?

Best, YJia

Hi,

Unfortunately, I am not an expert on MRI sequences. I think one would be needed to unpack all this :slight_smile: .

Are these sessions belonging to the same study? In a single study you usually want all sessions to be acquired using the same protocol. If they are not the differences you get in your analyses might be related to different acquisition and not some inherent properties you are investigating. Data harmonization in such cases can be tricky.

The rule of thumb for setting relevant parameters with a Siemens scanner is:

  1. If you have spinecho fielmap pairs (e.g., se_epi_field_PA and se_epi_field_AP) you should use TOPUP as this will give the best results. For an example of this look at our quick start.
  2. If you have fieldmap magnitude and phase, you should use SiemensFieldMap. You probably do not need an example here, as we already configured this for one of your sessions.
  3. If you do not have anything, set the relevant parameters to NONE. It will work, just the results will be of a bit lower quality.

Best, Jure

Hi, Jure

All of this data will be used in the analysis of the Alzheimer’s study, which does have a large variation in scan sequences due to being from multiple centers.

Of the five cases mentioned above, case 1 has been resolved with your help (thanks again Jure for the help you gave me :grinning:)

The two fieldmap_rest data in case 2 (we can call them fieldmap_rest1 and fieldmap_rest2) after the format conversion was done, fieldmap_rest1 generated two .nii files and fieldmap_rest2 generated one .nii file. Some of their useful information is as follows. Can I consider this as a double echo field map? Since its from Simens, I’m guessing I can set hcp_bold_dcmethod to SiemensFieldMap, but I’m not sure how to change the nomenclature in mapping.txt to load it correctly.

# fieldmap_rest1 - first nii file
"EchoNumber": 1,
"EchoTime": 0.00492,
"RepetitionTime": 0.4,
"PulseSequenceDetails": "%SiemensSeq%\\gre_field_mapping",
"DwellTime": 2.69e-05,
"PhaseEncodingDirection": "j"

# fieldmap_rest1 - second nii file
"EchoNumber": 2,
"EchoTime": 0.00738,
"RepetitionTime": 0.4,
"PulseSequenceDetails": "%SiemensSeq%\\gre_field_mapping",
"DwellTime": 2.69e-05,
"PhaseEncodingDirection": "j"

#fieldmap_rest2 - first nii file
"EchoNumber": 2,
"EchoTime": 0.00738,
"RepetitionTime": 0.4,
"EchoTime1": 0.00492,
"EchoTime2": 0.00738,
"PulseSequenceDetails": "%SiemensSeq%\\gre_field_mapping",
"DwellTime": 2.69e-05,
"PhaseEncodingDirection": "j"

The data in case 3 also has Mag_Images and Pha_Images, isn’t it also possible to ignore the reference images and still preprocess Mag_Images and Pha_Images as field maps using the same method as in case 1?

The data for case four is more problematic, with its restfMRI_B0map related data being reformatted to give six .nii files with the following detailed parameters. According to the EchoTime information in the json files, its phase difference is 2.46ms, can I use this phase difference in the dual echo field map information for correction?

#restfMRI_B0map_CF203Hz_1 - first nii file
"EchoTime": 0.00246,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j"
#restfMRI_B0map_CF203Hz_1 - second nii file
"EchoTime": 0.00492,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j"
# restfMRI_B0map_Echo1_1 - first nii file
"EchoTime": 0.00492,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j"
# restfMRI_B0map_Echo1_1 - second nii file
"EchoTime": 0.00492,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j"
# restfMRI_B0map_Echo2_1 - first nii file
"EchoTime": 0.00738,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j"
# restfMRI_B0map_Echo2_1 - second nii file
"EchoTime": 0.00492,
"RepetitionTime": 0.7,
"PhaseEncodingAxis": "j",

In case 5, since it has se_epi_field data, I think it’s better to prioritize TOPUP corrections, and for subsequent naming, do I just refer to the naming of mapping.txt in quickstart?

Best, YJia

Hi,

Case 2

Map 102 to FM-Magnitude and 111 to FM-Phase. Just like we did with case 1. If the exact image number does not match across sessions with this acquisition type then map by name. If you want to complicate your life, you can also map both magnitudes e1 and e2, and QuNex, HCP Pipelines will average them. To do this you do:

111 => FM-Phase: fm(1)
101 => FM-Magnitude: fm(1)
102 => FM-Magnitude: fm(1)

This should then work with the SiemensFieldMap option.


Case 3

Yes, you can use Mag_Images and Pha_Images ph just like in case 1.


Case 4

The SiemensFieldMap option requires the magnitude/phase pair which I do not see in there. You also do not have SE-FM acquisitions, so I think your option here is NONE?


Case 5

This looks like it could be processed with TOPUP. Yes, adjusted mapping from quickstart should do the trick here.


One thing to consider would be to process all with the NONE option. This way the processing will be consistent across sessions. It will be suboptimal for some sessions, but maybe consistent processing is better as you are not getting some analytical differences due to differences in processing.

Cheers, Jure

1 Like

Hi, Jure

I’m in the process of testing case 2, 3, and 5 as you suggested, and hopefully it will run successfully.

Regarding case4, this field map data does differ significantly from SiemensFieldMap. However, when I was checking the information, I found that Philips has a similar B0 map field map sequence, which does not need to collect the phase difference through two different echo times (ΔTE) to calculate the B0 field map like SiemensFieldMap (we can get the B0 map directly). I doubt that it is possible to set the parameter to PhilipsFieldMap, but I haven’t seen the Philips data and I don’t know the nomenclature of the mapping.txt after the parameter is set to PhilipsFieldMap, so I really need your help.

To make it easier for you and other MRI sequence experts, I’ve attached screenshots of the field map data involved in case4 below, which I hope will help you in your judgment. There are a total of three EchoTime below.

# EchoTime
0.00246 - `restfMRI_B0map_CF203Hz_1`.
0.00492 - `restfMRI_B0map_CF203Hz_1a`, `restfMRI_B0map_Echo1_1`, `restfMRI_B0map_Echo1_1a`, `restfMRI_B0map_Echo2_1a`
0.00738 - `restfMRI_B0map_Echo2_1`

# restfMRI_B0map_CF203Hz_1
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00246,
"RepetitionTime": 0.7

# restfMRI_B0map_CF203Hz_1a
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00492,
"RepetitionTime": 0.7


# restfMRI_B0map_Echo1
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00492,
"RepetitionTime": 0.7

# restfMRI_B0map_Echo1_1a
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00492,
"RepetitionTime": 0.7


# restfMRI_B0map_Echo2_1
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00738,
"RepetitionTime": 0.7

# restfMRI_B0map_Echo2_1a
"ProtocolName": "restfMRI_B0map",
"ImageType": ["ORIGINAL", "PRIMARY", "M"],
"EchoTime": 0.00492,
"RepetitionTime": 0.7


I have 500+ cases of data in my hands that are all such field map sequences, so I’d really like to know how to use its suspect field map data to correct it to get a good processing result. (Though this Multi-band data with MultibandAccelerationFactor=7 it’s TR is surprisingly 2s and SliceThickness is 2.5mm, which is very confusing to me with such parameter settings :thinking:)

Best, YJia

Oh, so the data in case 4 is actually from a Philips scanner and not Siemens? The others are Siemens right, while the one without fIeldmaps seems to be UHI? Because if you have GE in there, than that is also a different parameter value.

Also, cases 1, 2, 3, 5 are now sorted out?

Best, Jure

Hi, Jure

No! case1, 2, and 3 are from Siemens and case4, 5 are from UIH.

Case5 has spin echo data, so I can refer to quickstart naming and use TOPUP correction.

But case4 uses B0map data, and I’m not sure if setting it to PhilipsFieldMap works. Some of this B0map data seems to look like Magnitude (restfMRI_B0map_Echo1_1) and some like Phase (restfMRI_B0map_CF203Hz). And the EchoTime, ΔEchoTime of these data are similar to the SiemensFieldMap, so it’s not clear to me if these actually play the role of the Magnitude and Phase in the SiemensFieldMap? If not, I’d like to know the data naming and required parameters involved in PhilipsFieldMap. If neither of these settings are OK, then perhaps I do need to set bold_dcmethod to NONE.

The images of the three B0map sequences obtained from the case4 scan after format conversion are shown in the previous reply, and I have also provided their corresponding EchoTime. If you need any other information, I can provide it for you (but I have to say that the json file information for such B0map sequences is so scarce)

Case1 has been resolved and I’m currently testing case2, 3, 5 to see how they run.

Best, YJia

The PhilipsFieldMap option requires the usual Magnitude and Phase pair. There are some specifics about how these fieldmaps are handled later on, which is why there are vendor specific settings, e.g. PhilipsFieldMap, SiemensFieldMap, GEFieldMap.

I cannot say whether any of the above is useful for UIH, as I have never worked with such data. Based on the session.txt I would say UIH would require specific treatment to get into the desired format for HCP Pipelines. I would say that NONE looks like the option to pick right now. I have forwarded the question to two of my colleagues who know much more about fieldmaps, let’s see if they have something meaningful to add here.

Cheers, Jure

Hi, Jure

You’ve been a lot of help to me already and it’s really appreciated! :grinning:

Best, YJia :sparkling_heart:

Hi,

I talked with a colleague about your case 4 and he also said that the setting NONE seems like the only viable route forward here.

Best, Jure

Hi, Jure

I have processed these data separately as you suggested. For case 4 the UIH data is set to NONE and the results are acceptable, but there is another problem with this strange batch of data.

Normally, we don’t need Multi-band data for slice-timing, but I suspect that the parameters of this batch of data are set incorrectly (as evidenced by the fact that it has MultibandAccelerationFactor=7, but surprisingly, the TR is still 2s), so I think that I still need to do the slice-timing process for this kind of Multi-band data. So I think I still need to do slice-timing for this kind of Multi-band data, but I’m not sure how to set the _hcp_bold_slicetimingfile parameter after setting _hcp_bold_doslicetime to True?

Best, YJia

Hi,

Relevant documentation about slice timing can be found at hcp_fmri_volume — QuNex documentation. Basically, you turn it on or off with the hcp_bold_doslicetime parameters. And then use hcp_bold_slicetimerparams and hcp_bold_slicetimingfile to provide additional details for the FSL slicetimer. Slice timing file is used for the --tcustom parameter of FSL slicetimer, you can also specify this parameter through hcp_bold_slicetimerparams and achieve the sama result.

If you search the documentation for slice timing there are some other pieces of information there that might help.

Best, Jure

Hi, Jure

I found the --slice_timing_info parameter in setup_hcp which, according to the description, prepares a slice timing file for me when it’s set to yes. this way, I can use it for slice timing in hcp_fmri_volume.

In order to be able to confirm that the whole process is plausible, I got 10 data collected by the same device reprocessed. But in the import_dicom step I found some unusual warning.

---> 5010   501      restfMRI_mb7_240_iso2.5mm_SaveBySlc    240   [TR 2000.00, TE  30.00]   PID-20221216-112320-0194   2022-12-16 11:40:11
     WARNING: number of frames in nii does not match dicom information: 48 vs. 240 frames
     WARNING: no slice number information, use qunex reslice manually to correct /home/jiayf/qunex/ADBD/sessions/BDUA_001/nii/5011.nii.gz

This means that not all dicoms are formatted correctly, I checked the messages under sessions/<id>/dicom and sessions/<id>/nii and the situation is the same as the reported error, I will provide you with DICOM-Report.txt and comlogs.

DICOM-Report.txt (2.3 KB)
done_import_dicom_2025-03-31_02.21.52.106654.log (95.8 KB)

When I checked the forum for that reported error, I found that other users were experiencing similar problems. [RESOLVED] Import_dicom not reading all the diffusion data - Issues - QuNex Discourse

I’m going to do what he did and manually replace the files in the nii folder with the ones I got from dcm2niix.

Best, YJia

Hi,

Yes, your plan sounds reasonable. Let me know how it goes.

Best, Jure

Hi, Jure

I’m currently following the above plan and I’ll be able to let you know how it turns out soon, but while I’m waiting for the results, I have a few questions I’d like to ask you.

  1. For the multi-band data, I can get BOLD_slicetimer.txt by setting --slice_timing_info="yes" in the setup_hcp step, and then in hcp_fmri_volume set --hcp_bold_ doslicetime="TRUE" and --hcp_bold_slicetimingfile="TRUE" in hcp_fmri_volume to call _slicetimer.txt to do the slice timing. Can I also get the SliceTiming information and do the slice timing operation automatically like this for normal single band data? (I don’t need to manually set the number of scanning slices and scanning order) If so, does this mean I can process fmri data with different SliceTiming conditions together in parallel? (e.g. multi-band & single band, different slice slices, odd & even scanning order)
  2. In HCPpipeline, hcp_fmri_volume’s processing of fmri data roughly consists of slice timing, motion correction, structure-function registration, denoising & filtering and spatial smoothing. In the denoising & filtering step, hcp_fmri_volume seems to regress off the head motion, physiological noise, and white matter signals, preserving the global signal. This is normal for the commonly used gray matter functional connectivity analysis, but if I do white matter functional connectivity analysis, are there some parameters that can be modified to preserve the white matter signal for subsequent functional connectivity analysis using the white matter segmentation results to extract the time series from the white matter region?
  3. Regarding the above mentioned issue of not completing the format conversion correctly when executing import_dicom, this may not be an isolated case, I think I need to check the data properly after completing this step and manually format and overwrite the problematic data. (too bad :face_without_mouth:)
  4. Normally I just set the --scheduler parameter like this. I usually only modify time and mem-per-cpu, which seems fine when processing fewer tasks. However, when I parallelize more tasks (--parjobs=10,--parsessions=4,mem-per-cpu=64G), I find that the parallel processing is not as effective as it could be (only about a third of the tasks are processed in the expected time), and I’m wondering if it’s because I haven’t set the cpus-per-task parameter so that the CPU is not fully utilized? Please tell me how you usually adjust the mem-per-cpu and cpus-per-task in the scheduler parameter according to the amount of data to be processed in parallel. With your help I think I can tweak these parameters more boldly
--scheduler="SLURM,jobname=prefree,time=1-00:00:00,mem-per-cpu=50G"

Best, YJia

Hi!

1/ If each session has the *_slicetimer.txt in there then QuNex will use the one belonging to each session and not the same one across all sessions. Through the batch file, you can also set session level parameters and enable this functionality only for a couple of sessions. For example:

---
session: NK4
subject: NK4
dicom: /Volumes/pooh/NK/fMRI/PD-fcMRI-TMS/sessions/NK04/dicom
raw_data: /Volumes/pooh/NK/fMRI/PD-fcMRI-TMS/sessions/NK04/nii
hpc: /Volumes/pooh/NK/fMRI/PD-fcMRI-TMS/sessions/NK04/hpc

# ---------- session level parameters ----------
_hcp_bold_doslicetime: "TRUE"

02: T1w:             T1w 0.7mm N2
03: T2w:             T2w 0.7mm N2
...

Would enable hcp_bold_doslicetime only for the session NK4 and use the default ("FALSE") for all other sessions. There is a bug here as you need to prefix the session level parameters with _, prefixing with -- does not work as it should. The bug has already been fixed and the patch will be released in the next version.

2/ This is outside of the scope of my expertise, I think a better location for this question would be the HCP Pipelines user group (https://groups.google.com/a/humanconnectome.org/g/hcp-users).

3/ What is the import_dicom issue here? If the conversion tool is not working as you would like, you can use a different one, see import_dicom — QuNex documentation. The default tool is the one that gives the best results in most of scenarios. But there are cases when another tool might perform better, which is why we have the tool parameter.

4/ This is tricky to do optimally as it is system and data dependent. Also, if you optimize processing for one session it might be suboptimal for another unless the data acquisition protocol matches completely.

On our end, we usually process each session in its own job as this gives us better control over what is happening. I imagine you are setting the parjobs parameter because you hit the job limit in your case case? If we are not hitting the limit, we usually do not set parjobs and we leave parsessions to its default (1).

When we hit the job limit, we often use the SLURM job array. Note that this functionality is currently supported only for HCP Pipelines commands (since they are the most computationally expensive). See Parallel Execution and Scheduling of QuNex commands — QuNex documentation.

We set cpus-per-task depending on the amount of work inside one session, which is session dependent. A rule of thumb is to set this to the number of BOLDs in the sessions and also set parelements to that value in order to process those BOLDs in parallel. Even if you have a single BOLD, surface processing is parallel and having 2 or 4 CPUs will speed everything up.

Best, Jure

Hi, Jure

Thank you very much for your answer.

1/ Most of the data I have requires slice timing, so the *_slicetimer.txt that setup_hcp generates for each session should help me to achieve individual slice timing for all of them!

2/ Thanks for the guidance, I’ll go to the HCP group and start a question on this issue.

3/ The import dicom directive does not convert all dicom files to nii format correctly (many time points are lost). The format conversion I did manually using dcm2niix was correct, so I thought I’d set --tool="dcm2niix"

4/ I still have touching the SLURM limit at the moment, I thought before that there was a memory limit for submitted jobs (500G), but I tried submitting 10 jobs (10*64=640G) and it works fine. So maybe I can submit a lot of jobs if there are not many people using the CPU in the short term? Regarding the parelements parameter, all my sessions have only one BOLD data, so both parelements and cpus-per-task should be set to 1? Regarding the parsessions parameter, to be conservative, with 64G of RAM I usually only set it to 4, to avoid memory overflow that can lead to processing errors. So when I was processing 110 session data before, I was expecting to process 40 sessions in parallel (4 * 10), and hopefully it would be done in three batches.

--parjobs=10
--parsessions=4
--scheduler="SLURM,jobname=free,time=4-00:00:00,mem-per-cpu=64G"

5/ I finished the hcp_fmri_volume processing, but ran into strange problems with the hcp_fmri_surface processing, such that it ended after only a few minutes of running. The relevant Logs are as follows.
done_hcp_fmri_surface_1_BDUA_001_2025-03-31_15.36.42.009137.log (7.3 KB)

done_hcp_fmri_volume_1_BDUA_001_2025-03-31_08.51.12.664130.log (91.3 KB)

batch.txt (5.4 KB)

Best, YJia

4/ Like I said these things are very system specific, so you will have to optimize on your end. Usually there are limits about how many resources you can allocate and for how much time, but these are set by your system admins.

There is a decent amount of parallelism in some processing steps (e.g., hcp_fmri_surface), so having cpus-per-task more than 1 will help there as well even though you have a single BOLD.

Right now, you are running 4 sessions in parallel using a single CPU and 64 GB of mem. For more demanding steps (e.g. surface), 4 CPUs would not hurt here. Also with a single CPU, you only have 64 GB of mem, so 16 GB per session, which can be too low. Adding cpus-per-task=4 should significantly improve this.

5/ No idea what is happening here. The call from QuNex to HCP pipelines looks OK. It seems like all the steps within the HCP pipelines finish instantly. What if you run this over a single session within a single job?

Best, Jure