Beta Series questions

AFNI Message Board
1

Hi all,
I’m trying to run a beta series analysis on some data I have. I have a task with 66 trials, 22 in each of 3 conditions (7 events per trial are modeled). I have set the trial type descriptor to -stim_times_IM for each event type, but I note that in the output, I’m seeing only 11 (but sometimes 12 or 13!) regressors per event type. I should be seeing 22, to my understanding. I’m not sure what I’m doing wrong because each of my 1D files have have the correct amount of lines.

The other problem I’m getting is crashes on running the 3dDeconvolve command in some cases:

  1. Fatal Signal 11 (SIGSEGV) received in job #0
    and
  2. malloc errors.

The data files that are the inputs are 2 blocks (300 MB each). The system has 16 GB of RAM (some of which is used elsewhere). I can’t figure out, though, why some analyses work and others don’t. Any input would be helpful.

I am using AFNI 22.0.04 on Linux Ubuntu 20.04 (linux_x86_64 binaries).

Thanks,
Matt

2

Hi Matt,

Would you mind posting a sample of one of the timing files that is not giving you the number of betas that you expect? Or, you could mail me the timing file along with any X.xmat.1D file (or a nocensor version).

Are you using afni_proc.py? If so, try adding -regress_compute_fitts. That will use 3dcalc to compute the fitts, rather than having 3dDeconvolve (use the extra RAM to compute and) write it out.

While 16 GB seems like plenty for this, if other programs (like web browsers) are using all of the RAM, you might have to close some programs.

  • rick
3

Hi Rick,
I sent the files. I’ll try the flag you suggest for the cases that didn’t work.
Thanks,
Matt

4

Hi Matt,

Indeed, there is some problem in 3dDeconvolve, possibly with the combination of global timing and IM. The problem seems to happen before 3dDeconvolve even detects that the timing is global. Based on that, you should be able to fix the problem simply by specifying the timing type BEFORE any timing files are given:

-global_times

So add that option before any -stim_times_IM option is listed.

To some degree, I have been thinking that we should move towards always using local timing. Within 3dDeconvolve, having the 2 cases makes life much more difficult (both for 3dDeconvolve and for users), but that is for another day.

So either specify -global_times, or change the timing to local via “timing_tool.py -global_to_local”.

Please let me know how it goes.

Thanks,

  • rick
5

Will do, thanks. I should note that in the conventional 3dDeconvolve (using -stim_times), I got a warning that said the analysis would assume global times, and in the *.html output, I saw the correct output (22 trials) for each event type. My assumption is that will address the varying number of trials I was getting in the -stim_times_IM case.

6

Thanks for the script and timing files! I have pushed a change for this which should be built this weekend.

Unfortunately, the comment about detecting global times comes after the damage was done from not knowing, possibly leaving you with far too few regressors.

The code was updated to make global timing be the default for the assessment of the number of trials, and to give a warning if IM is used without specifying either -local_times or -global_times, first (since it could still “fail” in the other direction).

Until you get the fix (or maybe forever :), please add -global_times (or -local, if appropriate) before the -stim_times options.

Thanks for bringing it up!

  • rick