Follow standard CMake layout

[EmilyBourne]

Clean up CMake files to follow standard practice. In particular:

• All find_package calls are moved to the root CMakeLists.txt so dependencies are easy to locate
• Definitions of installed dependencies are moved to dedicated cmake/FindX.cmake files so they can be located via a standard find_package call
  • LIKWID
  • MUMPS
  • Metis (via MUMPS)
• Definition of the C++ standard is moved to the root of the project
• The target InputFunctions (which is only required for testing and for the CLI) is removed from the GMGPolarLib target
• The target GMGPolarInterface is added to group example input functions and other tools required for the command line interface.
• The condition if(OpenMP_CXX_FOUND) is removed as OpenMP is a required dependency so this should always be True
• Relative paths are avoided. Instead CMake ensures that the include/ folder is included via the compile command
• Add an install target to allow GMGPolar to be installed on a system and included via find_package(GMGPolar)

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.

[EmilyBourne]

@tpadioleau can you have a look at this please to see if it aligns with what you had in mind for linking to Gyselalib++?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.73%. Comparing base (efd9941) to head (3846939).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #214   +/-   ##
=======================================
  Coverage   95.73%   95.73%           
=======================================
  Files          79       79           
  Lines        8622     8622           
=======================================
  Hits         8254     8254           
  Misses        368      368           

☔ View full report in Codecov by Harness.
📢 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.

[tpadioleau]

I think this is an improvement, my main concern is whether we should install files related to InputFunctions ?

[tpadioleau]

Is this METIS from https://github.com/KarypisLab/METIS ? I see it is based on CMake, it does not generate its own Config files ?

Does not need to be handled in the PR.

[EmilyBourne]

I didn't check, I just reorganised what was already in the existing CMake files. Probably a question for @mknaranja

[mknaranja]

more a comment than a full answer: Yes, this is METIS from Karypis, it is used for mesh / graph partitioning which is used in direct solvers such as MUMPS. But: I couldn't tell you anything about the technical config file question, I never looked at it at that level.

[julianlitz]

I never tested Mumps without Metis, but Mumps could be used without it by setting ICNTL(7)=7.

https://github.com/SciCompMod/GMGPolar/blob/main/src/LinearAlgebra/Solvers/coo_mumps_solver.cpp#L107

[mknaranja]

I think MUMPS can also use other graph partitioners such as p4est but I think that does only yield other problems. Graph partitioning is used to reduce fill-in. I would suggest to keep METIS if MUMPS is used. From my point of view, METIS is a minimal dependency as it is used in millions of numerical linear algebra (+ HPC) applications.

[tpadioleau]

Do they actually need to be installed ?

[EmilyBourne]

I'm not sure. This is a question for @mknaranja . It depends on what you see as being the main functionality of the library.

I would lean towards them not needing to be installed. But if they are I would probably use them for testing GMGPolar vs other solvers

[EmilyBourne]

I can see a world where someone might want to use e.g. the domain geometry for a problem. I don't see any harm in installing them. Unless you see a problem?

[tpadioleau]

No strong concern, it is just usually easier to add a new feature than remove it. So if we were not sure it is public, we could have delayed its installation in an other release. But if these functions make sense, we keep them.

[HenrZu]

@mknaranja requested me to have a look at this. Looks great :) The structure is much cleaner. I left a few minor comments (most are questions as im not really familiar with the structure).

[tpadioleau]

FYI, I started a draft of the Spack package, gyselax/spack@e4fbf54

You can test it with a Spack environment:

# gmgpolar-spack.yaml
spack:
  concretizer:
    unify: true
  specs:
    - 'cmake'
    - 'gmgpolar@git.ebourne_cleanup_cmake=main'
  repos:
    patches:
      git: https://github.com/gyselax/spack.git
      branch: releases/v2025.11
    builtin:
      branch: releases/v2025.11
  view: true

Once you have downloaded Spack and activated it, see https://spack.readthedocs.io/en/latest/getting_started.html#getting-started

spack env create gmgpolar-env ./gmgpolar-spack.yaml
spack env activate gmgpolar-env
spack install

[tpadioleau]

Hello, what remains to do for this PR ?

[EmilyBourne]

Hello, what remains to do for this PR ?

I am still waiting for a reply on these threads:
#214 (comment)
#214 (comment)

from @mknaranja or @HenrZu to determine what (if anything) remains to be done

[tpadioleau]

Ok for me.