Subject: Re: fft on prospect

From: Rich Loft <[email-masked]>
Date: Mon, 17 Apr 2000 09:39:34 -0600 (MDT)

Ben:

   It isn't at all unusual for people to answer a question
   for themselves just by carefully posing the question for
   someone else's benefit. Glad this worked for you, it makes
   my job easy....

							Rich
 
   P.S.

   Within the next couple of months we will be releasing 
   a beta version of FFTPACK which is threaded and specifically 
   tuned for RISC uprocessors. This release will contain at least
   real to real and complex to complex FFT's. When the time
   comes, perhaps you will want to switch to those.

							Rich

   Date: Fri, 14 Apr 2000 14:31:08 -0600 (MDT)
   From: Ben Foster <[email-masked]>
   Cc: [email-masked]
   Content-Length: 1150

   Dick and Rich:

   Well, this is embarassing. Writing that long email msg today
   reminded me to check scoping of the fft coeffs coming
   out of the set99 call, and lo-and-behold when I put the
   the trigs and ifax arrays in global common rather than 
   thread_private, it worked on prospect! Now I'm not sure 
   why it worked on the crays and the Origin, but I don't
   really care, either ;-)

   !
   ! Thread private fft data and workspace:
   ! (maybe these could be made local to filter routines)
	 real :: fx,wfft
	 common/fft/fx(zimx+2,2*zkmxp),wfft((zimx+1)*2*zkmxp)
   !$OMP THREADPRIVATE (/fft/)
   !DIR$ TASKCOMMON fft
   !
   ! Global coefficients for fft (set by set99 call from con.f)
	 real trigs
	 common/fft_glb/ trigs(3*zimx/2+1)
   ! Global fft args:
	 integer :: ifax(13)
	 common/fft_int/ ifax
   !

   However, I'm still interested in updating the fft in this
   model -- maybe the performance and/or portability would be 
   better with one of the new packages. But it appears its
   not as necessary as before...it can be lowered in priority...

   Sometimes, just sending email to you guys helps me get my
   ducks in a row, thanks for your patience..

   --Ben