Release BarcodeMapper 1.1.3 · alberdilab/barcodemapper

[1.1.3] - 2026-10-16

This release also ships 1.1.1 and 1.1.2, which were never tagged or published.

Read mapping now requests resources sized from a measured run instead of the previous guess: 3 times the input size in memory (peak use was about 2.3 times) and 12 minutes per GB of input (about 3 hours with the default database), doubled on each retry. The old 5 minutes per GB (about 74 minutes) made every 100,000-pair run against the default database time out on its first attempt, and the 5 times memory request was about twice what mapping used once samtools collate was removed.

Read mapping no longer pipes Bowtie2 through samtools collate. With a large reference (for example 10.5 million sequences, a 1.2 GB @SQ header) collate copied the full header into each of its 64 temporary shards, so mapping needed about 100 GB of memory and 15 GB of temporary files even for 10,000 read pairs. The alignments now stream straight to BAM with samtools view -b, and the filtered extraction table is sorted by read ID in the extract rule so each fragment's alignments stay adjacent for taxonomy assignment. Results are unchanged.

Manual --build with -b and -u now builds in a hidden staging directory beside the target and promotes the FASTA, Bowtie2 index, headers, and manifest only when all are complete, so a failed build no longer leaves a partial database.
A failed manual build keeps its stage and resumes on rerun with the same inputs and work directory; the stage is discarded if the BOLD/UNITE checksums, retain options, version, or work directory change. A stale Snakemake lock can be cleared with barcodemapper --unlock -t <work directory>.
Builds into a target that already holds database artifacts stop with a clear message to choose a new -d path; a lone FASTA asks for review before removal or reuse of that path.

Install instructions for the release wheel without a source checkout.
A Bioconda recipe with the workflow executables as runtime dependencies.
Reproducible Mjolnir benchmark plans for mock communities, reference novelty, method comparisons, and scaling.

Slurm workflows no longer cap rule threads at the controller's CPU count; the Slurm profile now sets cores: 8, so index_db and read mapping run with their intended threads.
index_db memory and runtime are sized from the uncompressed database rather than the gzipped file, so large reference builds no longer exhaust their retries with out-of-memory and timeout failures.