a problem when using the Clustsim option of the 3dttest++


I am recently trying permutation test with Clustsim option embedded in the 3dttest++.

It works well for the ReHo data and finally presents the correction criterion files. However, it always breaks reporting failure to open dataset (e.g., cc.0001.nii, please see the attached figure) when it work for the mALFF data.

I don’t know why and could you please give me some helpful instructions?


Can you please copy+paste the command that you were executing into a reply to this message?


Hi, thank you so much and sorry for the late reply.
Here is my script:

cd ${path1}
for item in mALFF 
rm ${item}_corrected*
3dttest++ -prefix ${item}_corrected \
-setA ${path1}/DHK/rest/DHK.results/RSFC/${item}_masked+tlrc \
${path1}/FSG/rest/FSG.results/RSFC/${item}_masked+tlrc \
${path1}/FSL/rest/FSL.results/RSFC/${item}_masked+tlrc \
${path1}/GF/rest/GF.results/RSFC/${item}_masked+tlrc \
${path1}/GJ/rest/GJ.results/RSFC/${item}_masked+tlrc \
${path1}/HXL/rest/HXL.results/RSFC/${item}_masked+tlrc \
${path1}/LCY/rest/LCY.results/RSFC/${item}_masked+tlrc \
${path1}/LRH/rest/LRH.results/RSFC/${item}_masked+tlrc \
${path1}/LYW/rest/LYW.results/RSFC/${item}_masked+tlrc \
${path1}/LZH/rest/LZH.results/RSFC/${item}_masked+tlrc \
${path1}/LZL/rest/LZL.results/RSFC/${item}_masked+tlrc \
${path1}/LGM/rest/LGM.results/RSFC/${item}_masked+tlrc \
${path1}/LQ/rest/LQ.results/RSFC/${item}_masked+tlrc \
${path1}/QYQ/rest/QYQ.results/RSFC/${item}_masked+tlrc \
${path1}/SCY/rest/SCY.results//RSFC/${item}_masked+tlrc \
${path1}/SYX/rest/SYX.results/RSFC/${item}_masked+tlrc \
${path1}/TL/rest/TL.results/RSFC/${item}_masked+tlrc \
${path1}/WL/rest/WL.results/RSFC/${item}_masked+tlrc \
${path1}/WQJ/rest/WQJ.results/RSFC/${item}_masked+tlrc \
${path1}/WQY/rest/WQY.results/RSFC/${item}_masked+tlrc \
${path1}/WSL/rest/WSL.results/RSFC/${item}_masked+tlrc \
${path1}/WY/rest/WY.results/RSFC/${item}_masked+tlrc \
${path1}/WGX/rest/WGX.results/RSFC/${item}_masked+tlrc \
${path1}/WGY/rest/WGY.results/RSFC/${item}_masked+tlrc \
${path1}/XWY/rest/XWY.results/RSFC/${item}_masked+tlrc \
${path1}/YCP/rest/YCP.results/RSFC/${item}_masked+tlrc \
${path1}/YWX/rest/YWX.results/RSFC/${item}_masked+tlrc \
${path1}/YBL/rest/YBL.results/RSFC/${item}_masked+tlrc \
${path1}/YHM/rest/YHM.results/RSFC/${item}_masked+tlrc \
${path1}/YZH/rest/YZH.results/RSFC/${item}_masked+tlrc \
${path1}/YY/rest/YY.results/RSFC/${item}_masked+tlrc \
${path1}/ZL/rest/ZL.results/RSFC/${item}_masked+tlrc \
${path1}/ZYL/rest/ZYL.results/RSFC/${item}_masked+tlrc \
${path1}/ZYX/rest/ZYX.results/RSFC/${item}_masked+tlrc \
${path1}/ZBQ/rest/ZBQ.results/RSFC/${item}_masked+tlrc \
${path1}/ZJ/rest/ZJ.results/RSFC/${item}_masked+tlrc \
${path1}/ZXQ/rest/ZXQ.results/RSFC/${item}_masked+tlrc \
${path1}/ZCB/rest/ZCB.results/RSFC/${item}_masked+tlrc \
${path1}/ZSY/rest/ZSY.results/RSFC/${item}_masked+tlrc \
-setB ${path2}/DTT/rest/DTT.results/RSFC/${item}_masked+tlrc \
${path2}/FRX/rest/FRX.results/RSFC/${item}_masked+tlrc \
${path2}/FXD/rest/FXD.results/RSFC/${item}_masked+tlrc \
${path2}/HYR/rest/HYR.results/RSFC/${item}_masked+tlrc \
${path2}/JY/rest/JY.results/RSFC/${item}_masked+tlrc \
${path2}/LL/rest/LL.results/RSFC/${item}_masked+tlrc \
${path2}/LP/rest/LP.results/RSFC/${item}_masked+tlrc \
${path2}/LYP/rest/LYP.results/RSFC/${item}_masked+tlrc \
${path2}/LYS/rest/LYS.results/RSFC/${item}_masked+tlrc \
${path2}/LZX/rest/LZX.results/RSFC/${item}_masked+tlrc \
${path2}/MJ/rest/MJ.results/RSFC/${item}_masked+tlrc \
${path2}/RHS/rest/RHS.results/RSFC/${item}_masked+tlrc \
${path2}/WAS/rest/WAS.results/RSFC/${item}_masked+tlrc \
${path2}/WCH/rest/WCH.results/RSFC/${item}_masked+tlrc \
${path2}/WXC/rest/WXC.results/RSFC/${item}_masked+tlrc \
${path2}/WXM/rest/WXM.results/RSFC/${item}_masked+tlrc \
${path2}/WY/rest/WY.results/RSFC/${item}_masked+tlrc \
${path2}/XLB/rest/XLB.results/RSFC/${item}_masked+tlrc \
${path2}/XZQ/rest/XZQ.results/RSFC/${item}_masked+tlrc \
${path2}/YSJ/rest/YSJ.results/RSFC/${item}_masked+tlrc \
${path2}/YYL/rest/YYL.results/RSFC/${item}_masked+tlrc \
${path2}/YZH/rest/YZH.results/RSFC/${item}_masked+tlrc \
${path2}/ZB/rest/ZB.results/RSFC/${item}_masked+tlrc \
${path2}/ZC/rest/ZC.results/RSFC/${item}_masked+tlrc \
${path2}/ZD/rest/ZD.results/RSFC/${item}_masked+tlrc \
-Clustsim \
-prefix_clustsim cc
#-covariates ${path1}/age.1D


Thanks for posting that.

One thing to note is that to create a 3dttest++ command, it might be easier to use this “wrapper” program-- this should allow you to make the same 3dttest++ command with a (hopefully) shorter/simpler syntax:

Looking more closely at your initial post, I see the word “Killed” in the stream of output-- that means that your computer hit a maximum memory capability, and stopped running the command part way through; that is why none of those other intermediate dsets were created. (Just for future reference, it would probably be easier for old folks like me to clearly see the output if you can copy+paste it into the messages, rather than pictures.)

What is the size of voxels you have? For example, what is the output here (could be run on any “input” dset):

3dinfo -ad3 -n4 -prefix ${path2}/WCH/rest/WCH.results/RSFC/${item}_masked+tlrc

Finally, can I ask what your quantities in the input dsets are (are they mALFF values, say from resting state FMRI data?), and what your null and alternative hypotheses are? Because it looks like you are running a 1-sample ttest (which generally has null hypothesis that the mean of the inputs is zero, and the alternative hypothesis being that they are not zero), and mALFF is a positive definite quantity whos values should always be positive-- so I wouldn’t see it ever having a chance to be “zero mean” in any group. But I might be misunderstanding.



I think there were some issues with the directories in the version from back then, and a similar command to yours worked for me.

Can you try running it again on a more current version?

  • rick

Dear ptaylor,

Thanks for your helpful advice.

The output of “3dinfo -ad3 -n4 mask_mALFF+tlrc” (as you suggested, not a picture (:P)) is “1.0 1.0 1.0 193 229 193”.

There are two datasets (yes, mALFF value from rs-fMRI) in the 3dttest++ (the patients group in -setA and the healthy control in -setB).

Does it mean that I would not be able to run the permutation test unless I buy a more powerful computer? :)o

Thank you very much~


Hi, Ying-

Well, those don’t seem like particularly large dsets, nor a terribly large number.

Rick suggested updating your AFNI-- which is (as all of Rick’s advice) a good idea, esp. in this case there might have been problems in that program. To update AFNI, copy+paste:

@update.afni.binaries -d

And I guess reading your code more closely, I do see that you are doing a 2-sample test, so please ignore my earlier question about doing a 1sample test.

Can you update AFNI and see if that works this time? Also, if you have other large processes running on your computer, you might want to stop those temporarily (e.g., browsers can be reeeeally greedy on RAM, esp. Chrome).


Hi, pt,

After updating the AFNI, unfortunately, the program still always runs into a stop before the correction criteria files appear.

Here is the end part of the output:
"+ t-test randomsign/permute:+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:
+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:
+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:
+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:
+ WARNING: 3dttest++ -setB :: 6020579 vectors are constant
++ t-test randomsign/permute:000000000111111111222222222333333333444444445555555Killed
++ saving main effect t-stat MIN/MAX values in ./cc.0013.minmax.1D
++ ---------- End of analyses – freeing workspaces ----------
Is there any other possible reasons or solution? Thanks~


Hi, Ying-

That “Killed” message means that you are running out of memory on your computer. Now, your dset isn’t that large of a FOV, but you do have 1x1x1 mm3 voxels, so I think that there are more there than what I normally see with EPI dsets. What was the original resolution of your presumably EPI dsets? I would assume that those were at much lower resolution, like 3x3x3 mm3, or maybe 2x2x2 mm**3 for a fancy-style acquisition… I don’t know that upsampling the data really high will help with anything-- it won’t create more “information” (dsets are just interpolated to a higher res grid), and it will potentially create memory+space problems on the machine (perhaps what we are seeing here).

… And looking at the options, I see you don’t have a mask being used-- though I would imagine did have a mask applied to your data (based on their filenames). Could you add the mask you used as an option with “-mask …”? Looking at the help file, this option is actually explicitly called for with the “-ClustSim” flag in use:

-mask mmm = Only compute results for voxels in the specified mask.
             ++ Voxels not in the mask will be set to 0 in the output.
             ++ If '-mask' is not used, all voxels will be tested.
         -->>++ It is VERY important to use '-mask' when you use '-ClustSim'
                or '-ETAC' to computed cluster-level thresholds.
             ++ NOTE: voxels whose input data is constant (in either set)
                 will NOT be processed and will get all zero outputs. This
                 inaction happens because the variance of a constant set of
                 data is zero, and division by zero is forbidden by the
                 Deities of Mathematics -- cf., http://www.math.ucla.edu/~tao/

Probably for just such a case as what we are seeing here! (Though even if this does solve the memory issue, it might be useful to reconsider upsampling the data a lot.)


Dear ptaylor,

Thank you so much for your helpful suggestions, especially for that about the resolution.

It does be quite strange that upsampling happens during the preprocessing of the resting data. Therefore, I went back to refine the preprocessing (as the example 11b of afni_proc.py) and obtained the un-resampled mALFF data. Finally, the criterion file of permutation test was finally generated today.

And yes, I have now added a group mask as an option in the 3dttest++ instead of masking every individual data.

Thanks again and best regards!

Ying Wang

Hi, rick

Thanks for your suggestion and I am sorry for a late reply.

Updating the AFNI did not work for me. After various examination, and now I suspect something was wrong when generating the mALFF value (mALFF was upsampled, although I don’t know the reason yet:-().

Thanks again, and best wishes!

Ying Wang