Handle Openmp num threads via Kokkos

[EmilyBourne]

Previously the number of threads was set at each individual loop. This is error prone as it can easily be forgotten on 1 loop. It is safer to set the number of threads once and for all using omp_set_num_threads. However Kokkos does not use the value of omp_num_threads set via the OpenMP function. Instead the only way to set this information is during the call to Kokkos::initialise (or Kokkos::ScopeGuard) at set up. As we remove explicit OpenMP loops from the code we therefore lose control of the number of threads.

This PR removes the num_omp_threads variable passed throughout the code. It runs the tests with 1 or 16 threads via the macro GMGPOLAR_TEST_THREADS. For the main the number of threads should be specified using:

./gmgpolar --threads=4

or

./gmgpolar --kokkos-threads=4

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.

[julianlitz]

The (num_omp_threads_) parameter at the loops were not really needed. Only in the case if you would run two simultaneous GmgPolar instances with e.g 2 threads each (making the global parameter equal to 4, but you could restrict it to 2 threads for a single instance).

[julianlitz]

I think that the num_omp_thread parameter is basically just used to set the number of threads used in the main.cpp starting from our run.sh script.

Inside the GmgPolar solver it is basically unusued.
I didn't want to set any global thread count numbers inside my solver as it should be done from the outside.

TLDR: Yes we can remove the number of threads variable and modify the run.sh script as you described.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.38%. Comparing base (1a307c5) to head (071d30a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #263      +/-   ##
==========================================
- Coverage   89.42%   89.38%   -0.04%     
==========================================
  Files          79       79              
  Lines        9172     9139      -33     
==========================================
- Hits         8202     8169      -33     
  Misses        970      970              

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