pyop3: compiled assignment in "inc" mode gives wrong values in parallel

Aperta
  • Qualcosa non va?
#5,642 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
compilers, distributed-systems

Direzione di ricerca

Start by running the reproduction script under mpiexec -n 2 and -n 3, comparing the "array" and "compile" eager strategies on the owned entries. The issue points at the compiled INC assignment visiting ghost entries before the halo exchange adds them to their owners. Done means the compile strategy matches the array strategy on 2 and 4 ranks, and the maintainers have decided whether INC on a whole Dat with ghosts is supported.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

On more than one rank, an eager pyop3 assignment in "inc" mode with eager_strategy="compile" gives wrong values. The "array" strategy gives the right values.

from firedrake import *
import numpy as np

mesh = UnitSquareMesh(6, 6)
V = FunctionSpace(mesh, "CG", 1)
g = Function(V).assign(1)

for strategy in ["array", "compile"]:
    f = Function(V).assign(1)
    f.dat.assign(g.dat, "inc", eager=True, eager_strategy=strategy)
    nwrong = mesh.comm.allreduce(np.count_nonzero(f.dat.data_ro != 2))
    PETSc.Sys.Print(f"{strategy}: {nwrong} owned entries differ from 2")

On main (ed5fcad68) with mpiexec -n 3 this prints

array: 0 owned entries differ from 2
compile: 31 owned entries differ from 2

On 1 rank both strategies are correct. On 2 and 4 ranks the compile strategy gives 19 and 29 wrong owned entries. The lazy form f.dat.iassign(g.dat)() gives the same wrong values, and so does op3.loop(p := V.nodes.iter(), f.dat[p].iassign(g.dat[p]), eager=True).

The wrong entries are the owned entries that are ghost entries on other ranks. Each of them gets g once from its own rank and once more from every rank that holds it as a ghost, so its value is 2 plus the number of ghost copies. Before the halo exchange the ghost entries hold 0 + g, so the compiled assignment visits them as well, and the INC halo exchange then adds them to their owners.

Is "inc" meant to work for an assignment to a whole Dat with ghost entries? Or is INC only valid in a loop over owned entities?

An LLM (Claude Code) found this while I was digging into other pyop3 assignment work. G-ADOPT does not use this path but I am flagging it anyway.

Lingua principale
Python
Stelle
684
Fork
204
Merge medio
4g 14h
PR unite (30g)
46

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di firedrakeproject/firedrake

Tutte le issue di firedrakeproject/firedrake

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.