ctio fft1d causes endless loop

[MarcosIAG]

Fresh install of IRAF and external package CTIO.
Main IRAF make sysgen and CTIO mkpkg on ubuntu 16.04 (AMD 64).
MACH and IRAFARCH = linux64

fft1d enters an endless cpu busy state.

[olebole]

Although CTIO is involved, this seems to be an IRAF core problem -- it finally calls sys/vops/fftx.f or sys/vops/fftr.f for the actual FFT. Differently from the other FFT routines in IRAF, this one was not marked as originated by Numerical Recipes and therefore remained original (and not replaced by ffpack in 934ea80).
Could you provide a small example file and the exact CL commands that lead to the endless loop?
Do you know whether it worked for other versions (like the original 2.16.1, or under 32bit)?

[MarcosIAG]

Hi Ole, That is true, those fft utilities based on complex vops are much older than Numerical Recipes. The ctio fft1d task works fine in current stsci astroconda 2.16 stack installation (a 2013 update). Please find attached a sample spectrum and the ftt1d pars that fail (but work on conda distribution). many thanks and regards, Marcos

…

-------------------------------------------------------- Marcos P. Diaz prof. livre-docente Departamento de Astronomia Instituto de Astronomia, Geofísica e Ciências Atmosféricas Universidade de São Paulo Rua do Matão, 1226, Butanta 05508-900, São Paulo, SP, Brasil e-mail: [email protected] url: astroweb.iag.usp.br/~marcos <http://astroweb.iag.usp.br/%7Emarcos> voice: 55-11-30912720 skype: marpdiaz fax:55-11-30912860 ----------------------------------------------------------

On Sat, Oct 12, 2019 at 11:18 AM Ole Streicher ***@***.***> wrote: Although CTIO is involved, this seems to be an IRAF core problem -- it finally calls sys/vops/fftx.f or sys/vops/fftr.f for the actual FFT. Differently from the other FFT routines in IRAF, this one was not marked as originated by *Numerical Recipes* <https://iraf-community.github.io/iraf-v216/license-problems> and therefore remained original (and not replaced by ffpack in 934ea80 <934ea80> ). Could you provide a small example file and the exact CL commands that lead to the endless loop? Do you know whether it worked for other versions (like the original 2.16.1, or under 32bit)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#94?email_source=notifications&email_token=ANOIGCASST2Z4YDWCQHYJ3DQOHME3A5CNFSM4I7MI4VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCANUY#issuecomment-541329107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANOIGCDMDLJOVLW5YK2CH5TQOHME3ANCNFSM4I7MI4VA> .

[olebole]

Test files:

testfiles.tar.gz

[olebole]

OK, first debugging gives that fftx.f is really buggy. The variable l is defined as l(15) (implicitly as real):

iraf/sys/vops/fftx.f

Line 20 in c2bb53e

dimension x(*), y(*), l(15)

However, then there is a loop over the index until 31:

iraf/sys/vops/fftx.f

Lines 84 to 87 in c2bb53e

	90 do 110 j=1,31
	l(j) = 1
	if (j-n2pow) 100, 100, 110
	100 l(j) = 2**(n2pow+1-j)

This just can't work at all, and did never work, and I wonder how this passed any test at NOAO. It just randomly overwrites the stack, or wherever the l array is placed. Originally, the loop went only as do 110 j=1,15, but was extended to 31 with version 2.14 (2006), with this (supposed) changelog entry:

iraf/doc/notes.v212

Lines 1913 to 1916 in c2bb53e

	sys/vops/fftr.f
	sys/vops/fftx.f
	Increased the check for the power-of-2 dimension to 2^31 from the
	current 2^15 (4/21/06, MJF)

One may guess that the second change in this diff was done on error:@mjfitzpatrick?
In principle, one could have two ways to "fix" this:

1. Just revert the change for this loop and hope that everything is OK
2. Try to replace the fftx.f and fftr.f code with the libfftw, which is nowalso used elsewhere in IRAF. I would suppose this would be the clean solution.