Dask client handling in TPI/SS: unguarded scatter breaks serial runs; SS re-scatters params every residual evaluation

Aperta
  • Qualcosa non va?
#1,211 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à
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
57/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend, performance

Direzione di ricerca

Read ogcore/TPI.py around line 969 and its serial fallback around line 1039, then compare the guarded scatter handling in ogcore/SS.py around line 292. Also trace SS.inner_loop from SS_fsolve to verify how often parameters are scattered. Done means TPI works with client=None and SS reuses the scattered parameters rather than broadcasting them on every residual evaluation.

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

Descrizione

1. run_TPI raises when client=None

client.scatter at TPI.py:969 is called unconditionally at function-body indentation:

    # Scatter the parameters
    scattered_p_future = client.scatter(p, broadcast=True)

SS.inner_loop guards the equivalent block with if client: (SS.py:292), but TPI does not. So run_TPI(p, client=None) fails with AttributeError: 'NoneType' object has no attribute 'scatter' before the loop is entered — which makes the serial fallback at TPI.py:1039 unreachable in exactly the case it exists for.

Fix is to wrap the scatter/restore block in if client: and pass p directly when there is no client, mirroring SS.

2. SS.inner_loop re-scatters the parameters on every residual evaluation

client.scatter(p, broadcast=True) sits inside inner_loop (SS.py:304), which is called once per outer residual evaluation by SS_fsolve. The Specifications object is therefore re-serialised and re-broadcast to every worker dozens of times per steady-state solve, while p does not change across those calls.

run_TPI already does this correctly — scatter once before the loop, reuse the future. Hoisting the SS scatter into run_SS (or caching the future on the client) would match that pattern and remove the repeated broadcast.

I can open a PR for (1) straight away; happy to do (2) in the same PR or separately, whichever you prefer.

Lingua principale
Python
Stelle
85
Fork
153
Merge medio
1g 19h
PR unite (30g)
19

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 PSLmodels/OG-Core

Tutte le issue di PSLmodels/OG-Core

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.