RT error (mismatch) running afni_procpy

AFNI Message Board
1

AFNI version info (afni -ver): AFNI_23.1.10

when I run afni_procpy on my fmri data I get the following error message

udosmacprohighs:~/M02_analysis] udowill% ./M02.ap.align
-- applying input view as +orig
-- template = 'TT_N27+tlrc', exists = 1
-- will use min outlier volume as motion base
-- including default: -radial_correlate_blocks regress
-- including default: -find_var_line_blocks tcat
** TR of 3.01 != run #1 TR 3.0125
----------------------------------------------------------------------
** failed command (create_script):

  afni_proc.py -subj_id M02.align -dsets M02/M02_epi_r1+orig.nii              \
      M02/M02_epi_r2+orig.nii M02/M02_epi_r3+orig.nii M02/M02_epi_r4+orig.nii \
      M02/M02_epi_r5+orig.nii -do_block align tlrc -copy_anat                 \
      M02/M02_struct_brain.nii -tcat_remove_first_trs 0 -blur_in_mask yes     \
      -volreg_align_to MIN_OUTLIER -volreg_tlrc_warp -volreg_align_e2a        \
      -regress_stim_times M02/wpsM02_pseu.txt M02/wpsM02_word.txt             \
      -regress_stim_labels Pseu Wrd -regress_basis 'BLOCK(30,1)'              \
      -regress_make_ideal_sum sum_ideal.1D -regress_censor_motion 0.3         \
      -regress_opts_3dD -jobs 2 -gltsym 'SYM: Pseu -Wrd' -glt_label 1 P-W     \
      -regress_reml_exec -regress_est_blur_epits -regress_est_blur_errts

It seems the RT of my data (3.0125) clashes with what the scripts expects. It is not clear to me where (in which module) the conflict arises; any advice as to what I need to do to get the script running would be much appreciated.
Udo

2

That means the TRs are not consistent across the runs. It is possible that those numbers are rounded, and might even be closer together than 0.0025 s, but you might want to be sure of why they differ at all. Consider:

3dinfo -tr -prefix M02/M02_epi_*+orig.nii
  • rick
3

Rick,
thanks for the hint that it could be my data that contain conflicting information. And you were right, indeed some of my epi runs have a TR of 3,01 and others of 3.0125. It seems that this is due to an old dciom2nifi app (which I used years ago - can't remember which it was), and not due to the scanner: I went back to the original DICOM files and they show a TR of 3000ms for al files. I'll correct the header info and run afni_procpy again. You may have made my day, Thanks
Udo

4

Hi Udo,

That's good news, thanks for the udpate.

-rick