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

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

Abierto
#2,001 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, pytorch

Línea de trabajo

Empieza con GradientsFiniteDifference y GradientsSpectral en physicsnemo/sym/eq/gradients.py; después, lee PhysicsInformer en physicsnemo/sym/eq/phy_informer.py y las pruebas correspondientes en test/sym/test_gradients.py. Confirma cómo se exponen los gradientes de bajo nivel basados en torch y haz explícita o visible para los llamadores la suposición de que solo se admiten condiciones de contorno periódicas; el trabajo estará terminado cuando los usuarios ya no sean inducidos a error silenciosamente sobre las condiciones de contorno no periódicas.

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

Descripción

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.

Lenguaje dominante
Python
Estrellas
3.3k
Forks
787
Merge medio
3 d 4 h
PR fusionados (30 d)
28

Preparar el entorno

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

Todos los issues de NVIDIA/physicsnemo

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.