[vsipl++] fftm compile problem

[Day, John]

Jules wrote:
>> We tried building vsipl++1.3 on Windows using the Cygwin enviroment,
>> but had many problems.

> If you don't mind, can you describe the problems?  We've had some
> success with cygwin, however we would like to make things more robust.

Turns out that there was only a single problem: the configure failed on
fftw3l (using the "builtin" parameters that you suggested). Configure
reported an error on the console, but the logs did not contain any
specific error that we could identify or troubleshoot. That's when we
decided to give MingGW a try.

I should also mention that our development platform is a Dell running an
x64 Dual Core Xeon processor. But we are mostly running in 32-bit
emulation (using the WOW64 emulation) which seems to be slightly
unstable, for example we cannot get gdb (MinGW or Cygwin versions) to
run reliably. So there might be other "x64" side-effects at play here.

 >> However (surprisingly) we were successful in
 >> building using standalone MinGW with Msys and gcc/g++/g77 3.4.5,

>Great!

 >> with only two minor glitches:

 >> 1. MinGW didn't have sys/times.h, so we created one with just a tms
 >> structure which satisfied the make.

>OK.  Do you know where this was being included from?  We try to pull
>in <time.h>, but only if you've enabled one of the posix timers
>(--enable-timer=posix or --enable-timer=realtime).

These CLAPACK files included sys/times.h
vendor/clapack/SRC/dsecnd.c 
vendor/clapack/SRC/second.c

 >> 2. Modified vendor\fftw\kernel\alloc.c to allow compilation of
 >> our_alloc16()

>Was this to fix a compilation error in that routine, or to force the
>#ifdef to true?

We forced with these #defines
#define WITH_OUR_MALLOC16
#define MIN_ALIGNMENT  16
#if defined(WITH_OUR_MALLOC16) && (MIN_ALIGNMENT == 16)
 ?>
>> The two build examples, fft.exe and example1.exe were linked and ran 
>>OK, which suggests that our compiler switches and linkage issues were 
>>resolved OK.
 >>
 >> But we are still having a problem compiling the Judd/Cottel 
>>BeamformEx code 
>>(http://hpec-si.com/MinimumVarianceBeamformerExample.pdf) in files 
>>BeamformEx.cpp and beam_steer_coeff.cpp
 >> [See listing compile/link commands and errors at end of this
message]
 >>
 >> BeamformEx.cpp: pg 7
 >> // Create a cholesky object
 >>  vsip::chold<vsip::cscalar_f, vsip::by_reference>
 >>           chold_object(vsip::chold<vsip::cscalar_f, 
>>vsip::by_reference>::lower,nh);
 >> I was able to get this to compile by changing the first parameter of

>>the constructor to (vsip::mat_uplo)0, since it seems to be looking for

>>an enumeration of zero.

>'lower' is no longer part of the chold object, rather it is in the
>vsip namespace.  You might try changing parameter to vsip::lower.

That worked.

 >>
 >> beam_steer_coeff.cpp: pg37
 >> k *= (2.0 * M_PI/sv);
 >> This statement causes the error, possibly due to incorrect
 >> overloading of *= operator.
 >>
 >> I can get all of the beamformer files to compile and link if I
 >> comment out this last statement.  Is this still a config problem, or
 >> is this code possibly out of date? A comment on page 43 suggests
 >> that this is using a very early implementation of VSIPL++.

>That statement should work.  From the error message below, the library
>may be failing to include a header file.

>Can you try adding the following include

>	#include <vsip/map.hpp>

>and recompiling?

That worked. 
Also tried replacing both includes with a single #include
<vsip/signal.h> and that worked too.

 >>  We are trying to get this beamformer working to do signal
 >>  processing on some towed-array sonar data. Are there any other
 >>  adaptive beamformers available similar to this in the VSIPL++
 >>  community, either commercially or as free software?

>There is a K-Omega beamformer (also originating from Randy Judd) that
>was included with the old VSIPL++ reference implementation.  However,
>I am not sure if it is adaptive.
 
We found this presentation with code snippets, 
http://hpec-si.com/S14-HPEC-SI-VSIPL++.ppt#298,12,VSIPL++ Version

...but can't find the entire source code. How might we obtain this code
or similar VSIPL++ implementations? (We are under Navy contract, so
might reuse some old government code, if any exists).

Thanks,
John Day
 
 
 
 
 
 
 
This electronic message and any files transmitted with it contain information which may be privileged and/or proprietary. The information is intended for use solely by the intended recipient(s). If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is prohibited. If you have received this electronic message in error, please advise the sender by reply email or by telephone (301-939-7000) and delete the message.