I am working on re-analyzing some fMRI data, which was previously analyzed using SPM. 3dinfo shows that each of my runs are 173 time points. At 2 seconds a TR, I assume this should mean that the runs are 346 seconds each. My output from 3dDeconvolve confirms that the longest run is 346.0 seconds, and all the runs should be the same length. However, 3dDeconvolve appears to be cutting runs off at 344, which is causing the last trial in some of my functional runs to be considered unusable since they consistently onset a little after 344 (e.g. 344.285 or 344.59).
Does anyone have any idea what might be causing this inconsistency in how AFNI is reading my run lengths and how to deal with this problem? I don’t think the stim times are wrong because the original analysis yielded decent results, and it doesn’t make sense to me that AFNI and SPM would see the runs as being different lengths or that the onset times would be different for different analysis platforms. My scripts were generated using uber_subject.py. No TRs were removed for any of the functional runs and I have checked the length of each scaled run using 3dinfo, so the runs going into 3ddeconvolve are 173 time points.
Here is an example of the warning message I am getting:
*+ WARNING: ‘-stim_times 6’ (LOCAL) run#6 has 1 times outside range 0 … 344 [PSFB syndrome]
dataset TR being used is 2 s – unusable times follow
344.59
Time starts at t=0, and by the time of the linear regression, all voxels are assumed to be synchronized with the TR timing, as if the volumes were acquired at the beginning of each TR.
For example, assuming one run has only 3 time points, with TR=2s. Then the times for those volumes are t=0, t=2 and t=4, in seconds. While the “run” would last 6s, there would not be any data at time t=6, only up to t=4. So since the first volume is at t=0s, the last is at t=(N-1)*TR. Your last volume is at time t=344s.
To be precise, an event at time 344.285 does come after the acquisition of a few slices. And even for those slices the did occur after it, there will be no measurable BOLD impact to speak of (the ideal BOLD response takes about 2s to even start pulling away from 0). Really, there is little point in stimulating subjects at the very end of a run.
Anyway, that is why you are getting the warning, 344s is the time for the last volume.
Note that stimulus times can be shifted if needed, by 3dDeconvolve directly, or by afni_proc.py or timing_tool.py.
Yes, that does make sense. I hadn’t thought about the fact that slice time correction aligns everything to the start of the TR and that some slices would be finished before a stimulus occurring after the start of that final TR. I agree that it doesn’t make much sense to present stimuli this late - I’ve never encountered this issue in previous fMRI work because we have always left the final TRs empty to avoid such issues, but the data I am currently working with were collected many years ago.
In any case, thank you for your insights. This really does help. I didn’t want to lose those trials if they were actually valid, but now that I understand what is happening, I think it makes the most sense to allow 3dDeconvolve to run as is and leave out those few trials that started after the last TR. I don’t think there is much to gain from trying to alter the slice times to include them if there would not be enough time for the BOLD response anyway.
Thanks!
Katelyn
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.