gem/nhlib — pull request #52 by angri (2012-08-13 14:56:12+00:00)
Title: Fault source distance calculators and distance filter performance optimizations

Note: this branch is based on disagg, which should land first for the clean diff.

This adds two source files in C, which compile into small C-extensions. Those extensions are then being used to speed up some geodetic and geometric calculation (namely - minimum geodetic distance and convex-to-point distance). An alternative (pure python) implementation of those functions exists and it is being used for the case when extensions are not available. So we do not reduce the portability, but support some performance improvements for the case when we can compile extensions.

One needs C compiler (I tested with gcc 4.4.5 and clang 3.1) and linker as well as python and numpy headers. The process is simple: "python setup.py build_ext" - it puts compiled extensions to build/lib./nhlib/geo. Dealing with it is probably the most simple if you create symbolic links from nhlib/geo/_geodetic_speedups.so and nhlib/geo/_utils_speedups.so to .so files in ../../build/lib./nhlib/geo. If you don't see warnings when you run tests - extensions are properly installed.

Note that functions in C are tested by the very same test cases as for pure python versions. This way we make sure that different implementations are functionally equivalent. So after all, any code that uses nhlib can work either with nhlib + extensions or with pure python nhlib. Functionality in extensions is private anyway.

As far as the performance is concerned, C code allows to make point source / area source calculation faster by about 7% because of more efficient distance filtering. Fault source models should perform better by the magnitude of 7 to 10 for larger site models (1k+). Because nothing has changed in the ERF preparation code, there should be no noticeable performance difference for single site (or few sites) use cases.