Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(amr): regrid cadence + buffer zone so a forest can be reused across timesteps

Abierto
  • ¿Algo no está bien?
#72 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
julia
Área
performance

Línea de trabajo

Start with regrid! in src/amr.jl and the PreparedForest generation checks in src/linalg.jl, then inspect the cadence and operator use in examples/monodomain_amr.jl and examples/niederer_benchmark.jl. Review the AMR documentation and regrid! docstring requirements. Done means buffered regridding, documented cadence and reuse, updated examples, and a phase breakdown comparable to #49.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

From Dennis Ogiermann, 2026-08-14: "We can recycle the grid over several timesteps (if you are not already doing this) to speed things further up."

Answering the parenthetical first

Partly, yes — and the part that is already right is the invalidation boundary. regrid! returns its input fields unchanged and leaves the forest generation untouched when the marks change nothing, so existing prepared operators stay valid (src/amr.jl:29-32); and PreparedForest refuses to run against a bumped generation rather than silently computing garbage (src/linalg.jl:525-530). That is the hard part and it is done.

Everything above that line is hand-rolled or unused.

What's missing

(a) Cadence is a constant in each example, not an API. examples/monodomain_amr.jl:41 has REGRID_EVERY = 20; examples/niederer_benchmark.jl:91 has REGRID_EVERY = 50, used at :450 and followed by a manual rebuild of Lop = diffusion_operator(bf) at :457. Two examples, two different numbers, no guidance anywhere on how to pick one, and no way for a user to discover the pattern short of reading an example.

(b) There is no buffer / safety zone, which is the thing that makes a long interval correct. If the forest is only re-marked every k steps, a depolarization wavefront can leave the refined region during those k steps and be integrated on coarse cells — a silent accuracy loss with no error and no assertion. The standard fix (Berger–Colella) is to dilate the refine marks by a buffer of b cells before balancing, so that b bounds how far the front can travel within the interval: roughly b ≥ k · v · Δt / h. Without a buffer, the safe interval is bounded by a property nobody has written down, which is why the two examples disagree by a factor of 2.5 and neither can justify its number.

(c) The reuse the generation guard already permits is not being taken. Neither AMR example calls prepare at all. examples/monodomain_amr.jl:62 does laplacian(bf) * V — a fresh allocating BlockField every single step — on the 19 out of every 20 steps where the forest generation is unchanged and a PreparedForest would be valid. examples/niederer_benchmark.jl:178 at least reuses a preallocated LV via apply!, but still never prepares, so it re-walks the tree and re-warms the exchange schedule instead of holding the prepared state across the 49 steps where it is valid.

Proposal

  • Add a buffer keyword to regrid! that dilates the refine marks by b cells (or blocks) before 2:1 balancing, so a longer interval is safe by construction rather than by luck. Document the b ≥ k · v · Δt / h reasoning next to it.
  • Document the canonical adaptive time-stepping loop — regrid on a cadence, re-prepare only when the generation bumps, reuse otherwise — in the AMR docs page and in the regrid! docstring, which currently explains invalidation without showing the reuse it enables.
  • Convert both AMR examples to that loop, which is also the honest way to measure whether it helps.

Expected payoff, stated honestly

Not what the phrasing suggests. #49 measured this already: the coarse–fine halo exchange is the AMR tax at roughly 92% of an apply, and regridding is not. So skipping regrids does not buy much, and any claim that it does should be treated as unmeasured.

What is real is (c) — the per-step BlockField allocation in the monodomain example is pure waste on 95% of steps, and the package already has the mechanism to remove it. And (b) is a correctness win, not a speed win: it is what lets the interval grow at all without quietly under-resolving the front.

The check that would falsify all of this is a phase breakdown comparable to #49's, before and after, on examples/niederer_benchmark.jl. If t_regrid and the allocation count do not move, the issue was wrong.

Adjacent

The per-call boundary_rhs re-allocation is tracked in #73's affine-term checklist item, under the #81 SciML umbrella, not here.

—
🤖 Claude evicted a paragraph from this one that was already living rent-free in #73.
claude-opus-5-5[1m] (high) · claude-code 2.1.285 · unreviewed

Lenguaje dominante
Julia
Estrellas
3
Forks
1
Merge medio
1 d 11 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RallypointOne/MatrixFreeOperators.jl

Todos los issues de RallypointOne/MatrixFreeOperators.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.