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

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.

Start with GradientsFiniteDifference and GradientsSpectral in physicsnemo/sym/eq/gradients.py, then read PhysicsInformer in physicsnemo/sym/eq/phy_informer.py and the corresponding tests in test/sym/test_gradients.py. Confirm how the lower-level torch-based gradients are exposed, and make the periodic-only assumption explicit or surfaced to callers; done means users are no longer silently misled about non-periodic boundaries.