Direct use of Projector is never annotated on the pyadjoint tape

Aperta
#5,176 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
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Inizia da adjoint_utils/blocks/solving.py, leggendo ProjectorBase.project e ProjectBlock, insieme al refactoring di CachedSolverBlock in #4638. Traccia come vengono annotate e rieseguite la funzione libera project, Function.project e l’uso diretto di Projector. Il lavoro è completo quando tutti e tre i percorsi vengono registrati sul tape di pyadjoint e la riesecuzione riutilizza il solver memorizzato nella cache di Projector, l’inversa di slate e il comportamento di constant_jacobian.

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

Descrizione

While fixing #5172 (PR #5175) I noticed that using Projector directly records nothing on the pyadjoint tape. Only the free function project and Function.project are annotated; ProjectorBase.project is not, so the projector that the documentation recommends precisely when one wants to reuse the mass solver across repeated projections is invisible to the adjoint. A model that switches from project(f, V) to p = Projector(f, V) plus p.project() for performance silently loses those operations from the tape, with no warning.

The natural fix seems to be to move the annotation onto ProjectorBase.project itself, with the block holding the Projector so that replay reuses its cached solver, slate inverse and constant_jacobian behaviour. SupermeshProjectBlock already works this way. That would give a single annotation point for all three entry paths and would make the replay reproduce the forward computation exactly, rather than reconstructing it from recorded parameters as #5175 does. Since this means restructuring ProjectBlock, which lives in the same part of adjoint_utils/blocks/solving.py that the CachedSolverBlock work in #4638 is reshaping, it probably makes sense to do it on top of that refactor, where a cached projector block would be the natural analogue of the cached solver block.

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.