Feature eigen

Context

This MR generalizes the use of Eigen in waves.

Tasks

Following MR !50 (merged), here is the updated to-do list:

• replace gmm::matrix<double> by Eigen::Matrix<double>
• replace std::vector<double> by Eigen::(Row)Vector<double>
• refactor elementary matrices computation
• change method return type, ie void build(Matrix const &A, Matrix &K) should become Matrix K build(Matrix const &A)
• replace tbox::Pt by Eigen::VectorXd
• investigate Pardiso interface
• investigate Eigen multithreading feature
• clean the thermo-mechanical matrices

Notes

• I added a general interface tbox::LinearSolver from which derive tbox::Mumps, tbox::Pardiso, tbox::Gmres and tbox::SparseLu. The first class is a direct interface to the MUMPS solver, while the other three merely call Eigen interface or implementation of these solvers. The linear solvers are interfaced in python and the nonlinear solvers must now be initialized with a problem and a linear solver.
• I did not clean the thermo-mechanical matrices computation in tbox::Tetra4 and tbox::Hex8. This could be further addressed in the branch clean_mirrors, which brings LFS support for large geometry files and improved tests.
• Regarding the multi-threading in Eigen, it does not make sense to use it if the top level functions in waves are multi-threaded, which should be the case. However, multi-threading can be used for linear solvers. For now, only Pardiso can use multi-threading (GMRES and SparseLU are not multi-threaded and I did not look into MUMPS).

Additional changes

• I replaced the std::vector holding the shape functions by Eigen::Matrices, and consequently updated the Cache, ShapeFunction and Gauss classes. Additionally, the members of Cache and Gauss are now private and can only be accessed by getters (which I inlined).
• I replaced the std::vector by std::deque to hold the list of Eigen::Triplet for the global matrices assembly, as it proved to be faster.
• I changed the assembly procedure of periodic BCs (tbox::MshDeform) and Kutta condition (flow::Newton and flow::Picard) so that the contributions are directly assembled on the right rows, thus avoiding the costly manipulation of the rows after the matrix has been built.

Tests

Passed on ubuntu18.04 (python 2.7.15), debian4.9 (python 2.7.13), msys2 (python 3.8.1).

flow/scripts/config.py

@@ -125,6 +125,7 @@ class Config(object):
             raise RuntimeError('Available nonlinear solver type: Picard or Newton, but ' + p['NSolver'] + ' was given!\n')
         args = parseargs()
         self.solver.nthreads = args.k
+        self.solver.verbose = args.verb
         self.solver.relTol = p['Rel_tol']
         self.solver.absTol = p['Abs_tol']
         self.solver.maxIt = p['Max_it']