Conclusions, possible developments.
===========================================

The report [:ref:`RB12 <RB12>`] has been released. It serves as a detailed conclusion. It offers a more detailed overview and perspectives on the maintenance and possible developments of MULT_FRONT, in the context of the availability in *Code_Aster*, of another solver, MUMPS. However, in the following 2 paragraphs, we summarize the scope of execution and the performance report of MULT_FRONT.




Scope of execution
---------------------

The scope of the multi-frontal method has been almost complete since the developments in 2011, which make it possible to factorize so-called "generalized" matrices. Only numerically unstable systems requiring a pivot method (X- FEM for example) should be excluded from the choice of the MULT_FRONT solver. A less recent development (renumbering the interpolation nodes and no longer the degrees of freedom), makes it possible to maintain the order of these degrees of freedom within a node and makes it possible to deal with incompressible elements. Using MUMPS is the solution for systems that require a pivot method. However, a development of MULT_FRONT is possible: it is possible to perform, within each supernode, i.e. among the unknowns eliminated at each stage, a search (obviously partial) for a pivot. A more complete search would then involve the fusion of several supernodes (fusion of daughter and mother matrices) and seems difficult to imagine. This partial pivoting requires a significant amount of work and would be a risk for the stability of the code.




Performance
-----------

Sequential performances (single-processor mode) are comparable to MUMPS in many cases. Only cases with a lot of linear relationships between degrees of freedom can be very unfavorable to MULT_FRONT, which creates matrix padding in these cases. Sometimes it was enough to reorder the data from these boundary conditions to the limits to solve the problem.

As far as parallelism is concerned (located as we saw above, within the elimination of each supernode), it is rarely used and can offer an acceleration factor between 2 and 3 for execution on four processors (or processor cores). This parallelism is interesting for large cases requiring a lot of memory and having to run practically alone on the machine. This makes it possible to significantly reduce their period of residence in the machine. The arrival of processors with more and more cores should provide an opportunity for new performance tests for such big cases. However, this parallelization in shared memory does not offer any memory gain. What parallelization in distributed memory allows (MUMPS). Often this memory problem is a blocking point for large linear systems.

The multi-frontal method offers the possibility of another more elaborate parallelization on the various branches of the elimination tree. It is not possible to program it in MULT_FRONT, it would be "redoing" what is done in MUMPS. The code was not designed for parallelization by sending a message.