Template Level on DomainGeometry

[EmilyBourne]

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]

I can take a look at it tomorrow evening.

[codecov]

Codecov Report

❌ Patch coverage is 89.75069% with 185 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.36%. Comparing base (b3b9c52) to head (07afaab).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
include/GMGPolar/utils.h	47.74%	81 Missing ⚠️
include/GMGPolar/setup.h	55.55%	80 Missing ⚠️
include/GMGPolar/solver.h	94.64%	12 Missing ⚠️
...tSolver/DirectSolver-CSR-LU-Give/matrixStencil.inl	94.44%	2 Missing ⚠️
...tSolver/DirectSolver-CSR-LU-Take/matrixStencil.inl	94.44%	2 Missing ⚠️
...oother/ExtrapolatedSmootherGive/solveAscSystem.inl	97.29%	2 Missing ⚠️
...oother/ExtrapolatedSmootherTake/solveAscSystem.inl	97.29%	2 Missing ⚠️
include/Smoother/SmootherGive/solveAscSystem.inl	97.05%	2 Missing ⚠️
include/Smoother/SmootherTake/solveAscSystem.inl	97.05%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #190      +/-   ##
==========================================
+ Coverage   94.91%   95.36%   +0.44%     
==========================================
  Files          94       86       -8     
  Lines        9516     9638     +122     
==========================================
+ Hits         9032     9191     +159     
+ Misses        484      447      -37     

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

[julianlitz]

The code is not formatted correctly in every file.
At least if I save the file, then some braces and indentation change.
@EmilyBourne Am I allowed to commit code formatting changes to your branch?

[julianlitz]

I would argue it would make sense to move everything unrelated to the interface in the gmgpolar.h to not have everything spread out as it is currently.

[EmilyBourne]

I would argue it would make sense to move everything unrelated to the interface in the gmgpolar.h to not have everything spread out as it is currently.

Currently even the interface is not entirely in igmgpolar as the function:

    template <concepts::BoundaryConditions BoundaryConditions>
    void solve(const BoundaryConditions& boundary_conditions, const SourceTerm& source_term); 

cannot be virtual.

The argument for keeping the separation was to be able to keep .cpp files to help with compilation speed. But it looks like there's very few functions left so maybe this is not worth it anymore

[EmilyBourne]

The code is not formatted correctly in every file. At least if I save the file, then some braces and indentation change. @EmilyBourne Am I allowed to commit code formatting changes to your branch?

Strange that clang-format doesn't complain. Maybe because I called them *.inl. I should rename them to *.h

[julianlitz]

@EmilyBourne I already merged the solver.inl and solver.h together to avoid the .inl.

Also I swapped a few things around to make it clearer what sthings are part of the Interface and what is part of the GMGPolar class.

[julianlitz]

Maybe merge the litz_ebourne_template_level branch into yours? 👉🏼👈🏼

[julianlitz]

@EmilyBourne You can check the compilation speed of my new version to check if there is a big slow down if we move everything into the header.

[julianlitz]

[EmilyBourne]

@EmilyBourne You can check the compilation speed of my new version to check if there is a big slow down if we move everything into the header.

Actually there is only 1min difference between main and this branch! 5mins to compile on main, 6 here according to my laptop

[julianlitz]

Yes I also noticed a small slow down but it's unavoidable since Level needs to be templated.