Skip to content

Keep RunningNorm estimate stable when a slice is all zeros - #2142

Open
rootkiller6788 wants to merge 4 commits into
NVIDIA:mainfrom
rootkiller6788:fix-running-norm-zero-slice-inf
Open

rootkiller6788 wants to merge 4 commits into
NVIDIA:mainfrom
rootkiller6788:fix-running-norm-zero-slice-inf

Conversation

@rootkiller6788

Copy link
Copy Markdown

RunningNorm keeps a running mean of |x| in log space. If a channel is all zeros for a whole batch, the slice comes out of the masked reduction as NaN, and the old code replaced that with 0.0 before taking the log. The estimate then became -inf and stayed there, so every later batch for that channel came out as inf.

The docstring already promises that an all-zero slice leaves the running estimate unchanged, so this makes it true: those slices now fall back to the current estimate (or the neutral value 1.0 before the module has seen any data), and the EWMA update is a no-op for them. Slices with any non-zero entry behave exactly as before.

Added regression tests covering the all-zero first batch, an all-zero batch after the estimate was seeded, and the existing zero-ignoring/calibration behavior. Verified on the CPU path: before the change a seeded estimate went to -inf after one all-zero batch; after the change it stays put and outputs stay finite.

An all-zero reduction slice comes out of the masked nanmean as NaN. It was
then replaced by 0.0 and fed through log(), producing -inf which poisoned
ln_running_mean permanently (and made subsequent outputs inf). Fall back to
the current running estimate for those slices so the EWMA update is a no-op,
which is what the docstring already promises. Slices with any non-zero entry
are unaffected.
Cover the all-zero slice path (first batch and after seeding) plus the
zero-ignoring and calibration behavior. The zero-slice tests fail against
the old log(0) = -inf handling.
@copy-pr-bot

copy-pr-bot Bot commented Oct 18, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions

Copy link
Copy Markdown
Contributor

CODEOWNERS review map

Current for commit b6a4fc198dff. An approval covers every file listed for that owner; one owner is sufficient for shared files.

⏳ @loliverhennigh — 1 file(s)
  • physicsnemo/nn/module/running_norm.py

No CODEOWNER

  • test/nn/module/test_running_norm.py

Comment /codeowners-info to refresh.

@peterdsharpe peterdsharpe self-assigned this Oct 20, 2026
@rootkiller6788
rootkiller6788 marked this pull request as ready for review November 8, 2026 07:18
@greptile-apps

greptile-apps Bot commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in Greptile

[Low impact] The change affects one edge case in RunningNorm’s training updates.

The half-precision overflow should be fixed before merging.

Findings

  1. P1 Zero batches erase later outputs ▶

Summary

Changes RunningNorm so all-zero slices reuse the current estimate, or 1.0 before initialization.

  • All-zero input slices keep RunningNorm’s estimate steady.

Reviews (1) · Last reviewed commit: "Merge branch 'main' into fix-running-nor..." · Reviewed by Greptile

Comment thread physicsnemo/nn/module/running_norm.py Resolved
The all-zero-slice fallback rebuilt the linear running mean with
exp(ln_running_mean) and then took log() of it again. In half precision
that exp overflows to inf once the finite estimate approaches the dtype
maximum (e.g. ln(65504) ~= 11.09), so an all-zero batch still poisoned
the EWMA and every later finite input normalized to zero. Select the
fallback directly in log space instead and add an fp16 regression test.
@rootkiller6788

Copy link
Copy Markdown
Author

Fixed — the all-zero fallback now stays in log space instead of round-tripping through exp, so it can't overflow to inf in half precision, and I added an fp16 regression test covering the 65504 seed case.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants