Skip to content

Replace Interpolation macros with type-safe functions#169

Open
julianlitz wants to merge 1 commit intomainfrom
litz_inline_interpolation
Open

Replace Interpolation macros with type-safe functions#169
julianlitz wants to merge 1 commit intomainfrom
litz_inline_interpolation

Conversation

@julianlitz
Copy link
Collaborator

@julianlitz julianlitz commented Feb 3, 2026

Summary

This PR replaces the macros with inline functions to improve type safety and code maintainability without sacrificing performance. This is part of the broader effort to eliminate macro usage throughout GMGPolar.

Motivation

As discussed in #149, macros are error-prone and bypass C++'s type system, making bugs harder to catch at compile time. Macros in GMGPolar are currently used for code inlining, but modern C++ compilers handle inline functions just as efficiently in release builds while providing:

  • Type safety: Compile-time type checking prevents misuse
  • Better debugging: Functions appear in debuggers and stack traces
  • Scope safety: No unintended name collisions or side effects

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
Copy link

codecov bot commented Feb 3, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.82%. Comparing base (eaf5d34) to head (675e18f).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
+ Coverage   89.41%   89.82%   +0.40%     
==========================================
  Files          91       91              
  Lines        5241     5452     +211     
==========================================
+ Hits         4686     4897     +211     
  Misses        555      555              

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

Comment on lines 24 to 26
#pragma omp for nowait
for (int i_r_coarse = 0; i_r_coarse < coarse_grid.numberSmootherCircles(); i_r_coarse++) {
int i_r = i_r_coarse * 2;
for (int i_theta_coarse = 0; i_theta_coarse < coarse_grid.ntheta(); i_theta_coarse++) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should a collapse be added now that the order is not important?

Copy link
Collaborator Author

@julianlitz julianlitz Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be slightly more efficient if we define variables inside the first loop when possible, but doesn't make a big difference here.

for i=...

    var = f(i)

    for j= ...

        var2 = g(var)

    end

end

for i=...

    for j= ...

        var = f(i)

        var2 = g(var)

    end

end

I havent tried collapsing yet and I don't think it would do much.

Should be enough to parallize the outer loop and then access memory sequentially inside the 2nd loop.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EmilyBourne Collapsing might be interesting for gpu though

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. For OpenMP it probably won't help. For GPU it will be necessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants