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

feat(distributed): ImplicitGlobalGrid halo backend for multi-node CartesianGrid

Abierto
  • ¿Algo no está bien?
#46 2 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
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
julia
Área
distributed-systems

Línea de trabajo

Start with ext/MatrixFreeOperatorsMDLAExt.jl and the existing _dist_scatter!/_dist_reduce! seam, then prototype IGG's update_halo! with MFO-owned Field storage. Compare init_global_grid with partition_grid and prepare_distributed, and inspect test/multigpu and #30 for multi-node test gating. Done means ext/MatrixFreeOperatorsIGGExt.jl implements the seam, cross-rank adjoint and parameter-gradient checks pass, and halo cost is measured.

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

Descripción

enhancement

Context

Blocked by #47. The IGG backend should plug in through #47's explicit selection API (prepare_distributed(L, IGGBackend(...))), not a second prepare_distributed method alongside MDLA's — today the only method lives in ext/MatrixFreeOperatorsMDLAExt.jl, so a second extension defining the same (operator, integer) signature would be ambiguous.

DESIGN.md §10.4 is now resolved: MDLA first (done), ImplicitGlobalGrid.jl for multi-node next.

MDLA is implemented in ext/MatrixFreeOperatorsMDLAExt.jl behind the _dist_scatter! / _dist_reduce! seam and covers single-node multi-GPU with the adjoint carried through. It cannot go multi-node, and it is CUDA-only. IGG is production-proven GPU-aware MPI halo exchange over a Cartesian MPI topology — exactly our uniform CartesianGrid case, multi-node, CPU+GPU.

This issue is to investigate first, then implement — the investigation gate below is real and may change the shape of the implementation.

Scope

  • In: uniform CartesianGrid, multi-node, CPU + GPU, behind the existing distributed seam, as ext/MatrixFreeOperatorsIGGExt.jl. No new core dependency.
  • Out: multi-node AMR (BlockForest). IGG assumes one fixed uniform Cartesian decomposition; the forest's halo_update! is intra-forest and a distributed forest needs a separate answer. Track that separately if/when it comes up.
  • Not adopted: ParallelStencil.jl. We take IGG's halo only. @init_parallel_stencil(backend, precision, ndims) is module-level global state fixed at load, which is incompatible with keeping GPU support in a weak-dep extension; PS also brings no operator algebra, no linear-solve path, and no AMR. Our hot-stencil escape hatch remains KernelAbstractions @kernel (DESIGN §1.A).

Investigation gate (do this first)

IGG owns its own grid construction (init_global_grid) and array allocation (@zeros). The load-bearing question:

Can update_halo! be driven against MFO-owned Field storage, or is only the topology / MPI-Cartesian-communicator part reusable, with the exchange itself written directly on MPI.jl?

Prototype both far enough to answer it before committing to the extension's shape. If only the topology is reusable, the honest outcome may be "depend on MPI.jl directly and borrow IGG's decomposition logic" — which is a fine result for this issue, just a different one.

Secondary questions for the same prototype:

  • How init_global_grid's global state interacts with partition_grid / prepare_distributed, which already compute local-vs-global ranges. One of the two has to own the decomposition; they must not disagree.
  • Whether the adjoint contract survives: _dist_reduce! must remain the exact transpose of _dist_scatter! across ranks, including the ∂/∂κ scatter-add over owned cells. This is the part with no equivalent anywhere in the IGG/PS ecosystem, and it is the easiest thing to get silently wrong.

Calibrate the expected payoff — do not over-invest in overlap

For the driving workload (reaction–diffusion where a large local ODE dominates each node — cardiac monodomain, ~65 states and ~255 exp per node per step) only the scalar field crosses a boundary while the full state churns over the volume. For a 256³ subdomain that is roughly a 2800:1 byte ratio, so even a naive blocking exchange should cost low single-digit percent of a step.

IGG is being adopted for correctness and multi-node CPU+GPU portability, not because the halo is a bottleneck. Get a correct blocking exchange working and measured before reaching for @hide_communication-style overlap. If a benchmark later shows the exchange is actually material, that is the trigger to revisit — not an assumption to build on.

Done when

  • Investigation gate answered and written down (IGG arrays vs. MFO storage)
  • ext/MatrixFreeOperatorsIGGExt.jl implements _dist_scatter! / _dist_reduce!
  • Adjoint identity ⟨Lx,y⟩ = ⟨x,Lᵀy⟩ verified across ranks, not just within one
  • Parameter-gradient (∂/∂κ) parity against the single-rank result
  • Setup-time exchange of κ's Interface (cut-plane) ghosts, per DESIGN.md §7 Owed by the next backend (from the PR #66 review): no IGG rank holds the global κ, so build each rank's Diffusion leaf through the inner constructor from a rank-local κ (fill_coefficient_ghosts! mirrors the physical ghosts and leaves Interface ones untouched), then run one _dist_scatter!-shaped exchange over those planes at prepare time. Do not reuse _slab_op(::Diffusion) per rank — it throws on an out-of-range view or silently leaves the cut-plane ghosts at zero or the mirror (κ_I/2 face coefficients under ArithmeticMean, 0 under HarmonicMean), and no current guard catches that
  • Multi-node test gated like test/multigpu (see #30), skipped by default
  • Halo cost measured on a realistic domain and recorded, so the overlap question is settled by data

—
🤖 Claude filed the κ-ghost note where it belongs.
claude-opus-5-5[1m] (high) · claude-code 2.1.285 · unreviewed

Lenguaje dominante
Julia
Estrellas
3
Forks
1
Merge medio
1 d 28 min
PR fusionados (30 d)
6

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.