changes in the inverse FFT in recfunk codes

click title to see Google Drive directory JParkCodes

After some comparison runs, Vadim Levin convinced me that the "improvement" I made to the inverse FFT in the recfunk*, rfmig* codes was a bad innovation.  The original RF-estimation codes applied a cos^2 factor to the frequency-domain RFs H_R(f) and H_T(f) with weighting unity at the f=0 point, decreasing to zero at f_max while following a cos-squared dependence.  I changed all codes to have a sharper bandpass (I was unhappy that the half-amplitude point occurred at f_max/2!) with unit factor from f=0 to f=0.5*f_max, then a cos-squared rolloff within (0.5*f_max , f_max).  This sharper bandpass led to small negative sidelobes at the flanks of sharp Ps pulses.  Although one can live with this, the temptation to interpret a wiggle could be strong, so it is safer to use the original weighting of H(f) before inverse FFT to obtain the time-domain RF.  The sidelobes do not disappear completely, but are far smaller.

These codes have been updated on the website:

recfunk_pick.f

recfunk_estack.f

rfmigrate_estack.f

rfmigrate.f

recfunk_svd.f

recfunk_mwm.f

recfunk_mwmj.f

recfunk_mwms.f

rfmig_boot.f

rfmig_mboot.f

rfmig_cboot.f

rfmig_mcboot.f

Update of anirec_synth.f and anirec_synth_circle.f

click title to see Google Drive directory JParkCodes

A small amount of random noise was added to synthetics to prevent zero-divide errors (in cases where the recfunk codes tries to compute an RF for an interval of x=0 data). In the update, this bit of noise was made smaller, and explicitly zero-mean. There were some low-frequency artifacts cropping up in synthetic RFs. The updated versions seem to avoid this problem:

anirec_synth.f

anirec_synth_circle.f

for info see  link