Skip to content

Key GCP folds run ids on output-changing options - #4

Merged
davek44 merged 2 commits into
mainfrom
gcp-run-id-command-hash
Oct 5, 2026
Merged

davek44 merged 2 commits into
mainfrom
gcp-run-id-command-hash

Conversation

@davek44

@davek44 davek44 commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator

Summary

On GCP, the _folds wrappers pick a deterministic output dir and resume any job whose output is already complete. That dir was keyed only on inputs (VCF/BED, models, params, data), so rerunning with different options silently reused the earlier run's results. In practice, a hound_snp -m bfloat16 -j 6000 rerun merged 12 fp32 shards from an earlier -j 1024 run. With the same -j, it would have silently returned fp32 scores.

The run id now also hashes the options that change the output:

  • hound_snp_folds, hound_ism_snp_folds, hound_ism_bed_folds: hash a representative job command (placeholder model/output/fold paths). Every flag changes output, and job size must match for per-shard resume.
  • hound_eval_folds: option flags move into eval_options/spec_options, used both to build the commands and in the key. Spec's memory/IO knobs (--ncpus, --band, --seq_chunk, --ram, --scratch_dir) stay unkeyed, so changing them still resumes. Spec options are keyed even without --spec, so adding --spec to a finished eval resumes it.
  • hound_eval_genes_folds: same, via evalg_options, plus --valid, which changes the split written to the same evalg/ dir.

Adds stage_cache.hash_text.

Note: existing runs get new output dirs, so an in-progress GCP run won't resume across this change.

Test plan

  • New: each wrapper with stubbed GCP returns the same dir for the same options, a new dir for an output-changing option (-m, -j, --rc, --shifts, --valid), and the same dir for memory/IO knobs and for adding --spec. All fail on the old code.
  • test_snp_folds, test_stage_cache, test_ism_snp, test_ism_bed, test_gcprunner, test_eval, test_hound_eval_genes, test_eval_*_folds_gcp

🤖 Generated with Claude Code

davek44 and others added 2 commits October 4, 2026 19:47
hound_snp_folds, hound_ism_snp_folds and hound_ism_bed_folds derived their
deterministic GCS output dir (and so per-shard resume) from the input and
model hashes only. Rerunning with different options (precision, stats,
targets, --rc, job size, ...) silently reused the earlier run's completed
shards, e.g. a -m bfloat16 rerun merged fp32 shards of another job size.

The run id now also hashes a representative job command (placeholder
model/output/fold paths), so any option change starts a fresh prefix while
identical reruns still resume. Adds stage_cache.hash_text.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hound_eval_folds and hound_eval_genes_folds keyed their deterministic GCS
output dir on models, params, (gtf,) and data only, so rerunning with
different options (--rc, --shifts, --step, ...) resumed the earlier run's
finished acc.txt / gene_metrics.tsv.

Their output-changing flags move into eval_options/spec_options/
evalg_options, used both to build each job command and in the run id.
Per-job paths and splits, and spec's memory/IO knobs (--ncpus, --band,
--seq_chunk, --ram, --scratch_dir), stay out of the key so changing them
still resumes. Spec options are keyed even without --spec, so adding --spec
to a finished eval run resumes it. Gene eval also keys --valid, which
changes the split written to the same evalg/ dir.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@davek44
davek44 merged commit 3cc6dce into main Oct 5, 2026
3 checks passed
@davek44
davek44 deleted the gcp-run-id-command-hash branch October 5, 2026 04:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant