🐛[BUG]: power_spectrum in metrics.general puts the zero frequency half a cell off along an odd width
I maintainer di solito rispondono entro 2 giorni
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- machine-learning, testing-qa
Direzione di ricerca
Inizia da physicsnemo.metrics.general.power_spectrum.power_spectrum e leggi il test esistente test_power_spectrum. Esegui i test attuali con casi di altezza e larghezza dispari, quindi aggiungi la copertura di regressione per questi casi e verifica che gli spettri e i centri dei bin restituiti siano coerenti. L’autore dell’issue riferisce di avere già pronto un fix e un test di regressione, quindi verifica la presenza di lavori sovrapposti prima di iniziare.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Version
main at ff5d19d08123de47ca446caed1d70a225d540184
On which installation method(s) does this occur?
Source
Describe the issue
physicsnemo.metrics.general.power_spectrum.power_spectrum builds the radial wavenumber grid after fftshift with
k = torch.hypot(xx - h // 2, yy - w / 2).to(torch.float32)
After fftshift the zero frequency of an axis of length n sits at index n // 2 for even and odd n alike. The height uses h // 2, the width uses w / 2. For an even width the two agree. For an odd width w / 2 is half a cell away from the true center, so every wavenumber along the width is off by 0.5 and the whole grid is skewed in one direction.
Three things follow for any field with an odd width.
- The same cosine along the height and along the width gives different spectra. For a 33 by 33 grid and wavenumber 5 the height version puts all power into the bin around k = 5 and the width version splits it between two neighbouring bins, 6.19 and 5.04 instead of 10.08 and 0.
- The spectrum of a field differs from the spectrum of its transpose, up to about 12 percent per bin on a 33 by 33 random field. For a 32 by 33 field even the returned bin centers differ from the 33 by 32 case.
- A single cosine along the width fills two bins instead of one, so a peak reads lower and wider than it is.
The existing test test_power_spectrum only uses a 32 by 32 grid, where w / 2 and w // 2 coincide, so it cannot see this.
The fix is to build the grid in float32 and use w // 2 for the width. A one character change to // alone is not enough because torch.hypot has no integer kernel, hence the float32 arange.
Minimum reproducible example
import math
import torch
from physicsnemo.metrics.general.power_spectrum import power_spectrum
size, m = 33, 5
coords = torch.arange(size, dtype=torch.float32)
wave = torch.cos(2 * math.pi * m * coords / size)
along_h = wave.view(size, 1).repeat(1, size)[None, None]
along_w = wave.view(1, size).repeat(size, 1)[None, None]
_, p_h = power_spectrum(along_h)
_, p_w = power_spectrum(along_w)
print(p_h[0, 0])
print(p_w[0, 0])
x = torch.randn(1, 1, 33, 33)
_, p = power_spectrum(x)
_, p_t = power_spectrum(x.transpose(-2, -1))
print(torch.allclose(p, p_t, rtol=1e-4, atol=1e-6))
Relevant log output
tensor([0., 0., 0., 10.0833, 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
tensor([0., 0., 6.1875, 5.0417, 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
False
Tiny values of order 1e-13 are printed as 0 above. A pytest run of the attached regression test against main is at https://github.com/Nicholas022400701/oss-ci/actions/runs/35357438260 with 4 failed and 2 passed, the two passing cases are the even sized 32 by 32 grids.
Environment details
Ubuntu GitHub Actions runner, Python 3.12.14, torch 2.14.0+cpu, numpy 2.5.2, physicsnemo installed from source with pip install -e .
I have a fix with a regression test ready and will open a pull request that links this issue.
- Lingua principale
- Python
- Stelle
- 3.4k
- Fork
- 824
- Merge medio
- 4g 6h
- PR unite (30g)
- 81
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NVIDIA/physicsnemo
-
Wasserstein CDF distance uses the first width for every binForse già presa @sylvesterkaczmarek l’ha presa 24 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
NVIDIA/physicsnemo#2042 ·
I maintainer di solito rispondono entro 2 giorni
-
🐛[BUG]: Darcy2D Jacobi kernel divides grad(k)·grad(u) by 2dx instead of 4dx², so the data doesn't solve the Darcy equationForse già presa @coreyjadams l’ha presa 22 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
NVIDIA/physicsnemo#2036 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
🐛[BUG]: MHD_PDE equation "B_grad_u" uses v * Bx.diff(y) instead of By * u.diff(y)Forse già presa @aaguadob l’ha presa 29 giorni fa. Aperta? - Needs Triage bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
NVIDIA/physicsnemo#2021 ·
I maintainer di solito rispondono entro 2 giorni
-
🐛[BUG]: Diffusion(time=True) in darcy_physics_informed/utils.py silently drops the time-derivative termForse già presa @aaguadob l’ha presa 29 giorni fa. Aperta? - Needs Triage bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
NVIDIA/physicsnemo#2020 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
NVIDIA/physicsnemo#2177 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di NVIDIA/physicsnemo
Issue simili
-
bug P1
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Toloka/tolokaforge#1947 ·
I maintainer di solito rispondono entro 1 giorno
-
SageMaker provider: streaming fails with NoStreamDataError on DJL Serving (LMI) endpointsForse già presa @balajiaru l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
UKGovernmentBEIS/inspect_ai#6127 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
pydot/pydot#601 · 4 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
letsencrypt/cp-cps#361 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100