We provide here a small overview of the software design choices.

Criterions

Code easy to use for the user.
Avoid long and nested namespaces and variable names.
Create a hierarchy that allows to reuse the code.
Do not rely on weird C++ tricks.
Do not rely on too many dependencies.
Code flexibility and high performance.

Design

To reach high performance, std::array are mainly used.
To avoid many dependencies, C++11 was chosen.
To make the code easier to use, we only rely on Boost libraries and CImg (for visualization)
To reuse code as much as possible, solvers are grouped depending on how they work. FMM-based solvers have many common procedures. The same as FM2-based solvers.
Also, we tried to use the information expert pattern.
In order to reach the flexibility and high performance, we chose to use a combination of static (templates) and dynamic polymorphism. That is, all solvers inherit from the Solver class. However, Solver itself is templated depending the grid type.

This way, the compiler can carry out tons of optimizations by knowing in advance the number of dimensions on the grid. Actually, presumably the performance is the same as if the operations were hardcoded for any number of dimensions.

FMM-based solvers, following the policies design patter, have other parameter templates that change the behaviour. Concretely, the heap types.

The dynamic polymorphism allows to use all solvers under a common interface, as the examples included.

Solvers hierarchy

Folder structure

cmake: cmake helper files and modules.
data: files and maps to test the code.
- alpha: contains code the be refactorized and included in the library in the future.
doc: doxygen documentation.
examples: examples to understand how to use the library.
include/fast_methods: header files with most of the code, as the library is mostly templated.
- benchmark: code for the benchmark tool.
- console: the console class, useful for printing and parsing arguments.
- datastructures: data types of the Fast Marching Method and other algorithms such as heaps or queues.
- fm: Fast Methods Algorithms.
- fm2: Fast Marching Square (FM2) algorithms.
- gradientdescent: gradient descent implementation to compute shortests paths from the Fast Methods outputs.
- io: input/output and visualization helper classes.
- ndgridmap: main container and types of the Fast Methods.
- thirdparty: others' software used.
- utils: utility functions used in the library.
scripts: matlab scripts to parse outputs and automatic benchmarking bash script.
src: source code for non-templated classes.