Improve Enum Names and Remove Unused Color Enum

[julianlitz]

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]

Codecov Report

❌ Patch coverage is 98.03922% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.67%. Comparing base (c5811e0) to head (b136bf7).

Files with missing lines	Patch %	Lines
include/GMGPolar/utils.h	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #298   +/-   ##
=======================================
  Coverage   95.67%   95.67%           
=======================================
  Files          79       79           
  Lines        8640     8640           
=======================================
  Hits         8266     8266           
  Misses        374      374           

☔ View full report in Codecov by Harness.
📢 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]

LevelType can be made const in lots of places but not on my prio list :)

[EmilyBourne]

Why this change? Isn't it safer to return a ConstVector from a const object?

[julianlitz]

I think
return Vector const is the correct one in our context.

It returns a const pointer of vector which entries can be modified.

[julianlitz]

For me both getters are "const" so it only makes sense to keep the Vector one.

[EmilyBourne]

From a purely IT standpoint I agree, however from a readability/beginner-friendly point of view I am not sure I agree.

Most people understand const to mean that the object and its contents cannot be modified. This is what is enforced in the version on main. In reality Vector<double> rhs(); can be marked const as it does not change the class (as the pointer points to the same thing), however adding it prevents us from separating out the case returning Vector<double> from the case returning ConstVector<double>. Given that the const annotation is mostly there to prevent developers from making changes to objects that are not expected to change, I think this separation is useful from a user-friendliness standpoint.

A similar change was made in the matrix getter/setters however there the case was slightly different. In that case the constness didn't come from GMGPolar developers trying to enforce correct usage of GMGPolar, rather it came from Kokkos making everything copied to GPU const to reflect the fact that modifications to members won't be auto-copied back to CPU. This made it impossible to avoid adding const to the setters.

[julianlitz]

"Most people understand const to mean that the object and its contents cannot be modified."

Yes thats why I implemented it like that a year ago. Usually const means that also the entries cant be modified.

---

However with Kokkos we no longer interpret our vectors as objects.
They are interpreted as pointers.
Thus for me the new version reflects that correctly.

[EmilyBourne]

However with Kokkos we no longer interpret our vectors as objects.
They are interpreted as pointers.
Thus for me the new version reflects that correctly.

This is why I say that I agree from an IT standpoint.

But in my experience most people (especially beginners) do not notice that a Kokkos view is simply a pointer. Your new version reflects the reality from an IT standpoint. But from experience in other code bases, this implementation is a trip hazard for beginners and doesn't bring any advantages for non-beginners