The second evaluation is here and I am getting a little bit worried with my progress. I was supposed to start integrating ecipex algorithm right now but instead I dealt with some hidious runtime errors.

KISSFFT runtime errors

As I described in the previous week’s post, kiss’s fast fourier transform gave me some undefined behavior. The first thought was that the library was not properly built so I started messing around with the cmake application. I ended up writing a small test file and link it with the static library generated by the cmake contrib build to make my life simpler. Still no luck. The test program run with no error when I linked with the library generated by the original makefile. I decided to involve my mentors in this and the weirdest part after a bit brainstorming is that in their OSX and linux computers run without complaining. I got really frustated with valgrind I was not able to determine what was going wrong.

Eventually I found out what was going wrong and I find it quite interesting. When building the kissfft library you need to define the datype of the number that the library will work with. I have built the library with -Dkiss_fft_scalar=double with cmake. The default datatype that the header file uses is float.

In the header file:


# ifndef kiss_fft_scalar
/*  default is float */
#   define kiss_fft_scalar float
# endif

and here is the primary struct that I was using:


typedef struct {
    kiss_fft_scalar r;
    kiss_fft_scalar i;
}kiss_fft_cpx;

I had the fallacy that this would automatically resolved. Thinking it afterwards the linking happens after the object file is generated so all the symbol tables have been finalized. So essentially I had complex vectors of float and was linking with the library that was built for doubles. As soon as I included in my test this line #define kiss_fft_scalar double, all problems were gone solved my problems. Of course it did not run with the default kissfft library.

Putting this behind me, this problem drove me crazy because I was not confident enough with cmake experience thinking that I did something wrong in the build configuration. The answer ofcourse lied in the source code (as always :)

Hopefully I will be able to catch up with the schedule until the end of the evaluation. One of my mentors, Artem Tarasov, who actually has helped a lot with minimal input, has already implemented a modern version of the Ecipex algorithm in C++ so I will directly integrate his code in OpenMS and hopefully that will speed up my progress.