Solver interface

[Psirus]

This adds an interface for all of the built-in Eigen solvers, two SuiteSparse solvers and two versions of Mumps.

Also, there is a "convenience wrapper" for solving our GlobalDofSparseMatrix-GlobalDofVector system. Unfortunately, it has imho too many parameters:

dof

this was necessary, because the DofMatrix/Vector didn't know the dof types they contained; since #165 has been merged, implementing a ExportEverything() function would be possible for these types, making this parameter redundant (or at least optional)

numIndependentDofs

as with the assembler, the number of independent dofs still needs to be passed to BuildConstraintMatrix…not sure why this is the case, and what can be done about it

time

Imaginary conversation between me and the solver:

"Here solve this system Ax = b." "But I need a time as well." "WTF?!"

the boundary conditions need the time, and I'm not sure what to do here; make it a reference?

[TTitscher]

Nice work, especially the external solvers! When I had a look at those I realized that they all implement the Eigen interface, with factorize, compute, solve, analyzePattern, .... Can you elaborate why you chose to wrap those in this factory-like function? This removes the possibility to customize the solver, e.g. modify the preconditioner, adjust the tolerance, re-use the solver, etc. (... and I do not like these constraints.) An alternative could be to pass them via template argument, as in NuTo::NewtonRaphson. Another idea is to follow the master branch approach and have some SolverBase.

[Psirus]

The solve() function is just a convenience wrapper, it is not intended to replace SolverBase. As you've noticed, they all implement the Eigen Sparse Solver Concept. There is nothing stopping you from using them right now [you even have a file showing you what to include, how to call them and what to link to :)]. Wrapping the wrappers seems pointless imho.

Additional benefits of the "factory" include trivial Python wrapper code and no #ifdef HAVE_MUMPS etc. in any header files.

[Psirus]

Okay, Enum vs. String, instead of long back and forth, maybe edit this:

Pro Enum:

• Autocomplete
• Misspelling reported by the compiler

Pro String:

• no additional type
• easier in Python
• headers don't change with available/unavailable solvers
• reading in a solver as a command line parameter / json entry is easier