Extend data access API

[benegee]

New

• trixi_ndofs(int handle);
• trixi_ndofsglobal(int handle);
• trixi_ndofselement(int handle);
• trixi_nnodes(int handle);
• trixi_load_primitive_vars(int handle, int variable_id, double * data);
• trixi_load_node_reference_coordinates(int handle, double* node_coords);
• trixi_load_node_weights(int handle, double* node_weights);

Breaking changes

• trixi_nelementsglobal(int handle); (was trixi_nelements_global(int handle);)
• trixi_load_element_averaged_primitive_vars(int handle, int variable_id, double * data); (was trixi_load_cell_averages(double * data, int handle);

Conventions

Adopt https://trixi-framework.github.io/Trixi.jl/stable/conventions/#Cells-vs.-elements-vs.-nodes. For libtrixi, avoid "cell" in favor of "element".

Related #43

[sloede]

Looks sensible to me. Just note that changing the public API requires a breaking release. That's OK, of course.

Alternatively, you could consider to only extend the API, e.g., by adding a new trixi_load_cell_average or trixi_load_cell_averages_single function. That has the advantage that you can still decide to introduce a breaking change later. It has the downside, that you need more tests.

[codecov]

Codecov Report

Attention: Patch coverage is 97.20280% with 4 lines in your changes missing coverage. Please review.

Project coverage is 83.92%. Comparing base (3a813d2) to head (aa45b69).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
examples/trixi_controller_mpi.f90	0.00%	3 Missing ⚠️
examples/trixi_controller_mpi.c	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
+ Coverage   81.75%   83.92%   +2.16%     
==========================================
  Files          21       21              
  Lines         773      877     +104     
  Branches       52       52              
==========================================
+ Hits          632      736     +104     
  Misses        137      137              
  Partials        4        4              

Flag	Coverage Δ
unittests	83.92% <97.20%> (+2.16%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[sloede]

Looks mostly good to me, but I think there are some structural decisions to be made (or maybe they have been made but I am just not aware 😬)

[benegee]

Say I want to stay as close to Trixi.jl as possible and have read
https://trixi-framework.github.io/Trixi.jl/stable/conventions/#Cells-vs.-elements-vs.-nodes
would there be any place in libtrixi where "cell" should be used?

[sloede]

Say I want to stay as close to Trixi.jl as possible and have read https://trixi-framework.github.io/Trixi.jl/stable/conventions/#Cells-vs.-elements-vs.-nodes would there be any place in libtrixi where "cell" should be used?

IMHO only when talking about mesh-related operations that are independent of the solver. For example, querying the number of cells is usually not something you need, since you are rather interested in the actual elements (i.e., cells with solver data attached to it), which might or might not have a one-to-one relation with the cells.

From the top of my head, I don't see many occasions where the word "cell" would come up as part of an API name.

[benegee]

Great! Thanks for your hints!

This is now totally cell-free. And totally breaking.

[benegee]

Thanks for reviewing @sloede !
PackageCompiler is still failing. I had to discard my plan to resolve this via #207 because there seem to be some new issues.
It would however be great to merge this anyway.