grid spacing in Kirchhoff operator ignored for dynamic=True
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 56/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Python
- Estrellas
- 539
- Forks
- 126
- Merge medio
- 2 d 18 h
- PR fusionados (30 d)
- 21
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PyLops/pylops
-
Lipschitz methodPosiblemente ocupada @Megumi1773 la tomó hace 28 días. Abiertoenhancement good first issue
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 2 días
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
PyLops/pylops#786 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Uv setup for intel environmentAbiertoCI
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 2 días
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 2 días
-
Introduce spell checkingAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 38/100
PyLops/pylops#731 · 4 comentarios · 1 reacción ·
Los mantenedores suelen responder en 2 días
Todos los issues de PyLops/pylops
Issues similares
-
docs: Release playbookAbiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
awslabs/social-messaging-agent-runtime-toolkit#140 ·
Los mantenedores suelen responder en 1 día
-
subtask
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
fga-eps-mds/2026.2-MeasureSoftGram-DOC#187 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
txn2/mcp-data-platform#2493 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
YO-WHATS-UP2/minigit#78 ·
Los mantenedores suelen responder en 3 días
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
liberation-data/drivine-python#432 ·
Los mantenedores suelen responder en 1 día