search

trixi-framework / Trixi.jl

Trixi.jl: Adaptive high-order numerical simulations of conservation laws in Julia
https://trixi-framework.github.io/Trixi.jl
MIT License
533 stars 108 forks source link

Unified interface `ncells` for all mesh types #923

Open ranocha opened 3 years ago

ranocha commented 3 years ago

I recognized this while reviewing https://github.com/trixi-framework/Trixi2Vtk.jl/pull/47. Right now, we don't have a unified interface to access the number of cells of a given mesh. Based on our naming conventions and the existing example of ncells(mesh::P4estMesh), I propose to implement a method ncells for each mesh type and document it as official API.

When we do that, we should update Trixi2Vtk accordingly.

CC @andrewwinters5000

sloede commented 3 years ago

Good idea. Note that we also use n_cells in parts of Trixi, mostly for mesh I/O. This should IMHO be unified as well then. Since it means that I/O files change if applied consistently, this might become a breaking change then.

andrewwinters5000 commented 3 years ago

I agree. This would also condense the new Trixi2Vtk slightly. As far as I could tell, the StructuredMesh and UnstructuredMesh2D always use the eachelement(solver, cache) for the loops and would only need such an n_cells function for mesh I/O (as already noted by @sloede ).

ranocha commented 3 years ago

Yes, that's exactly the use case - and the reason why I didn't bother implementing something like this so far. I have mostly been working on the solver side where we have eachelement and nelements. However, ncells would be used for mesh-only stuff where we have neither a solver nor a cache.