Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

GradientsFiniteDifference/GradientsSpectral (and PhysicsInformer) silently assume a periodic domain — non-periodic BCs get a wrong residual at the boundary with no warning

Aperta
#2,001 1 commento 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
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, pytorch

Direzione di ricerca

Inizia con GradientsFiniteDifference e GradientsSpectral in physicsnemo/sym/eq/gradients.py, poi leggi PhysicsInformer in physicsnemo/sym/eq/phy_informer.py e i test corrispondenti in test/sym/test_gradients.py. Verifica come vengono esposti i gradienti di livello inferiore basati su torch e rendi esplicita o visibile ai chiamanti l’assunzione che siano supportate solo condizioni al contorno periodiche; il lavoro è completo quando gli utenti non vengono più indotti silenziosamente in errore riguardo alle condizioni al contorno non periodiche.

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

Descrizione

Summary

physicsnemo.sym.eq.gradients.GradientsFiniteDifference and GradientsSpectral — the two grid-based gradient backends PhysicsInformer (physicsnemo/sym/eq/phy_informer.py) exposes via grad_method="finite_difference" / "spectral" — compute derivatives assuming the domain wraps around (periodic boundary conditions), with no parameter to say otherwise and no warning when it doesn't. For any problem with a real physical boundary (Dirichlet/Neumann — the common case, not the exception), the PDE residual returned at the boundary nodes is silently wrong.

Where
  • physicsnemo/nn/functional/derivatives/uniform_grid_gradient/_torch_impl.py — every stencil (central difference, 4th-order, etc.) is built from torch.roll(field, shifts=..., dims=axis) unconditionally. There is no periods/boundary argument anywhere in this file.
  • physicsnemo/sym/eq/gradients.py:
    • GradientsFiniteDifference.__init__ (line 113) takes invar, dx, dim, order, return_mixed_derivs — nothing about boundary handling — and calls uniform_grid_gradient(...) (line 132) with no way to request anything else.
    • GradientsSpectral (starts line 174) has the same shape of gap for the FFT-based path.
  • physicsnemo/sym/eq/phy_informer.py — PhysicsInformer is the public entry point that dispatches to these two classes via grad_method. Nothing in its docstring states the periodic-domain requirement.
The project's own tests already show this is known internally

test/sym/test_gradients.py:

  • test_gradients_finite_difference (line 190) pads by 2 cells and slices [pad:-pad, pad:-pad, pad:-pad] (lines 199–206) before comparing against the analytical gradient.
  • test_gradients_spectral (line 215) does the same (lines 227–235).

Excluding exactly the boundary cells before checking correctness only makes sense if those cells are known to be wrong. That knowledge never made it into a docstring, a runtime warning, or an exception — a user calling PhysicsInformer on a plain non-periodic problem (a bar with fixed-temperature ends, a cavity with wall BCs, etc.) gets a residual that's wrong exactly where boundary conditions usually matter most, with nothing telling them so.

Related existing work

#1852 / draft PR #1853 already track adding a non-periodic boundary mode to the lower-level rectilinear_grid_gradient/uniform_grid_gradient functions, but neither mentions the consumer-facing gap in gradients.py/PhysicsInformer described here — the layer most PINN users actually touch. Happy to have this issue closed as a duplicate/tracked-by #1852 if that's preferred, but flagging the PhysicsInformer angle specifically since it's not covered there.

Suggested first step (small, low-risk)

Independent of when/whether #1852's lower-level fix lands: document the current periodic-only assumption explicitly in GradientsFiniteDifference, GradientsSpectral, and PhysicsInformer's docstrings, and/or raise a clear warning when grad_method is one of these two and the caller hasn't confirmed a periodic domain. That alone would stop the current silent failure mode without needing the full boundary-mode implementation.

Happy to open a PR for the documentation/warning step if that's a welcome direction — let me know if #1853 is still active first so I don't duplicate that effort.

Lingua principale
Python
Stelle
3.3k
Fork
787
Merge medio
3g 4h
PR unite (30g)
28

Preparare l'ambiente

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 NVIDIA/physicsnemo

Tutte le issue di NVIDIA/physicsnemo

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.