3dReHo: ** FATAL ERROR: WARNING: either neighborhood size (M=0) or time series length (N=130) was too small!

AFNI Message Board
1

Hi, I ran 60 subjects w/o errors but while I’m trying to run this sbj I got that error :cry:
Any advice is appreciated. Thank you.

cmd:
3dReHo -prefix rehoWrois_sbj_nneigh27 -inset EPIRES/oepi_res.nii.gz -nneigh 27 -in_rois UNC2EPI/aal2epi.nii.gz -mask EPIRES/bold_pp_mask.nii.gz

files:
https://www.dropbox.com/s/oeidgfkquwxnlj7/sbj.tar.gz?dl=0

2

Hi-

Sorry for the delay in replying, but I initially thought there was a bug in the program, and so was testing a couple things.

However, I don’t believe that is the case. In order to calculate ReHo, one takes a set of voxels (called a “neighborhood” here), which can be of any size, and calculates the Kendall’s W of the time series within that neighborhood. By definition, the neighborhood size must be >0.

In your “-in_rois …” dset, each neighborhood will be the ROI defined by the set of voxels with a given integer value; the number of voxels in a given neighborhood is called M. However, you are also applying the mask “-mask …” to the command, and basically once that mask is applied to your “-in_rois …” dset, some ROIs are entirely excluded-- they have 0 neighborhood. Therefore, the program is unhappy, and it complains that M=0 for a neighborhood (it occurs for the ROI with value=101, and possibly others-- the program crashes at the first instance of 0 neighborhood).

One way to avoid this would be to apply the mask to the ROI set ahead of time:


3dcalc \
    -a EPIRES/bold_pp_mask.nii.gz \
    -b UNC2EPI/aal2epi.nii.gz \
    -expr 'step(a)*b' \
    -prefix UNC2EPI/aal2epi_mskd.nii.gz

and then use “UNC2EPI/aal2epi_mskd.nii.gz” as your “-in_rois …” to 3dReHo (and you would not need to use the “-mask …” option). However, I don’t know if that is the kind of behavior you would want.

On a separate note, investigating this made me realize that the output format of the *.vals file is not as helpful as it could be-- it is just a single-row list of ReHo values, which might be hard to associate with the given ROI value. I will change this to be a 2 column file, where the first column is the ROI integer value, and the second will be the ReHo value.

NB: it would be possible to convert the new (nicer) format to the older one, if a script depended on that; if the old format was a.1D and new was b.1D, one could write:


1dcat b.1D'[1]'\'

to dump out b.1D as a.1D would appear.

How does that sound?

–pt

3

Thank you so much!
R.

4

Thank you again for support… I have a (dumb?) question: I used nneigh 7 (then 19 and 27) with --inrois. I got 3 identical .vals
Is it correct?
Thank you,

Riccardo

5

Hi, Riccardo-

The various nneigh won’t affect the ROI-based ReHo calculations (the ones output per ROI in the text file). The nneigh are for the voxelwise calculations (output in the volumetric data format); the in_rois is always just the entire ROI for each value of ReHo-- each ROI is the neighborhood for those specific calculations.

–pt

6

Thank you so much,

Riccardo
#stayhome