Hello! I have a question similar to the one posted here that was never followed up on: https://afni.nimh.nih.gov/afni/community/board/read.php?1,164425,164425#msg-164425
I am struggling to understand what to choose for a sub_TR value for a beginner gPPI analysis I am working on. The experiment I am working on does not have stimulus onset times synced with TR grids, so I believe this is an option I need to use. The example on the help page (https://afni.nimh.nih.gov/CD-CorrAna) includes an example of using sub_TR of 0.1 initially, but then in the bottom example uses a value of 1 and states that it is “upsampling the data because of stim duration of 3s”. I am having a hard time understanding what this means and why the value of sub_TR=1 was chosen (over something like 0.1) given the context provided. Let me know if someone is able to provide clarification, and/or input to help understand this conceptually.
I replied to that old post (a little late). Thanks for pointing it out.
It seems likely that Gang used 1s as basically the greatest common divisor of 3s (stim) and 2s (TR), so that the resulting oversampled timing would indeed be “TR-locked” at 1s. Personally, I like to upsample more than that, as it makes the deconvolution/reconvolution steps close to inverses of each other. And that comes with nice properties rather than the side-effects that come with a slow filter. There is a similar but still different PPI analysis at AFNI_data6/FT_analysis/PPI. README.txt is actually the main script.
Does that seem reasonable?
I have a question on this topic. How do we determine if the stimulus onset times are synchronized with TR grids
That would be the case if every stimulus onset (and duration) were a multiple of the TR. It is usually not the case.
This would be true if TR=2s, for example, and all of the onsets in the stimulus timing file that is provided to afni_proc.py/3dDeconvolve are multiples of 2.
It can be verified on the command line using timing_tool.py using -show_tr_stats, e.g.
timing_tool.py -multi_timing AV*.txt -tr 2.0 -show_tr_stats
timing_tool.py -multi_timing times*.txt -tr 2.0 -show_tr_stats
Each of those examples just happens to have TR=2s, but that does not need to be the case.
Also, this just verifies the onsets. But for PPI, one would want each stimulus duration to be a multiple of the TR as well.
If either of those is not the case, it is probably better to oversample the timing.
Fantastic! Thank you so much & have a great weekend
Yes, thank you very much!