Using Boost.Build it is relatively easy to link to libraries that are installed in your user directory instead of the standard system directories. Hence you should not deprive yourself of something because it is not already installed on your machine and you do not have root access. Just go get the source and compile it yourself. In many cases it is enough to pass "--prefix=$HOME" as argument to the configure script. That applies to HDF5, Mesa3D, FFTW, GMP. You can even install OpenMPI this way if you want to test MPI parallelisation. For Boost you should pass this option to bjam when you install the library. Since VTK uses the cmake build system, you just need to change the CMAKE_INSTALL_PREFIX build variable and make it point to your $HOME.

If you use any compiler other than GCC 4, you will soon find out how painful templates can be. All that machinery puts a lot of pressure on the compiler, and some of the compilers that are ubiquitous in scientific computing are simply not optimized to handle them efficiently. Having tested ICPC, XLC and GCC, I found that XLC is by far the worse in this respect. To achieve any reasonable level of optimisation, one needs to use IPA (interprocedural optimization, enabled with -O4 or -O5), which tend to gulp huge amounts of memory. Concerning ICPC, there has been a huge improvement in version 11 compared to version 10, so that upgrade is strongly recommended. Compilation times are reduced by a factor between 10 and 100 for heavily templated code. In case your compiler can't make it, there exists a last resort called explicit template instanciation (ETI).

Because it is the only one which supports both MPI and OpenMP, and it is fast. If you are suspicious about the results, you should run test_fftw from the test suite, after having edited the source so that the size of the arrays match your own data. Basically, what it does is compare the fourier transform computed using MPI with the serial fourier transform, the latter being safe since it is identical to the released version of FFTW.

I have been using many MATLAB scripts to post-process simulation results and to test programs developed as part of KW. In fact, many algorithms were first written completely in MATLAB since it is quite flexible in particular for debugging. Why do we care ? Well, I'm just mentionning this because none of the Matlab scripts are included in this distribution (mainly to avoid any eye-dropping reaction from GPL purists out there), but they do exist and are available on our website.