Ivan Katkov
Selected work/Case 09

Scientific computing · Python backend · Jan 2020 — Feb 2020

Turning seismic research logic into a reproducible parallel-processing service

I implemented generalized mutual correlation, dip correction and multiprocessing for scientific seismic-trace processing.

N tracesgeneralized inputNot limited to a fixed trace count
ParallelprocessingMultiprocessing acceleration
2 moresearch buildAlgorithm to service
CASE / 09 SYSTEM ONLINE
Innopolis UniversityA production-oriented service for seismic trace analysis

IMAGE PLACEHOLDER · Replace through public/images/cases and the case-study data file.

01 · Executive summary

The shortest honest version.

Situation

Research algorithms for seismic traces needed to become reusable, testable software rather than one-off analysis code.

Intervention

I generalized correlation logic, added dip correction and parallelized processing inside structured Python modules.

Result

The research workflow became a containerized, reproducible backend suitable for arbitrary trace counts.

02 · Context

Why the engineering work mattered.

Seismic interpretation relies on consistent processing across large collections of traces.

The implementation had to preserve scientific intent while improving software structure and execution.

03 · System design

A clear path from signal to production.

01SEGY input

Seismic traces loaded through segyio.

02Normalization

Data prepared for comparable processing.

03Correlation

Generalized mutual-correlation algorithm.

04Dip correction

Adjusted processing for trace geometry.

05Parallel output

Multiprocessing and reproducible results.

Constraints that shaped the solution

  • Scientific correctness.
  • Binary seismic data formats.
  • Compute-intensive processing.
  • Need for reproducible execution.

04 · Decision ledger

The trade-offs behind the implementation.

DecisionReasonTrade-offOutcome
Generalize before parallelizing

Fixed-count logic would multiply complexity when distributed.

More upfront algorithm refactoring.

One processing path supported arbitrary trace collections.

Use process-level parallelism

The workload was computational rather than request-bound.

Data transfer and worker coordination overhead.

Independent trace work could use multiple CPU cores.

05 · Change

Before and after.

BeforeResearch-specific algorithm

AfterStructured backend module

BeforeFixed processing assumptions

AfterArbitrary trace-count support

BeforeSequential compute path

AfterMultiprocessing acceleration

06 · Outcomes

Technical change translated into team value.

Technical
  • Implemented mutual correlation and dip correction.
  • Generalized processing across arbitrary trace counts.
  • Added multiprocessing, tests and Docker-based reproducibility.
Organizational
  • Created a clearer bridge between research intent and production-oriented code.
  • Made the implementation easier to reproduce and extend.
  • Documented technical behavior through module boundaries and tests.

07 · Evidence boundary

Precise claims build more trust than inflated ones.

  1. No unsupported accuracy or speed multiplier is claimed.
  2. The case distinguishes algorithm implementation from scientific discovery.
  3. Performance improvement is described qualitatively because benchmark data is not available.

08 · Reflection

What the project changed in my engineering judgment.

What worked

Generalizing the algorithm before optimizing it reduced both scientific and implementation ambiguity.

What I would improve next

I would add benchmark datasets and numerical-regression tests for every algorithmic change.

What this demonstrates

Scientific Python engineering with reproducibility and performance awareness.

Next case · 10A multi-channel support system led by a five-person backend team