search

bbfrederick / rapidtide

rapidtide - a suite of programs for doing time lag correlation analysis on fMRI data
Apache License 2.0
75 stars 14 forks source link

despeckle_thresh logic #77

Closed robbwh closed 2 years ago

robbwh commented 2 years ago

In the rapidtide help menu it says

 --despecklethresh VAL
                        Refit correlation if median discontinuity magnitude exceeds VAL. Default is 5.0 seconds.

When running rapidtide 2.2.0 with these settings 

rapidtide "$procImg" "$destination"/output --delaymapping --pickleft --noglm --numnull 0 --searchrange -25 100 --nofitfilt --nprocs="$nCores" --oversampfac 5 --spatialfilt 1.05 --filterfreqs 0.005 0.05 --corrmask="$destbetMask" --detrendorder=2 --zeropadding -1 --globalmeaninclude="$gmmask" --ampthresh 0.4 --interptype="cubic"

It will say, for instance

Correlation despeckling pass 1
    Using despeckle_thresh = 24.230

Shouldn't I expect despeckle_thresh to be set to 5 seconds automatically? Should I set it to that? Or is it finding an ideal despeckle_thresh through some automatic means?

EDIT:

I've observed the depeckle_thresh behavior before the most recent update (2.2.0), so it probably isn't related, but I'm getting this error/warning message as well. (Likely just an issue with my install. I would use the docker, but it isn't up yet.) I'm 99% sure the despeckle_thresh behavior isn't related to the error message, but just wanted to post it as well for full disclosure.

Correlation calculation, pass 1
RuntimeError: Undefined plan with nthreads. This is a bug
Exception ignored in: 'pyfftw.pyfftw._fftw_plan_with_nthreads_null'
Traceback (most recent call last):
  File "/gpfs23/scratch/Hudson/resource/antspy/lib/python3.8/site-packages/pyfftw/builders/_utils.py", line 285, in _Xfftn
    FFTW_object = pyfftw.FFTW(input_array, output_array, axes, direction,
RuntimeError: Undefined plan with nthreads. This is a bug

The rapidtide run still continues even after printing this warning though.

robbwh commented 2 years ago

I'm thinking it chooses despeckle_thresh differently if there are sidelobes, so I suppose it is fine as is.

bbfrederick commented 2 years ago

Sorry for the late response. Yes, the logic is unchanged - if there are no problematic sidelobes, despeckle_thresh remains at either the default (5s) or whatever you set it to with the command line. If a sidelobe is detected, it is reset to maximum of the current value and the sidelobe position. You may have just been looking at data without any bad sidelobes before, so you weren't seeing it be reset.

robbwh commented 2 years ago

All good, thanks. That makes sense!