<h1id="architecture-notes-for-advanced-use">Architecture notes for advanced use</h1>
<p>This page describes execution-level behavior relevant to sizing and running <code>obikmer</code> on large datasets or multi-socket machines. It complements the <ahref="../formats/index_layout/">index format</a> and <ahref="../theory/indexing_architecture/">theory</a> pages.</p>
<li>Only the <code>A</code>/<code>C</code>/<code>G</code>/<code>T</code> alphabet (case-insensitive) is recognized; a sequence is cut at any other character (including IUPAC ambiguity codes), so runs containing them are not represented in the index.</li>
<li>Sequences are internally processed in chunks of at most 256 nucleotides; a chunk shorter than k is dropped. This is invisible to the user beyond the ACGT-only, minimum-length-k constraints above.</li>
<li>Kmers are always handled in canonical form (see <ahref="../theory/encoding/">DNA encoding</a>), so the tool is strand-agnostic throughout: a kmer and its reverse complement are always the same entry.</li>
<p>An index directory is organized as <code>KmerIndex → partitions → layers</code>, with a canonical kmer belonging to exactly one (partition, layer) pair. This is what makes set operations (merge, filter, distance) parallel and coordination-free across partitions.</p>
<ul>
<li><strong>Partition count</strong> (<code>-p</code>/<code>--partitions</code>, rounded up to a power of 2) is the main dimensioning knob: more partitions means more independent parallel units and a smaller working set per partition, at the cost of more open files during construction.</li>
<li><strong>Layers</strong> accumulate as an index grows through successive merges; per-partition query cost grows with the number of layers (worst case linear, expected constant since most kmer lookups resolve in the first layer they could plausibly be in).</li>
<li>Genome columns (count or presence data) are kept at a consistent width across every layer and partition after a merge, which is what allows whole-index aggregate distances (Jaccard, Bray-Curtis, Euclidean, Hellinger, …) to be computed as a two-pass cascade (local partial sums per partition, then a global combination) with no double counting.</li>
</ul>
<h2id="parallel-execution-and-numa-awareness">Parallel execution and NUMA awareness</h2>
<p>Partition-level work (index construction, <code>merge</code>, <code>filter</code>, <code>reindex</code>, <code>select</code>, <code>phylo</code>'s sibling-annex/Sankoff computations) is dispatched by a partition runner that adapts to the machine's memory topology, detected automatically at startup via hwloc:</p>
<ul>
<li>On a multi-socket / multi-NUMA-node machine, one thread pool is pinned per NUMA node, and each partition is processed entirely by threads pinned to one node — keeping the memory a partition touches local to that node's DRAM. This matters because touching kmer data across NUMA nodes without pinning can degrade throughput by an order of magnitude or more on large multi-socket machines.</li>
<li>On a single-socket machine, Apple Silicon, or if hwloc cannot report NUMA topology, all cores are treated as one node with no pinning and negligible overhead — this is the default behavior on macOS.</li>
<li>Within a node, the number of active worker threads ramps up progressively rather than being fixed up front: it starts conservatively and grows in steps, but only as long as measured CPU efficiency or disk I/O throughput keeps improving. If neither improves after a growth step, the runner stops adding workers — avoiding oversubscription on stages that are memory-bandwidth-bound rather than CPU- or I/O-bound. Ramp speed scales with the number of cores per node, so a single-node machine ramps just as fast as a large multi-node one.</li>
</ul>
<p>No CLI flag controls this directly; it is fully automatic at runtime. NUMA-aware pinning can be compiled out (Cargo feature <code>numa</code>, on by default), in which case a plain global thread pool is used instead.</p>
<p><ahref="../usage/filter/"><code>filter</code></a> evaluates predicates against the genome metadata matrix directly whenever every active filter can be expressed as a column-level test (e.g. "any outgroup column non-zero"), producing a per-slot keep/drop decision without touching kmer sequence data at all. If any active filter cannot be expressed this way, evaluation falls back to a per-kmer, row-level check. Either way, the result is always written as a single, freshly compacted layer (<code>unitigs.bin</code> and the MPHF are rebuilt from the surviving kmers), never as an additional layer on top of the source index.</p>
<scriptid="__config"type="application/json">{"annotate":null,"base":"..","features":[],"search":"../assets/javascripts/workers/search.2c215733.min.js","tags":null,"translations":{"clipboard.copied":"Copied to clipboard","clipboard.copy":"Copy to clipboard","search.result.more.one":"1 more on this page","search.result.more.other":"# more on this page","search.result.none":"No matching documents","search.result.one":"1 matching document","search.result.other":"# matching documents","search.result.placeholder":"Type to start searching","search.result.term.missing":"Missing","select.version":"Select version"},"version":null}</script>
