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

All modified and coverable lines are covered by tests ✅

Project coverage is 82.76%. Comparing base (acaf98e) to head (66ee664).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
+ Coverage   80.27%   82.76%   +2.48%     
==========================================
  Files          19       19              
  Lines         715      818     +103     
  Branches       50       50              
==========================================
+ Hits          574      677     +103     
  Misses        137      137              
  Partials        4        4              

Flag	Coverage Δ
unittests	82.76% <100.00%> (+2.48%)	⬆️

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.

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