Follow standard CMake layout by EmilyBourne · Pull Request #214 · SciCompMod/GMGPolar

EmilyBourne · 2026-04-20T13:17:41Z

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.

… to gmgpolar

EmilyBourne · 2026-04-20T13:31:34Z

@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 · 2026-04-21T12:31:53Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.72%. Comparing base (5952563) to head (6a9c5da).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #214   +/-   ##
=======================================
  Coverage   90.72%   90.72%           
=======================================
  Files          86       86           
  Lines        9473     9473           
=======================================
  Hits         8594     8594           
  Misses        879      879

☔ 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.

tpadioleau

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

tpadioleau · 2026-04-20T14:33:05Z

 target_include_directories(InputFunctions_BoundaryConditions PUBLIC
-    ${CMAKE_CURRENT_SOURCE_DIR}
-    ${CMAKE_SOURCE_DIR}/include/InputFunctions/BoundaryConditions
+    ${GMGPOLAR_INCLUDE_DIRS}
 )


Is it possible to replace by target_link_libraries(InputFunctions_BoundaryConditions PUBLIC GMGPolarLib) ? I think the target GMGPolarLib should be responsible to bring these headers.

It is possible. This seemed more logical to me as the files in InputFunctions include files that are never used in GMGPolarLib (e.g. the associated .hpp files for these .cpp files) so GMGPolarLib is not needed to compile the InputFunctions for testing.

E.g. in theory we could use InputFunctions in https://github.com/gyselax/gysela-mini-app_poisson even when testing a different solver

@tpadioleau Does the comment above change your opinion on how the include directory is included or do you still think we should link the library?

tpadioleau · 2026-04-21T08:02:33Z

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.

I didn't check, I just reorganised what was already in the existing CMake files. Probably a question for @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.

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

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 · 2026-04-21T08:05:30Z

 target_include_directories(InputFunctions INTERFACE
-    ${CMAKE_SOURCE_DIR}/include/InputFunctions
-)
+    ${GMGPOLAR_INCLUDE_DIRS}


Same question, is it possible to replace by target_link_libraries(InputFunctions_BoundaryConditions PUBLIC GMGPolarLib) ?

tpadioleau · 2026-04-21T08:05:59Z

+install(TARGETS
+    InputFunctions
+    InputFunctions_BoundaryConditions
+    InputFunctions_DensityProfileCoefficients
+    InputFunctions_DomainGeometry
+    InputFunctions_ExactSolution
+    InputFunctions_SourceTerms
+    EXPORT GMGPolarTargets
+    ARCHIVE DESTINATION lib
+)


Do they actually need to be installed ?

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

tpadioleau · 2026-04-21T16:32:47Z

-    ${CMAKE_CURRENT_SOURCE_DIR}
-    ${CMAKE_SOURCE_DIR}/include/InputFunctions/DomainGeometry
-)
+    ${GMGPOLAR_INCLUDE_DIRS}


Same question, is it possible to replace by target_link_libraries(InputFunctions_BoundaryConditions PUBLIC GMGPolarLib) ?

julianlitz · 2026-04-22T21:59:27Z

Compiles on my machine 👍🏼

Co-authored-by: Thomas Padioleau <thomas.padioleau@cea.fr>

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).

HenrZu · 2026-04-24T10:37:17Z

-target_link_libraries(convergence_order PRIVATE GMGPolarLib)
-target_link_libraries(weak_scaling PRIVATE GMGPolarLib)
-target_link_libraries(strong_scaling PRIVATE GMGPolarLib)
+target_link_libraries(gmgpolar PRIVATE GMGPolarLib GMGPolarInterface)


im not really familiar with the structure. But these executables are built but not installed. Is this intentional? If yes, maybe add a comment :)

This is where we need feedback from the GMGPolar team. It is related to the comment above : #214 (comment)

It depends on how you see GMGPolar.
Is it a library? I.e. something designed to provide tools to other bigger tools (e.g. simulations, gyselalib++, etc)
Or is it a tool in its own right? I.e. does it make sense to have access to the executables but not the code?

My impression was that it is more of a library so I have implemented it like this for now. But that also raises the question of whether GMGPolarInterface should be included in that library or not?
In any case I suspect that it does not make sense to install convergence_order, weak_scaling and strong_scaling as I'm not sure these are particularly useful if you can't modify the code to try different test cases?

I think if you would export it as a library than you might need the sourceTerm.h concept definitions, but not all source term specific test case examples.

And the main.cpp etc are just for testing purposes and are probably also not part of a library.

The current setup is:

All include files are installed

Everything except src/ConfigParser/* and src/InputFunctions/* is compiled into the GMGPolarLib target

src/ConfigParser/* and src/InputFunctions/* are compiled into a GMGPolarInterface library

As an example of end users:

gyselalib++ would use GMGPolarLib to provide a solver for the equation and would be happy to not have to compile GMGPolarInterface

gysela-mini-app_poisson (a mini-app designed to compare different solvers) would do the same but could also use GMGPolarInterface to avoid having to write our own test cases.

@HenrZu What is your opinion?

Co-authored-by: Thomas Padioleau <thomas.padioleau@cea.fr>

tpadioleau · 2026-04-27T10:11:24Z

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

EmilyBourne added 11 commits April 20, 2026 14:09

Use directory agnostic imports

7eb9e54

Move package searches to root. InputFunctions only needs to be linked…

ed53411

… to gmgpolar

Link includes cleanly

ec909eb

All tests use input

1351a29

Set C++ standard globally

18a3cbe

Move LIKWID and MUMPS target definition to cmake/FindX.cmake files

4e46726

Try for a local version of GTest

08d6ffb

Prefer project paths

ed80423

Add an install target

bdd3cd2

Add GMGPolarTargets to ensure we can do find_package(GMGPolar)

7d43a70

Use different include paths for local build vs installed library

a01d03e

Clang format

7392ea6

EmilyBourne force-pushed the ebourne_cleanup_cmake branch from 69ca3ed to 7392ea6 Compare April 21, 2026 07:35

EmilyBourne mentioned this pull request Apr 21, 2026

Create an action to install METIS/MUMPS #217

Merged

14 tasks

EmilyBourne added 2 commits April 21, 2026 11:24

Merge remote-tracking branch 'GMGPolar/main' into ebourne_cleanup_cmake

7a1850f

Fix merge

6e94e02

EmilyBourne force-pushed the ebourne_cleanup_cmake branch from 6a681a8 to 6e94e02 Compare April 21, 2026 10:29

EmilyBourne added 3 commits April 21, 2026 13:52

Merge remote-tracking branch 'GMGPolar/main' into ebourne_cleanup_cmake

2106436

Create GMGPolarInterface to hold all CLI/testing interface objects

edaf7d4

MUMPS dependencies

adaca6d

EmilyBourne requested a review from mknaranja April 21, 2026 12:34

EmilyBourne mentioned this pull request Apr 21, 2026

Add GMGPolar as a possible IPolarPoissonLikeSolver gyselax/gyselalibxx#644

Open

15 tasks

tpadioleau suggested changes Apr 21, 2026

View reviewed changes

EmilyBourne added 2 commits April 22, 2026 09:29

Add target aliases

4ee7dbb

Can't export aliases

c2da216

Only C++ component required

3678f5c

Co-authored-by: Thomas Padioleau <thomas.padioleau@cea.fr>

HenrZu requested changes Apr 24, 2026

View reviewed changes

EmilyBourne added 4 commits April 24, 2026 13:12

Tests should not be its own project

0bacedc

Add QUIET to find_package(GTest)

063b52c

Version already set

f33f81d

Duplicate C++ version specification

b101c71

EmilyBourne requested review from HenrZu and tpadioleau April 24, 2026 11:43

tpadioleau reviewed Apr 26, 2026

View reviewed changes

Comment thread CMakeLists.txt Outdated

tpadioleau reviewed Apr 26, 2026

View reviewed changes

Comment thread CMakeLists.txt

Enable Fortran instead of choosing project languages based on USE_MUMPS

e1ca3ba

Co-authored-by: Thomas Padioleau <thomas.padioleau@cea.fr>

tpadioleau reviewed Apr 27, 2026

View reviewed changes

Comment thread CMakeLists.txt Outdated

Clear duplicate project declaration

0ba4a9e

tpadioleau mentioned this pull request Apr 30, 2026

Review ebourne cleanup cmake #234

Merged

14 tasks

tpadioleau and others added 4 commits April 30, 2026 14:00

Review ebourne cleanup cmake (#234)

6971888

Merge branch 'main' into ebourne_cleanup_cmake

924e13f

Merge branch 'main' into ebourne_cleanup_cmake

626bd01

Fix merge

6a9c5da

Conversation

EmilyBourne commented Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge Request - GuideLine Checklist

Checks by code author:

Checks by code reviewer(s):

Uh oh!

EmilyBourne commented Apr 20, 2026

Uh oh!

codecov Bot commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tpadioleau left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

julianlitz Apr 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mknaranja Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

julianlitz commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HenrZu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

julianlitz Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tpadioleau commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

EmilyBourne commented Apr 20, 2026 •

edited

Loading

codecov Bot commented Apr 21, 2026 •

edited

Loading

julianlitz Apr 25, 2026 •

edited

Loading

mknaranja Apr 29, 2026 •

edited

Loading

julianlitz commented Apr 22, 2026 •

edited

Loading

julianlitz Apr 24, 2026 •

edited

Loading

tpadioleau commented Apr 27, 2026 •

edited

Loading