Port and operate a scientific pipeline on GPU clusters

Why use this

1. A GPU adaptation can appear attractive when one stage runs faster while transfers, setup or changed numerical behavior remain outside the comparison. Large runs can magnify both scientific mistakes and resource waste if the benchmark boundary is not agreed first.

2. A benchmark-and-resource review packet could define equivalent inputs, measured stages and independent correctness questions before any compute is allocated. Researchers could decide whether the proposed experiment is interpretable and bounded without mistaking a plan for a successful port.

Why an agent / simpler alternative

Useful judgment

Identify mismatched benchmark boundaries and parameter assumptions across a reference pipeline and proposed GPU adaptation.

Simpler alternative

Use an existing supported implementation when its scientific behavior and performance already meet the research need.

Unsuitable when

Domain validation, resource caps or an accountable operator are absent.

Proposed inputs

1. Name

   Reference-method description

   Owner

   Research lead

   Minimum scope

   Algorithm stages, parameter definitions and expected invariants

   Quality check

   Identify which outputs require independent domain validation.

2. Name

   Compute experiment brief

   Owner

   Compute owner

   Minimum scope

   Proposed hardware class, stage boundaries and resource limits

   Quality check

   Include setup, transfers and shutdown responsibilities.

Access and setup — proposed or unknown

Proposed minimum

1. Offline pipeline descriptions and a proposed benchmark manifest without cluster access.

Compatibility unknowns

1. Unknown: current runtime, GPU libraries, cluster availability and numerical equivalence.

External actions requiring approval

1. Workload execution, compute spending, resource allocation, credentials and scientific publication.

Expected deliverable and review checks

Proposed artifact

Benchmark design with comparable stages, correctness review, resource accounting and stop conditions.

Critical checks

1. Reference and proposed measurements cover equivalent work and input conditions.

2. Performance acceptance is separate from scientific correctness.

Missing output evidence

No new workflow run or output inspection was performed for this overlay; use the canonical source-outcome references.

Failure signals and proposed responses

1. Signal

   GPU timing excludes data movement included in the baseline.

   Why it matters

   The comparison can exaggerate an improvement.

   Proposed response

   Align measurement boundaries and report unavoidable differences explicitly.

2. Signal

   Parameter tuning changes the method's accepted behavior.

   Why it matters

   A faster run may answer a different scientific question.

   Proposed response

   Stop the comparison and seek domain approval for the altered assumptions.

Effort and cost — unknown

Setup work

1. Define comparable experiments and resource shutdown ownership.

Ongoing review

1. Inspect independent correctness evidence and complete resource accounting.

Unknowns

1. Unknown: accelerator charges, scaling behavior and scientific validation effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

An invented benchmark manifest excludes transfer time in one variant and changes a correctness-relevant parameter.

Acceptance checks

1. Reject the unequal comparison design.

2. List the parameter decision requiring domain review.

Stop conditions

1. Code execution, real datasets, hardware allocation or scientific-result claims are needed.

Limits

1. This proposed document check validates neither numerical results nor GPU performance and supplies no cluster-run evidence.