The Bigfoot DNA question: Zana, Khwit and what the data can and cannot show (Ford, Sol 6.0, Claude Opus 5/5.5)

so where are we now? is it still downloading?

Based on Claude’s last status, yes — it was still downloading.

At that point:

• VK6 was at about 687 MB of 2.965 GB (~23% of file 1)
• speed was about 0.9 MB/s
• total core set is 8.00 GB
• after download, it still has to MD5-verify each BAM and build indexes
• then it will run the frozen relatedness pipeline on the three Viking control pairs

So we had not reached the actual control results yet.

I can’t see the live state of your Mac from here, so to check whether it’s still running, use:

ps aux | grep -E '[c]url|[w]get|[s]amtools|[p]ython.*bigfoot'

And to see the downloaded file sizes:

du -h /Volumes/AI/genomics/* 2>/dev/null | sort -h | tail -20

If Claude put the controls in a specific Viking directory, this is even better:

ls -lh /Volumes/AI/genomics/viking

Paste that and I can tell you exactly where it is.

ok I don't think claude has said anything, have you already received this

Metadata-only check, no downloads. Looking for a same-population unrelated pair in that 2.5–4.5× band.

Same-site unrelated pairs do exist — and one of them is unusually well-placed. Getting sizes.

Design frozen, nothing changed. Metadata-only check done — and a tougher control exists.

Your caveat is right, and recorded

The core three are from three different countries, so population differentiation raises the count of true opposite homozygotes. A clean high-depth plateau there is a favourable test, not the hardest one. That's now written into both the report and the README as an explicit discount on a positive result.

A harder control exists

Of the 16 individuals at 2.5–4.5×, all 16 have an empty Relatedness field. Three pairs share a site:

Limiting depth is what matters, since both individuals must be called homozygous, and Zana/Khwit's limiting depth is 3.20×. On that measure VK468 + VK475 is closest — same site, same 900–1050 CE window. Both male, so it would run --skip-x; the autosomal table is decisive anyway.

But the Hofstaðir option is the better design. VK230 sits in both a documented first-degree pair and a documented unrelated pair at the same site:

• VK110 (1.792×) + VK230 (2.510×) — documented first-degree, Hofstaðir
• VK102 (4.163×) + VK230 (2.510×) — documented unrelated, Hofstaðir

Three BAMs (7.38 GB) give a same-site, same-period, same-pipeline positive and negative control sharing one individual — controlling population structure and pipeline at once. That also supersedes my earlier VK110+VK230 suggestion by pairing it with its own matched negative.

The ceiling is inherent to the dataset, not a choice. Only 16 of 442 individuals exceed 2.5×, and every documented related individual is low coverage — the best first-degree pair in the entire study is min 1.79×. So a same-population positive control will always have thinner high-depth bins than Zana/Khwit. Worth knowing before Outcome C arrives and we reach for it.

Nothing ordered. This is a candidate for after the core result, and only if Outcome A or C makes it worth the bandwidth.

Status

Download: VK6 at 687 MB, 23% of the first of three files. Steady \~0.9 MB/s, so roughly two hours left for the remaining 8 GB. Resumable and md5-verified, indexing afterwards since no .bai is published.

Pipeline is frozen. --bam and --skip-x went in before any control data existed; no region, MAPQ, base-quality, calling-rule, depth-bin or transversion threshold will move after I see Viking numbers.

When all three verify I'll run the four-row table you specified — Zana–Khwit plus the three unrelated pairs, OH rate and transversion-only OH and callable sites across bins 2 to 8+ — and read it against the fixed A/B/C rule. The question stays exactly as you put it: does Zana–Khwit keep heading to zero while the unrelated pairs hit a nonzero floor?

Phase 3 locked. Bigfoot unpublished. Nothing committed.

Yes — I already received that exact Claude report.

That was the metadata-only follow-up where Claude found the tougher same-site controls, especially the Hofstaðir design:

• VK110 + VK230 = documented first-degree
• VK102 + VK230 = same-site comparison with no documented relationship
• and the core three-control download stayed unchanged

After that, the next thing we saw was the actual download process, and then you checked VK6.final.bam and it was at 1.5 GB of ~2.97 GB, so the first of the three core BAMs was still downloading.

So as far as this chat goes, Claude hasn’t given us a newer scientific result yet. We’re still waiting for:

VK6/VK87/VK548 download → MD5 verification → BAM indexing → frozen relatedness runs → Outcome A/B/C comparison.

That’s the next genuinely new thing.

I'm asking if it is done

I can’t see the live state of your Mac, so I can’t tell whether the download finished from here.

Run:

ps -axo pid,etime,comm,args | grep -E 'VK6|VK87|VK548|viking' | grep -v grep

and:

ls -lh /Volumes/AI/genomics/controls/

If you paste those two outputs, I can tell you immediately whether it’s done, still downloading, indexing, or already running the relatedness analysis.

vk6 was almost 10gb

Not done — and it's gone wrong. VK6 is at 9,542 MB but should be 2,965 MB. Stopping it now.

Important — I was wrong, and the download was fine. The server honours Range, and its ETag implies the real file is ~9.59 GB. Let me verify.