Skip to content

Conversation

@EmilyBourne
Copy link
Collaborator

Use operator()(std::size_t i_r, std::size_t i_theta) instead of rhs_f(double r, double theta) function in SourceTerms. In Pyccel the RHS is known at the grid points. If we pass integers then this information can be used directly. Otherwise an unnecessary interpolation must be added to make the RHS available at every point in space. Otherwise a function must be added to find the nearest grid point to the coordinate. This is also costly when handling non-uniform points. The function is renamed to operator() as this means that when inheritance is removed (see #131) a Kokkos::Vector would be accepted as a SourceTerm. This removes unnecessary function calls.

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 EmilyBourne marked this pull request as draft December 17, 2025 17:01
@EmilyBourne EmilyBourne marked this pull request as ready for review December 18, 2025 10:01
@EmilyBourne EmilyBourne marked this pull request as draft December 18, 2025 14:46
@EmilyBourne EmilyBourne marked this pull request as ready for review December 18, 2025 15:06
@codecov
Copy link

codecov bot commented Dec 18, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.29%. Comparing base (82c83f2) to head (69bc471).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #138   +/-   ##
=======================================
  Coverage   88.28%   88.29%           
=======================================
  Files          89       89           
  Lines        5276     5280    +4     
=======================================
+ Hits         4658     4662    +4     
  Misses        618      618           

☔ 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 EmilyBourne mentioned this pull request Dec 18, 2025
14 tasks
Copy link
Collaborator

@julianlitz julianlitz left a comment

Choose a reason for hiding this comment

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

There is only a single SourceTermFunctions instance available. Since it is used exclusively at level_depth = 0 we can provide the grid at that level and your approach works perfectly as implemented here.

However, this assumption may not hold for DomainGeometry or DensityProfiles if they are invoked across multiple refinement levels (when we would switch to integers there as well).

In those cases, one option would be to always provide the grid at level = 0 and provide an additional argument
operator(i_r, i_theta, level_depth)
and convert internally
double r = grid.radius(i_r << level_depth);
double theta = grid.radius(i_theta << level_depth);.

Another option would be to make PolarGrid a template parameter of
operator<PolarGrid>(i_r, i_theta),
though this could potentially conflict with Kokkos.

Another option:
operator(const PolarGrid& grid, int i_r, int i_theta);

1 Seems a bit hacky
2 Best performance but strange looking template
3 Clear and easy but additional argument

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.

3 participants