3dREMLfit doesn't drops output sub-BRIKs when using stim_times_IM

AFNI Message Board
,
1

AFNI version info (afni -ver): Precompiled binary linux_openmp_64: Apr 7 2023 (Version AFNI_23.1.00 'Publius Helvius Pertinax')

Hello!

I'm using the -stim_times_IM flag in 3dDeconvolve to model single-trial betas. As suggested for univariate analyses, I've been using 3dDeconvolve to generate a design matrix, and then using 3dREMLfit to actually run the regression.

But I have been running into two problems when there are empty regressors (e.g., when the onset of the single trial being modelled overlaps with a time-point censored for high motion):

  1. The -GOFORIT flag in the 3dDeconvolve command doesn't carry over to the 3dREMLfit command that is generated. As a result 3dREMLfit fails because of the empty regressor. This isn't a huge deal, since I manually added that flag to the 3dREMLfit command. But I thought I'd report it anyway!
  2. (This one is more important, I think) In my experience (and as per the documentation for both commands), when there is an empty regressor in 3dDeconvolve, there is an all-zero sub-BRIK in the output stats file that corresponds to the empty regressor. But it seems that 3dREMLfit drops these regressors altogether, such that there are a fewer sub-BRIKs in the output than there were trials.
    I would end up excluding the trials with the empty regressors anyway. But dropping them in the output misaligns all the trial numbers, because certain trials are dropped, and the rest are numbered in a sequential manner (e.g., trial 2 gets dropped, and trial 3 is named 2, 4 is named 3, and so on).
    I think in the past, when this happened with the -stim_times option, there was an all-zero sub-BRIK in the 3dREMLfit output as expected. So it may be the case that this is limited to the -stim_times_IM option.
    Is this behaviour expected? Am I missing a flag somewhere?

Thank you!
Mrinmayi

2

Mrinmayi,

I don't have answers to your questions. I'm simply curious about your motivation for running 3dREMLfit. Are you finding that the point estimates from 3dDeconvolve are insufficient? Perhaps you're seeking both point estimates and their associated uncertainty? Or is there another reason behind this choice?

Gang Chen

3

Hi Mrinmayi,

I think Bob wanted to keep the GOFORIT aspect from being automatic. If you are running this via afni_proc.py, GOFORIT should be included with -regress_opts_reml (as it would be using -regress_opts_3dD for 3dDeconvolve).

Point #2 is one that I was not aware of. Is this happening due to censoring?

  • rick
4

Thanks a lot for your responses!

I'm simply curious about your motivation for running 3dREMLfit . Are you finding that the point estimates from 3dDeconvolve are insufficient? Perhaps you're seeking both point estimates and their associated uncertainty? Or is there another reason behind this choice?

Yes - when I run univariate analyses, I use 3dREMLfit because I do group-level analysis in 3dMEMA. But the trial-by-trial models are meant for multivariate (RSA/MVPA) type analyses, so maybe it's not required, and I can stick to 3dDeconvolve? Is that what you would suggest, since I'm only interested in the estimates?

To Rick's point:

I think Bob wanted to keep the GOFORIT aspect from being automatic.

Makes sense! It's not a big deal to have to explicitly add the option in 3dREMLfit. I did use afni_proc to do all the preprocessing, but I'm running the regressions separately, since I anticipated modelling the data in different ways (e.g., for univariate, multivariate analyses, with trial-by-trial covariates, etc.).

Point #2 is one that I was not aware of. Is this happening due to censoring?

Yes, certain timepoints are censored due to high motion. In the -stim_times_IM case, because each regressor only has one trial (after expansion by the program), if the onset of a given trial happens to fall on a censored time point, the regressor becomes empty and I get a warning for it (which is not a problem - I can exclude the trials in the multivariate analysis). But the unexpected part is that there is no corresponding all-zero output sub-BRIK for that trial, and all the trial numbers gets misaligned. So the sub-BRIK names (probably) don't correspond to the correct trial for that participant.
For instance, I get a warning from Deconvolve and REMLfit:
*+ WARNING: * Column 55 [Delay_Ret_Face#19] is all zeros
But the output has a non-zero sub-BRIK corresponding to trial 19, and there is one fewer sub-BRIK for this condition, relative to the number of trials that were in the original regressor (see the screenshot from 3dinfo below). Trial 19 has values ranging from -198.485 to 241.243, and there is supposed to be 25 trials in this condition, but there are only 24 (0..23).

So I think trial 20 become sub-BRIK Delay_Ret_Face#19, 21 becomes Delay_Ret_Face#20 and so on...? At least, I think this is what happens.

Hope this helps! Let me know if you'd like to take a look at the whole output.

Thank you,
Mrinmayi

image
image1187×337 46.7 KB