grid spacing in Kirchhoff operator ignored for dynamic=True
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 56/100
Direzione di ricerca
Start in waveeqprocessing.Kirchhoff and trace the byot path with dynamic=True, focusing on the traveltime gradients used for source and receiver angles and the offset aperture calculation. Compare their grid spacing and units with _traveltime_table and the aperture docstring. Done means both calculations respect physical grid spacing when dx != dz; the issue names no test, so identify the relevant tests before changing code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
In waveeqprocessing.Kirchhoff the grid spacing is ignored in byot+dynamic gradients and in the offset aperture
mode='byot'withdynamic=True**): the traveltime gradients used for the source/receiver angles are computed as np.gradient(self.trav_srcs.reshape(*dims, ns), axis=np.arange(self.ndims)), i.e. without the grid spacing, whereas _traveltime_table(analytic/eikonal) usesnp.gradient(..., *dsamp, axis=...). With dx != dz the angles are wrong (arctan2(dT/dx·dx, dT/dz·dz)) One fix could be to pass the parameters in _traveltime_table`.
Offset aperture: aperture = abs(six - rix) / (iz + 1) with six, rix in x-grid
indices and iz in z-grid indices, while the docstring defines the aperture as offset over
depth. With dx != dz the effective physical ratio is scaled by dz/dx. One fix could be to express the
positions in metres (or in units of dz), e.g. six = (srcs[0] - x[0]) / dz.
- Lingua principale
- Python
- Stelle
- 539
- Fork
- 126
- Merge medio
- 2g 18h
- PR unite (30g)
- 21
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun 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 PyLops/pylops
-
Lipschitz methodForse già presa @Megumi1773 l’ha presa 28 giorni fa. Apertaenhancement good first issue
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
I maintainer di solito rispondono entro 2 giorni
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
PyLops/pylops#786 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
CI
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 2 giorni
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 2 giorni
-
Introduce spell checkingAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
PyLops/pylops#731 · 4 commenti · 1 reazione ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di PyLops/pylops
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
cline/mcp-marketplace#3576 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
griptape-ai/griptape-nodes-library-elevenlabs#30 ·
I maintainer di solito rispondono entro 1 giorno
-
docs: Release playbookApertadocumentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
awslabs/social-messaging-agent-runtime-toolkit#140 ·
I maintainer di solito rispondono entro 1 giorno
-
subtask
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
fga-eps-mds/2026.2-MeasureSoftGram-DOC#187 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
NSPG13/agent-bounties#1747 ·
I maintainer di solito rispondono entro 1 giorno