Provide density profile coefficients from grid index

[EmilyBourne]

Provide density profile coefficients from grid index instead of expecting an analytical expression.

This input seems to have been forgotten when we did this work for other inputs. Without this change Gyselalib++ needs to interpolate the coefficients in order to provide the values at any point in space.

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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.49%. Comparing base (8e52bf2) to head (3c27bcd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #313   +/-   ##
=======================================
  Coverage   97.49%   97.49%           
=======================================
  Files          79       79           
  Lines        8629     8639   +10     
=======================================
+ Hits         8413     8423   +10     
  Misses        216      216           

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

All good

[julianlitz]

After this PR I would probably recommend to remove the level local alpha and beta cache vectors if the call alpha(i,j) doesnt do any computations and only retrieves from a vector.
This reduces the memory consumption from
O(11 * dofs) down to O(9 * dofs) for the Take method while the runtime should stay the same.

Memory consumption in 64-bit vector equivalents on level 0:
3N: Solution, Rhs, Residual
2N: Symmetric tridiag smoother matrix
4N: arr, art, att, detDF
2N: alpha, beta
(2N: pcg_solution, pcg_search-direction)

I can create a corresponding PR if that is something we want to do.

[EmilyBourne]

After this PR I would probably recommend to remove the level local alpha and beta cache vectors if the call alpha(i,j) doesnt do any computations and only retrieves from a vector. This reduces the memory consumption from O(11 * dofs) down to O(9 * dofs) for the Take method while the runtime should stay the same.

Memory consumption in 64-bit vector equivalents on level 0: 3N: Solution, Rhs, Residual 2N: Symmetric tridiag smoother matrix 4N: arr, art, att, detDF 2N: alpha, beta (2N: pcg_solution, pcg_search-direction)

I can create a corresponding PR if that is something we want to do.

Currently in my tests GMGPolar is slower than our other solver which is unexpected so if you have any ideas to speed things up this could be good. Currently my main hypothesis is that the difference comes from the fact that the other solver allows us to provide an initial guess to reduce the number of iterations whereas GMGPolar doesn't allow this

[julianlitz]

@EmilyBourne Can you show me the output when using

verbose=1 and
solver.printTimings()

?