Iterator api

[j-fu]

Use iterator api for 2D function plot as a first attempt to generalize to discontinuous and higher order plots.

Linked to WIAS-PDELib/GridVisualizeTools.jl#3

[j-fu]

@chmerdon, this would be the API idea: write an iterator over local subtriangles.
This also would be the solution for #22.

[Copilot]

Pull Request Overview

Generalizes 2D plotting using an iterator-based API for simplex grids, paving the way for discontinuous and higher-order visualizations.

• Introduces a new LinearSimplices iterator type and integrates it into marching_triangles.
• Adds dedicated tests in test/griditerators.jl to verify allocation limits and correctness across dimensions.
• Exposes LinearSimplices in GridVisualize and updates module imports.

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
test/runtests.jl	Includes the new griditerators.jl in the main test suite
test/griditerators.jl	Adds a test set for testloop over 1D–3D grids, checking both result and allocations
src/griditerator.jl	Defines the LinearSimplices struct and its iterate implementation
src/common.jl	Refactors marching_triangles to use LinearSimplices
src/GridVisualize.jl	Adds ChunkSplitters import, includes griditerator.jl, and exports LinearSimplices

Comments suppressed due to low confidence (2)

src/griditerator.jl:1

• [nitpick] Add a docstring for LinearSimplices describing its purpose, type parameters, and keyword arguments (gridscale, nthreads) to improve discoverability and maintainability.

struct LinearSimplices{D, Tc, Ti, Tf} <: LinearSimplexIterator{D}

src/GridVisualize.jl:19

• Since ChunkSplitters is a new dependency, ensure it is added to Project.toml so the package will install correctly.

using ChunkSplitters

[Copilot]

[nitpick] Use an explicit path with @__DIR__ to ensure the file is found regardless of working directory, e.g., include(joinpath(@__DIR__, "griditerators.jl")).

Suggested change

	include("griditerators.jl")
	include(joinpath(@__DIR__, "griditerators.jl"))

[Copilot]

[nitpick] The magic number 256 is unexplained; consider defining a named constant (e.g. MAX_ALLOC_BYTES) or adding a comment on how this threshold was chosen.

Suggested change

	@test nalloc < 256 # allow for some allocations
	@test nalloc < MAX_ALLOC_BYTES # Threshold for memory allocation to ensure efficiency

[Copilot]

Here func (a user-provided function) is passed directly as the values vector to LinearSimplices. You likely need to evaluate func at each node coordinate to build a numeric vector before constructing the iterator.

[Copilot]

Similarly, funcs[i] is passed in place of a values vector. You should apply each funcs[i] over the corresponding grid nodes to produce the values vector for LinearSimplices.

Suggested change

	all_ls = [LinearSimplices(grids[i], funcs[i]; gridscale) for i in 1:length(grids)]
	all_ls = [LinearSimplices(grids[i], funcs[i](grids[i][Coordinates]); gridscale) for i in 1:length(grids)]

[j-fu]

The idea is that instead of passing a grid and a vector, users would implement a LinearSimplices constructor of a interator over triangles/tests possibly created on the fly

In the moment, this PR just replaces the marching_triangles method called in the extensions by one which uses LinearSimplices.

[pjaap]

I reviewed this approach and I like it in general.

I have two major complaints:

1. the PR in GridVisualizeTools is divergent from the main branch since the marching_triangles method changed recently. It is unfortunately not straight forward to rebase. This should be done in a small pair programming session.
2. The value handing in LinearSimplices. Should this be the general class for the iterators of just a concept of an iterator? This is the standard continuous data approach since it assigns values to nodes shared by multiple triangles. We should discuss how to pass values for each grid cell in a certain order

[j-fu]

I reviewed this approach and I like it in general.

I have two major complaints:

1. the PR in GridVisualizeTools is divergent from the main branch since the marching_triangles method changed recently. It is unfortunately not straight forward to rebase. This should be done in a small pair programming session.

I think this is natural: I think we may needto keep two versions of it: one for iterators ande for grid data. Of course they should use as much common code as possible. Same formarching_tetrahedra`.

2. The value handing in LinearSimplices. Should this be the general class for the iterators of just a concept of an iterator? This is the standard continuous data approach since it assigns values to nodes shared by multiple triangles. We should discuss how to pass values for each grid cell in a certain order

No, this is just an example for two things:

• Replacement of the marching_* functions for grids with linear simplices in GridVisualize - we would gain multithreading from this.
• Prototype for ConstantSimplices, DiscontinuousLinearSimplices and whatever users write for higher order elements and general element geometries.

As a result, a new "gridless" core API for GridVisualize could emerge.