Encapsulate MUMPS solver class

[julianlitz]

Merge Request - GuideLine Checklist

Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.

Checks by code author:

Always to be checked:

• There is at least one issue associated with the pull request.
• New code adheres with the coding guidelines
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

If functions were changed or functionality was added:

• Tests for new functionality has been added
• A local test was succesful

If new functionality was added:

• There is appropriate documentation of your work. (use doxygen style comments)

If new third party software is used:

• Did you pay attention to its license? Please remember to add it to the wiki after successful merging.

If new mathematical methods or epidemiological terms are used:

• Are new methods referenced? Did you provide further documentation?

Checks by code reviewer(s):

• Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
• The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
• There are appropriate unit tests and they pass.
• The git history is clean and linearized for the merge request. All reviewers should squash commits and write a simple and meaningful commit message.
• Coverage report for new code is acceptable.
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

[codecov]

Codecov Report

❌ Patch coverage is 96.75325% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.14%. Comparing base (39ce1dd) to head (fdc909f).

Files with missing lines	Patch %	Lines
src/LinearAlgebra/Solvers/coo_mumps_solver.cpp	94.89%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #182      +/-   ##
==========================================
- Coverage   95.18%   95.14%   -0.04%     
==========================================
  Files          94       89       -5     
  Lines        9345     8925     -420     
==========================================
- Hits         8895     8492     -403     
+ Misses        450      433      -17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[EmilyBourne]

Why can't you just do:

    : DirectSolver(grid, level_cache, domain_geometry, density_profile_coefficients, DirBC_Interior, num_omp_threads)
    , mumps_solver_(buildSolverMatrix())
{}

?
This would also avoid the need for std::optional

[julianlitz]

I tried this but doesn't work really for 2 reasons.

1. In the Smoother we have a
   void buildMatrix(inner&, tridiags&)

2. If we do this, then we need to do the Stencil assignments before the definition of the Matrices in the private: section. Otherwise Stencils are not yet defined when we run buildMatrix.

[EmilyBourne]

Do we have to do the same for all classes?

What makes sense for the Smoother isn't necessarily relevant for the solver is it?

In the Smoother we have a
void buildMatrix(inner&, tridiags&)

I can't find the function you are talking about. I just see buildAscMatrices which seem like functions which could become:
auto SmootherGive::buildAscMatrices()
or
MatrixType SmootherGive::buildAscMatrices()

[julianlitz]

Yes, I was referring to that function. These modify the private inner boundary matrix as well as the tridiag matrices.

It would work for the DirectSolver, however it would be nice if we keep it consistent with the Smoother as well.

[EmilyBourne]

Could the two matrices be calculated independently? It seems a shame to have std::optional if this can be avoided

[julianlitz]

Yes we can separate the InnerBoundary matrix construction from the tridiagonal matrices. This would be the best approach.
Or we do

MatriyType buildMatrix(tridiag&)

instead of

void buildMatriy(tridag&, MatrixType& inner_boundary)

[EmilyBourne]

Is it safe to use std::move here? inner_boundary_circle_matrix_ is not used when MUMPS is activated?

[julianlitz]

inner_boundary matrix will never be used again after this, so it would be fine. But let me know if you prefer a copy.

The COO Solver takes ownership of A while the CSR Solver doesn't.

[EmilyBourne]

I don't like the fact that a class member is uninitialised and must not be used. I would prefer if inner_boundary_mumps_solver_ and inner_boundary_circle_matrix_ could be condensed into 1 variable to avoid the risk of accidentally trying to access inner_boundary_circle_matrix_

[julianlitz]

The main issue is the different behavior of ownership.

In the CSR case we must have a private matrix member since we need to own the object. (The solver doesn't own a matrix).

In the COO case, the solver needs to own the object (thus a private matrix member is not necessarily needed).

Option 1: (currently used)

• in both cases store the matrix internally and copy it for the COO solver

Option 2: (previously used)

• in both cases store the matrix internally and move the matrix to the COO solver

Option 3:

• Depending on the solver use a different logic:
  Store matrix internally only in CSR case and use a standard variable for COO which then can be moved.

I find option 3 unnecessarily complex since the behavior for COO/CSR is quite different then.