{"id":"a4da0943-017a-4da5-be3f-653be5235cb3","arxiv_id":"1908.01263","paper_version":1,"verdict":"UNVERDICTED","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"This paper documents how to install and use the r-index software for building compressed genome indexes and querying them with reads.","lead":"This paper is a user guide for the r-index, a compressed index for matching DNA reads against collections of genomes. It explains how to install and run the ri-buildfasta and ri-align programs, with example commands and outputs.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The only quantitative scalability claim is a single self-reported benchmark with no version, dataset, or correctness check; the guide remains useful, but that claim is unverified.","rationale":"I read the paper as a user guide rather than a research claim. Its central purpose is to show how to install and use previously published r-index software, and the instructions are concrete enough to follow. The code is released under GPLv3, which is real supporting evidence for the guide's usability. The strongest empirical assertion is the chromosome 19 benchmark in Section 3. The most load-bearing concern is that this benchmark is not reproducible from the manuscript: no software version or commit is pinned, no dataset accessions are given, the exact command line beyond the illustrative example is omitted, and no correctness check of the built index is reported. That is a genuine documentation gap, but it does not make the installation or usage instructions wrong, and it does not turn the paper into a false scientific claim. The reader's weakest assumption about dependence on repetitiveness is related but secondary; the paper itself discloses that sais may be faster for small or insufficiently repetitive collections, so that dependence is admitted. The verifiability gap is not disclosed in the same way. Since the reader already chose UNVERDICTED rather than endorsing the scalability figures, this concern supports that verdict rather than changing it.","tokens_in":4350,"tokens_out":4689,"duration_ms":49511,"concrete_test":"Pin the repository to the commit used in the paper (or, failing that, the latest release), build ri-buildfasta and ri-align exactly as in Section 2, construct the 2000-copy chromosome 19 collection with the same provenance, run the Section 3 construction command with one thread, and record wall time, peak RSS, and total .ri size; then run ri-align count and ri-align locate on simulated reads and compare with known truth. If the measured time, memory, or index size differ materially from 'under 5 hours, 41 GB, 665 MB', the paper's practical claim is not supported by the released artifact.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's only quantitative evidence for practical scalability is the statement in Section 3 that a 665 MB r-index was built for 2000 copies of human chromosome 19 (110 GB uncompressed) in under 5 hours using 41 GB of RAM and one thread. That statement is load-bearing for the guide's implicit message that the r-index is usable on realistic pan-genomic collections. The manuscript does not specify the exact software version or commit, the full construction command and parameters, the source or accessions of the 2000 chromosomes, or any check that the resulting index is correct (for example, comparing ri-align count/locate output on reads with known truth). Because this is a single self-reported run, an independent reader cannot tell whether the reported time, memory, and index size reflect the released code, a particular configuration, or a specific dataset. The paper's own caveat that bigbwt 'efficiently handles most large repetitive text collections' is not quantified, so the boundary of the claimed practicality is undefined. This is not an internal inconsistency, but it leaves the strongest claim unverified.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper is a brief practical guide to ri-buildfasta and ri-align, two programs implementing the r-index for compressed indexing of genomic databases. It gives step-by-step installation instructions, example commands for building an r-index from a FASTA file and for counting or locating occurrences of reads from a FASTQ file, and explains how to interpret the tabular count output and the SAM-format locate output. It also reports small illustrative timings on a dengue virus dataset and a larger benchmark on a collection of 2000 human chromosome 19 copies. The underlying data structures and algorithms are taken from the authors' earlier papers, so the paper's contribution is as a software tutorial rather than a new algorithmic result.","tokens_in":4533,"tokens_out":3426,"duration_ms":36378,"significance":"If the software works as described, this guide is useful to researchers who want to index large repetitive genome collections in modest memory. The paper's strengths are its brevity, the inclusion of exact shell commands, the sample input files bundled with the repository, and the sample outputs that let users verify their installation. The source code is released under GPLv3, which supports reproducibility. However, the paper's only quantitative evidence for scalability is a single self-reported construction of an index for 2000 human chromosome 19 copies, and that report lacks the version, dataset, and correctness details needed for independent verification. The guide's practical value therefore rests on an unverified benchmark claim.","major_comments":[{"comment":"The central scalability claim is the sentence in Section 3: \"With bigbwt we have built a 665 MB r-index for a collection of 2000 copies of human chromosome 19 from different individuals, which take 110 GB uncompressed, in under 5 hours on a server using 41 GB of RAM and one thread.\" This claim is load-bearing for the guide's message that the r-index is practical for large pan-genomic collections, but the manuscript does not report the exact software version or commit, the full construction command and parameter choices, the source or accession identifiers of the 2000 chromosome copies, or any correctness check of the resulting index. Please add these details or explicitly label the run as anecdotal and remove it as evidence of practical scalability.","section":"§3 (Construction)"},{"comment":"The dengue benchmark in Section 3, reporting that building the index takes \"about 3 seconds and 47 MB of memory\" with bigbwt and \"about 10 seconds and 104 MB of memory\" with sais, gives no measurement methodology: it does not say whether the values are single runs or averages, how memory was measured, or what portion of the collection was indexed. Please state the measurement procedure or qualify these numbers as rough single-machine illustrations.","section":"§3 (Construction)"},{"comment":"The statement that bigbwt \"efficiently handles most large repetitive text collections\" is not quantified, so the boundary of the claimed applicability is undefined. Please provide a practical characterization of the regime in which bigbwt is expected to be faster or more space-efficient than sais, for example in terms of the BWT run count r relative to the text length n, or soften the claim to avoid overgeneralization.","section":"§3 (Construction)"}],"minor_comments":[{"comment":"The phrase \"which take 110 GB uncompressed\" should be \"which occupy 110 GB uncompressed\" or similar, since files do not \"take\" memory in this context.","section":"§3 (Construction)"},{"comment":"The text says \"to create simlulated.0.3edits\" but the sample output shows \"simulated.0.3edits\"; the extra \"l\" appears to be a typo.","section":"§5 (Interpreting Counts)"},{"comment":"In the description of the SAM fields, \"the position of the occurrence of the read is in that sequence\" should be rephrased to \"the position of the occurrence in that sequence\" for clarity.","section":"§6 (Interpreting Locations)"},{"comment":"The sentence \"The output is piped to the standard output by default\" should be \"written to standard output by default,\" since no pipe is involved.","section":"§4 (Alignment)"}],"recommendation":"major_revision","confidential_remarks":"This is a software tutorial rather than a research paper presenting new algorithms, so it should be evaluated on the clarity and reproducibility of its instructions. The main barrier is the unverified chromosome 19 benchmark; adding concrete version, dataset, command, and correctness information is feasible within the scope of a revision. I have not run the software, so my assessment is based on the manuscript text and the supplied sample outputs."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I read this as an application note, not a research result, and on that basis it works. What is new is narrow: concrete install/build/query commands for ri-buildfasta and ri-align, plus sample outputs. The authors say that up front in Section 1, so there's no overclaim. The dengue walkthrough is genuinely useful — input file, exact commands, expected run times, and annotated count/SAM outputs. That is the kind of documentation that makes a tool usable. The algorithmic content is all from earlier papers (Boucher et al.; Kuhnle et al.), and the self-citations are appropriate for a tutorial; no circularity issue.\n\nThe soft spot is the quantitative scalability claim in Section 3: one self-reported run (665 MB r-index for 2000 chr19 copies, under 5 hours, 41 GB RAM, one thread) with no software version or commit, no full command, no dataset accessions, and no check that the index gives correct results. That makes the headline performance figure impossible to reproduce or verify. The stress-test note has this right. It is a real weakness, but it is not fatal to the guide's purpose. The commands work on the shipped dengue data, and the core usability claim — that users can build and query an r-index — is supported by the example outputs. I would treat the benchmark as an anecdote until someone repeats it on a pinned version with a correctness check.\n\nThe other limitation is acknowledged in the text: bigbwt is for 'most large repetitive text collections,' and for small or non-repetitive inputs sais may be faster. That boundary is not quantified, so users have to test on their own data. Minor for a guide.\n\nWho is this for? Practitioners in pangenomics who want to try the r-index without digging through GitHub; also reviewers of the related RECOMB paper who want to see the tool in action. It is not a methods paper and should not be evaluated as one. I would send it to peer review if the venue has an application-note track; as a research article it would be a desk reject, and the authors seem to know that. I would ask a referee to verify the benchmark or to add a note that it is a single observation. Otherwise the manuscript is honest and clear.","headline":"A clear, honest user guide for the r-index software; the only real weakness is a single unrepeatable benchmark, which is easy to fix or qualify.","tokens_in":5050,"tokens_out":2038,"would_cite":false,"duration_ms":22750,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The r-index can be built and queried for large repetitive genome collections, making compressed exact matching to many genomes practical.","keywords":["r-index","Burrows-Wheeler Transform","compressed indexing","exact pattern matching","read alignment","genomic databases","repetitive sequence collections","FM-index"],"falsifier":"Run ri-buildfasta on a 110 GB collection of 2000 genomes chosen to be non-repetitive, such as diverse bacterial species, using the same server and one thread. If the resulting .ri files approach the size of the uncompressed input, or if construction memory scales with total text length rather than with run count, then the demonstrated compression and speed reflect the repetitiveness of the test data and not a general property of the r-index.","tokens_in":4185,"feed_emoji":"🧬","tokens_out":8349,"duration_ms":83836,"temperature":0.7,"pith_summary":"This paper is a hands-on guide to two programs, ri-buildfasta and ri-align, that build an r-index for a collection of genomes and use it to find exact matches of reads in that collection. The r-index is a compressed FM-index whose size tracks the number of runs in the Burrows-Wheeler Transform rather than the full text size, so highly repetitive collections can be indexed in a small fraction of their original space. The walkthrough uses a 22 MB dengue collection of 2,042 genomes and reports a larger test in which 2,000 copies of human chromosome 19 from different individuals—110 GB of uncompressed sequence—become a 665 MB index, built in under 5 hours on one thread with 41 GB of RAM. After construction, counting occurrences of 1,000 simulated 100-bp reads takes about 0.06 seconds and locating one occurrence of each takes about 0.1 seconds on a laptop.","feed_headline":"110 GB of genomes becomes a 665 MB search index","feed_subtitle":"The r-index software turns 110 GB of repetitive chromosome sequence into a small index for read matching.","key_machinery":"The central object is the r-index, a run-compressed FM-index whose space is O(r) machine words, where r is the number of runs in the Burrows-Wheeler Transform of the database. Rather than storing the full transform, it stores one sampled entry per run, and that is enough to support backward search for counting and to locate pattern occurrences. Construction in the walkthrough uses bigbwt, an algorithm designed for large repetitive collections, with the sais suffix-array algorithm available as a fallback for small or insufficiently repetitive inputs; a companion file stores the mapping from text offsets to sequence names, which is what lets locate output named SAM records instead of bare positions.","core_discovery":"The r-index can be used in practice: with the bundled programs, a complete compressed index of a large repetitive genome collection can be built and queried for exact matches. For 2000 copies of human chromosome 19 from different individuals, 110 GB of uncompressed sequence becomes a 665 MB index, built in under 5 hours on a server using 41 GB of RAM and a single thread. Once built, ri-align count reports for each read the longest suffix that occurs in the collection and how many times it occurs, and ri-align locate reports the positions of exact matches in SAM format, with reference sequence names resolved from the offset-to-name mapping. The implementation is released as open source, so the walkthrough serves as both documentation and a reproducibility record.","pith_inferences":["The paper leaves implicit that this changes storage economics: after one construction, queries do not touch the raw sequences, so repeated searches amortize the build cost, and the index files become small enough to distribute alongside the reads.","A natural extension the authors do not develop is using the longest-suffix counts as a simple mapping-quality proxy: a read with a long, unique suffix is more confidently placed than one whose longest match appears hundreds of times, and the count command already produces the raw numbers needed.","The reported single-threaded construction suggests a direct scalability test: repeated runs on random subsets of the 2000-chromosome collection would show whether build time and index size grow with collection size at the rate expected for a repetitive corpus, separating the algorithm's scaling from the machine's speed."],"forward_implications":["If the reported results hold, a 110 GB collection of 2000 human chromosomes can be queried through a 665 MB index, so pangenome-scale exact matching becomes possible on ordinary servers with far less disk and memory than the raw sequences require.","For reads with errors or novel variation, the count command's longest-suffix length and occurrence count can be used directly as seeds: users can truncate reads to the longest suffix that occurs, then locate those suffixes.","Because the original FASTA file is not needed after the index is built, storing and sharing a database reduces to storing the .ri files plus the small name-mapping file.","Since locate reports all occurrences unless --max-hits is set, users can control run time on highly repetitive reads by capping the number of reported hits or restricting to reads with at most k occurrences using --max-range."],"supporting_citations":[{"why":"Supplies bigbwt, the construction algorithm ri-buildfasta uses by default for large repetitive collections.","marker":"[1]"},{"why":"Gives the FM-index, the data structure the r-index compresses by runs.","marker":"[3]"},{"why":"Introduces the r-index and proves pattern matching in O(r) space, the theoretical basis for the implementation.","marker":"[4]"},{"why":"Extends the earlier implementation into the complete index this paper documents.","marker":"[6]"},{"why":"Provides sais, the alternative suffix-array construction available when collections are small or non-repetitive.","marker":"[12]"},{"why":"The preliminary r-index implementation that was extended for this software.","marker":"[14]"}],"fun_headline_variants":["r-index turns 110 GB genomes into a 665 MB index","Compress 110 GB of repetitive genomes to a 665 MB index","r-index: 110 GB genomes to 665 MB exact-match index","Build a 665 MB index from 110 GB genomes with r-index"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The practical space and time figures all depend on the Burrows-Wheeler Transform having few runs: the database must be repetitive enough that the number of runs r stays far below the text length, and the paper itself notes that for small or insufficiently repetitive collections the alternative construction may be faster.","fun_headline_variants_meta":{"raw":{"variants":["r-index turns 110 GB genomes into a 665 MB index","Compress 110 GB of repetitive genomes to a 665 MB index","r-index: 110 GB genomes to 665 MB exact-match index","Build a 665 MB index from 110 GB genomes with r-index"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000677,"raw_usage":{"total_tokens":3000,"prompt_tokens":789,"completion_tokens":2211,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":405,"completion_tokens_details":{"reasoning_tokens":2133}},"tokens_in":405,"tokens_out":2211,"duration_ms":15456,"temperature":1.0,"reasoning_tokens":2133,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T15:17:27.628734+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run ri-buildfasta on a 110 GB collection of 2000 genomes chosen to be non-repetitive, such as diverse bacterial species, using the same server and one thread. If the resulting .ri files approach the size of the uncompressed input, or if construction memory scales with total text length rather than with run count, then the demonstrated compression and speed reflect the repetitiveness of the test data and not a general property of the r-index.","supporting_citations":[{"cited_title":"Prefix-free parsing for building big BWTs","cited_arxiv_id":null,"evidence_quote":"Supplies bigbwt, the construction algorithm ri-buildfasta uses by default for large repetitive collections."},{"cited_title":"Indexing compres sed text","cited_arxiv_id":null,"evidence_quote":"Gives the FM-index, the data structure the r-index compresses by runs."},{"cited_title":"Optim al-time text indexing in BWT-runs bounded space","cited_arxiv_id":null,"evidence_quote":"Introduces the r-index and proves pattern matching in O(r) space, the theoretical basis for the implementation."},{"cited_title":"Efficient construction of a complete index for pan-g enomics read alignment","cited_arxiv_id":null,"evidence_quote":"Extends the earlier implementation into the complete index this paper documents."},{"cited_title":"Two efficient algori thms for linear time suffix array construction","cited_arxiv_id":null,"evidence_quote":"Provides sais, the alternative suffix-array construction available when collections are small or non-repetitive."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The preliminary r-index implementation that was extended for this software."}],"review_version":1}