I am trying to use BROCCOLI to speed up permutations testing for TBSS on skeletonized WM data. I was able to run permutations testing successfully on my platform and device (AMD GPU) with your sample data:
BROCCOLI/code/testing_scripts/randomise/betas49.nii.gz
However, when I now try with my own 4D NIFTI file consisting of FA data registered to a group-derived template, I get an error stating that there are 0 possible permutations, even when just attempting -groupmean (which is meaningless for FA data). It does read in the correct dimensions of my file, and does find the correct # of subjects (n = 84) in the 4th dimension.
Command:
RandomiseGroupLevel all_FA_skeletonised.nii.gz -groupmean -platform 0 -device 0 -permutations 10000 -output tbss_parallel -verbose
Output:
Warning: No mask being used, doing permutations for all voxels.
It took 64.409843 seconds to read the nifti file(s)
Warning: Number of possible sign flips for group mean is 0, but 10000 permutations were requested. Lowering number of permutations to number of possible sign flips.
Authored by K.A. Eklund
Data size: 176 x 512 x 512 x 84
Number of permutations: 0
Number of regressors: 1
Number of contrasts: 1
Here also are info output on my dataset:
fslinfo all_FA_skeletonised.nii.gz:
data_type FLOAT32
dim1 176
dim2 512
dim3 512
dim4 84
datatype 16
pixdim1 1.000000
pixdim2 0.500000
pixdim3 0.500000
pixdim4 1.000000
cal_max 1.5417
cal_min 0.0000
file_type NIFTI-1+
3dinfo all_FA_skeletonised.nii.gz:
Dataset File: all_FA_skeletonised.nii.gz
Identifier Code: NII__AL_eWytYUadLGoiKqBqBQ Creation Date: Wed Apr 22 09:02:21 2015
Template Space: ORIG
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 15,502,147,584 (16 billion [giga]) bytes
Geometry String: "MATRIX(1,0,0,-91.02654,0,-0.5,0,94.37949,0,0,0.5,-146.8557):176,512,512"
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -91.027 [R] -to- 83.973 [L] -step- 1.000 mm [176 voxels]
A-to-P extent: -161.121 [A] -to- 94.379 [P] -step- 0.500 mm [512 voxels]
I-to-S extent: -146.856 [I] -to- 108.644 [S] -step- 0.500 mm [512 voxels]
Number of time steps = 84 Time step = 1.00000s Origin = 0.00000s
-- At sub-brick #0 '?' datum type is float
-- At sub-brick #1 '?' datum type is float
-- At sub-brick #2 '?' datum type is float
** For info on all 84 sub-bricks, use '3dinfo -verb' **
Any ideas why this might be happening? Many thanks!