Understanding "num TRs per stim (orig)" in the @ss_review_driver

Hi Experts,

I am having a difficult time understanding how the the @ss_review_driver output “num TRs per stim (orig) 111 66 66 103 111 66 66 103” is being calculated for my task. My study has 540 total TRs (2 seconds per TR or 1080 seconds). It is a block design in which the 540 TR task is split in half (540sec or 270TRs each). During each half they repeat a task 3 times. There are 4 conditions (Base 60sec., Script 30sec., Recall 30sec., Rest 60sec.) that make up 1 task. I have a difficult time understanding how the “111 66 66 103…” pattern fits in my dataset.

My script can be seen below, and the timing files are below that at the very end.

Thank you kindly for the time!

I look forward to understanding this better :slight_smile:




Created by Jessica Hanson on 7/26/16.

Copyright 2012 LaurenTaubitz!. All rights reserved.

#This script runs afni_proc.py for the IRC_PTSD Study for the IMAGERY conditions ONLY!

#Removes stack size allocation limits to prevent killing this script
#ulimit -s unlimited

#Sets the folder containing the subject data
setenv subfolder /media/larson_buffalo/MRI7/IRC_PTSD/Data

#Creates a variable called “study” and sets its value.
set study = IRCPTSD

setenv scriptfolder /media/larson_buffalo/MRI7/IRC_PTSD/Scripts/Linear_Imagery

setenv timing_files /media/larson_buffalo/MRI7/IRC_PTSD/Scripts/Linear_Imagery/Timing_Files

#Opens the scripts directory
cd /media/larson_buffalo/MRI7/IRC_PTSD/Scripts/Linear_Imagery

foreach subject (sub16)

sub80 sub116 sub269 sub sub sub sub)

#afni_proc.py generates a script that does all single-subject processing through 3dDeconvolve
-subj_id ${subject}
-script proc_${subject}.UPDATED_TIMING_FILES.imagery.results
-out_dir ${subfolder}/${subject}/${subject}.UPDATED_TIMING_FILES.imagery.results
-dsets ${subfolder}/${subject}/${subject}.${study}.neutral_im+orig.HEAD
-copy_anat ${subfolder}/${subject}/${subject}.${study}.spgr+orig
-do_block align tlrc
-tcat_remove_first_trs 3
-volreg_align_to third
-regress_stim_times ${timing_files}/imagery_stim_times.*.1D
-regress_stim_labels im_neut_base im_neut_script im_neut_recall im_neut_rest
im_trauma_base im_trauma_script im_trauma_recall im_trauma_rest
-regress_basis_multi ‘BLOCK(60,1)’ ‘BLOCK(30,1)’ ‘BLOCK(30,1)’ ‘BLOCK(60,1)’
‘BLOCK(60,1)’ ‘BLOCK(30,1)’ ‘BLOCK(30,1)’ ‘BLOCK(60,1)’
-regress_censor_motion 0.3
-regress_censor_outliers 0.1
-gltsym ‘SYM: +im_neut_recall -im_neut_base’ -glt_label 1 im_neutrecall_vs_base
-gltsym ‘SYM: +im_trauma_recall -im_trauma_base’ -glt_label 2 im_traumarecall_vs_base
-gltsym ‘SYM: +im_neut_rest -im_neut_base’ -glt_label 3 im_neutrest_vs_base
-gltsym ‘SYM: +im_trauma_rest -im_trauma_base’ -glt_label 4 im_traumarest_vs_base
-gltsym ‘SYM: +im_trauma_recall -im_neut_recall’ -glt_label 5 im_traumarecall_vs_neutrecall
-gltsym ‘SYM: +im_trauma_rest -im_neut_rest’ -glt_label 6 im_traumarest_vs_neutrest
-gltsym ‘SYM: +im_trauma_script -im_neut_script’ -glt_label 7 im_traumascript_vs_neutscript
-gltsym ‘SYM: +im_trauma_base -im_neut_base’ -glt_label 8 im_traumabase_vs_neutbase
-jobs 4
-regress_run_clustsim no

#This runs the script generated by afni_proc.py
tcsh -xef proc_${subject}.UPDATED_TIMING_FILES.imagery.results |& tee ${scriptfolder}/output.${subject}_UPDATED_TIMING_FILES.imagery_proc_script

#Ends the foreach subject loop


0.0 180.0 360.0

60.0 240.0 420.0

90.0 270.0 450.0

120.0 300.0 480.0

0.0 180.0 360.0

60.0 240.0 420.0

90.0 270.0 450.0

120.0 300.0 480.0

Hi Jessica,

Those TR counts are for the BOLD responses - for how
many time points is each non-zero. Since rest comes
after task in each run, the computation is more simple
for the task terms (no BOLD response goes off the end
of a run).

The 60s Base task, when modeled with BLOCK(60,1) say,
has a 75s response curve, which probably comes out to
37 non-zero time points. Having 3 such blocks means
111 non-zero time points in total. The 2 30s tasks
have ~45s ideal BOLD responses, which are probably
non-zero for 22 time points, and 3 of those is 66.

Rest is the anomaly, as it goes to the end of a run.
The first 2 in a run do not go off, giving 74=37+37
time points. And then another 29 non-zero time
points at the end of the run gives 103.

However, you should probably not be modeling rest
at all. This is very close to a multi-collinear
system, and I suspect 3dDeconvolve is showing some
warnings. Is it?

Also, since these blocks are so long, I expect
the baseline model might be a confounding effect.

  • rick

Hi Rick,

This is VERY helpful, thank you! I’ll pass you concerns along to our PI.

Have a great weekend!