VirPipe: an easy-to-use and customizable pipeline for detecting viral genomes from Nanopore sequencing.
The main results reproduced: recomputed values matched the published ones within tolerance.
Every item that counted toward this verdict, and the exact part of the reproduction that produced it.
- ✓Same input data as the authors
- ✓No relevant deviation in data/preprocessing
- ✓No authors-side cause for any deviation
- ✓Reported values are derivable from the shared data
- ✓Any deviation was negligible
- ✓The central claim held under reproduction
- ✓Overall, the reproduction was clean
- 🟡Reported values were only indirectly comparable
A 0–100 reproducibility-quality score from the per-question grades, shown as a z-score: standard deviations above (+) or below (−) the mean of comparable assessments.
▸Reproduction agent’s raw note
REPRODUCED. VirPipe is a software-tool paper (authors' own Nextflow pipeline); its concrete pipeline-derived use-case claims on SRR22029862 both reproduce 1:1 by running the authors' own modules on the paper's own data. C1 (map): all three HTNV segments L/M/S covered 97.1/100.0/100.0% at 4657-14813x depth = 'almost entirely covered'. C2 (classify, centrifuge): 82.4% of reads classified specifically as Hantaan orthohantavirus (84.5% genus) = clear majority. C3 (assemble, Flye): runs, 48 contigs/122kb, fragmented (amplicon), no paper number to match. NOT attempted: wet-lab data generation (out of scope) and the Docker Python wrapper (no Docker on HPC; ran the shipped .nf module commands directly = faithful). «job» 'FAILED' only on a cosmetic final sort|head display line; all analysis outputs were produced. Verdict provisional; human audits.
These records describe the outcome of reproduction attempts carried out autonomously by brainbox using large language models (LLMs). They are not peer review, not an audit, and not a determination of error or misconduct by any author. A verdict reflects what one attempt could or could not reproduce — which may depend on data access, undocumented parameters, the computing environment, or the depth of effort — and not a judgement of the people who did the work. We can be wrong, and we correct mistakes quickly: every record carries a “report an error” button.
Assessment versions
Every reproduction run is kept as an immutable version — anchored to the data as it stood, with a tamper-evident chain hash. A rerun (e.g. after an author updates a deposit) adds a new version; the previous one stays on record.
-
v1 current initial assessment Score 83assessed: 2026-06-20 ⛓ 983936e3d209
✎ I am an author of this paper
Updated or fixed a deposit, or is there an erratum? Ask us to re-run the metrics. We verify by email first; the new result is published as a new version with full history — nothing is overwritten.
Provenance — full disclosure
When this reproduction was carried out, which methodology version was used, and by whom — so the record can be audited and checked independently.
- Reproduced
- 2026-06-20
- Rubric version
- v1.0
- Assessed by
-
🤖 AI curator · claude (ai-curator room) · v1.0 · run #1 2026-06-20no human curator yet
- Last updated
- 2026-08-05
Provisional, curator- or AI-assessed, and independently checkable. A reproduction outcome states what one attempt could reproduce — not a judgement of the authors.
Deep full-text extraction
Model: sonnetExisting virus detection pipelines poorly support Nanopore sequencing (limited access, discontinued, or hard to install), so an easy-to-use, customizable pipeline combining multiple complementary analysis methods is needed to reliably detect viral genomes from Nanopore (and Illumina) sequencing data.
- ★ VirPipe is a new bioinformatics pipeline for detecting viral genomes from Nanopore or Illumina sequencing input with streamlined installation and customization. resource
- ★ Existing Nanopore-compatible virus detection pipelines have practical weaknesses: GenomeDetective limits analyses and lacks free offline use, NanoSPC is no longer in service, and Vir-MinION requires demanding manual installation of components. finding
- ★ VirPipe integrates three complementary analysis methods—reference mapping, taxonomic classification, and contig analysis—that together provide a comprehensive analysis. method
- ★ VirPipe uses Nextflow wrapped by Python scripts and Docker containers to enable easy installation and a user-friendly interface, with customizable parameters and ability to run steps independently. method
- ★ In a use case with an HTNV-positive rodent lung tissue Nanopore dataset, all three VirPipe analysis modules concordantly detected Hantaan orthohantavirus (HTNV)-related reads. finding
- Reference mapping module uses Minimap2 for alignment and Qualimap for reporting. method
- Taxonomic classification module uses Centrifuge for Nanopore reads or Kraken2 for Illumina reads. method
- Contig analysis module assembles reads de novo with Flye (Nanopore) or SPAdes (Illumina), polishes Nanopore-derived contigs, identifies closest references via BLAST+, and can optionally estimate zoonotic potential using Zoonotic rank. method
| Assay | System | Perturbation | Readout | Platform |
|---|---|---|---|---|
| Nanopore sequencing (multiplex PCR-amplicon based) analyzed via reference mapping, taxonomic classification, and de novo contig assembly | Lung tissue of a rodent (Apodemus agrarius), sample SRR22029862 from Park et al. (2021) | none (naturally HTNV-infected tissue; library amplified via multiplex PCR targeting Hantaan orthohantavirus) | Presence/coverage of HTNV-related reads: genome segment coverage (reference mapping), proportion of reads classified as HTNV (taxonomic classification), similarity of assembled contigs to HTNV reference sequences (BLAST-based contig analysis) | — |
- ▲ All three genome segments of HTNV were almost entirely covered by input reads in the reference mapping module.
- ▲ A majority of the reads were classified into HTNV by the taxonomic classification module.
- ▲ A large number of assembled contigs showed high similarity with HTNV reference sequences in BLAST results from the contig analysis module.
Statistical methods review
Model: sonnetA neutral, descriptive read of the statistical approach — what was done, and (for shared learning, not as criticism) what could also have been done.
This is a bioinformatics software applications note describing VirPipe, a pipeline for viral genome detection from Nanopore or Illumina sequencing data. The paper does not report a hypothesis-driven experiment with statistical comparisons between groups; instead it demonstrates the pipeline's utility with a single use-case dataset (one Nanopore-sequenced rodent lung tissue sample confirmed HTNV-positive by prior experiments), reporting concordant qualitative results (read coverage, taxonomic classification proportions, contig similarity) across the three analysis modules.
-
The pipeline's performance is demonstrated using a single confirmed-positive sample (SRR22029862) with descriptive, qualitative reporting of concordance across the three modules.↳ Could also: Benchmarking against a panel of known-positive and known-negative samples with quantitative sensitivity/specificity or precision-recall metrics could also be used. — This would allow readers to see quantitative detection performance across a range of viral loads and sample types, complementing the single illustrative case shown here.
-
Read classification and coverage results are described narratively (e.g., 'a majority of reads were classified into HTNV', 'segments were almost entirely covered').↳ Could also: Reporting exact percentages, read counts, or coverage depth with associated variability (e.g., per-segment coverage breadth and depth, classification confidence scores) could also be included. — Quantitative figures would let readers assess detection robustness more precisely and compare results across future runs or datasets.
-
The use case relies on one sample per virus (with additional raw outputs for other viruses noted as available in supplementary data) rather than a systematic multi-sample evaluation.↳ Could also: Analyzing replicate or multiple independent samples per pathogen and reporting summary statistics (e.g., mean/range of coverage or classification proportions across replicates) could also be used. — This would characterize run-to-run variability of the pipeline's outputs, which is relevant for tools intended for broad surveillance use.
What was reproduced
The exact results taken into scope, with each reported value next to the value our attempt produced.
Scope — pmid-37129547 (VirPipe)
Paper: Kim et al. 2023, Bioinformatics. "VirPipe: an easy-to-use and customizable pipeline for detecting viral genomes from Nanopore sequencing." DOI 10.1093/bioinformatics/btad293. PMID 37129547 / PMC10191607.
Code: https://github.com/KijinKims/VirPipe (default branch master,
HEAD ce0e25188cf72866ffe070b4744b6cb47aa75637, tag v1.0.0).
This is the authors' OWN tool — a Nextflow pipeline wrapped by a Python+Docker
launcher. P16 third-party-tool rule is moot; we run the authors' pipeline.
Data: SRA SRR22029862 (ENA single Nanopore fastq). Use-case dataset:
Nanopore (MinION) reads from rodent lung tissue, library amplified by multiplex
PCR targeting Hantaan orthohantavirus (HTNV). ENA: 253,256 reads / 125,035,665 bp,
Orthohantavirus hantanense (tax 3052480).
Nature of the paper's reported results
VirPipe is a software tool paper. The "results" are a qualitative use case (Application/Use-case section + figure), not a benchmark table. The paper makes essentially two concrete, pipeline-derived claims about SRR22029862:
| id | claim (paper) | module | how reproduced |
|---|---|---|---|
| C1 | "all three segments of HTNV were almost entirely covered by the input reads" | map (minimap2 -ax map-ont → bamcov coverage) |
coverage % of L/M/S HTNV RefSeq segments |
| C2 | "a majority of the reads were classified into HTNV" | classify-taxonomy (centrifuge vs viral DB → kraken-style report) |
fraction of reads assigned to Hantaan/Orthohantavirus |
Stretch (beyond the 80% floor):
| C3 | assembly recovers HTNV genome | assemble (Flye) | # contigs, total length vs HTNV genome ~11.8 kb |
| C4 | BLAST identifies closest reference as HTNV | blast (blastn vs ref_viruses_rep_genomes) | top hit taxonomy |
IN SCOPE (pipeline-derived)
- C1 map / coverage — CORE
- C2 classify-taxonomy / centrifuge — CORE
- C3 assemble (Flye) — stretch
- C4 blast closest-reference — stretch (needs large BLAST viral DB + taxonomizr)
- qc/preprocess (NanoFilt q>=8, len>=200) — supporting step feeding all of the above
OUT OF SCOPE (not pipeline-derived / not attempted)
- Wet-lab: rodent trapping, RNA extraction, multiplex-PCR amplification, MinION sequencing of SRR22029862 (generation of the data itself).
- zoonotic-rank module (optional add-on; ML zoonosis score, not a paper claim).
- The Docker-image build path (
virpipePython launcher needs a Docker daemon; HPC has none). We run the SHIPPED Nextflow modules directly with conda, which execute the identical tool commands — a faithful 1:1 of the pipeline compute.
Execution
All compute on «our HPC» (SLURM, partition std). Data + DBs + conda envs staged on
«infra» front1. Reproduce by running the authors' .nf modules
(map.nf, classify-taxonomy.nf, assemble.nf, blast.nf) with -profile conda,
patching the container-hardcoded paths («path»,
«path», «path») to the «infra» clone + built envs.
Assessments & scoring basis
Each contributor’s verdict, the per-question basis, and the auditable, itemised worksheet behind it.
An automated assessment. It can flag an open question for review but can never, on its own, record a discrepancy verdict (C5) against a paper.
Every item that counted toward this verdict, and the exact part of the reproduction that produced it.
This is a software-tool paper: VirPipe's qualitative use-case claims — all three HTNV segments 'almost entirely covered' and 'a majority' of reads classified as HTNV — reproduce cleanly (97.1/100.0/100.0% coverage at 4657-14813x; 82.43% Hantaan, 84.52% genus) by running the authors' own pipeline on the paper's own data (SRR22029862, md5-verified). The only soft spot is endpoint comparability (q2 yellow): the paper gives no numeric values, so the match is prose-to-number rather than 1:1. No authors'-side defect, no fabrication concern, and the central conclusion holds; severity is negligible.
Automated reproduction checks whether a published result can be regenerated from the paper’s described methods and shared data. When something does not reproduce, that is not a claim of error or misconduct — most often it reflects under-described methods, software or environment differences, or gaps in data access, and some of the pre-print papers in the queue may carry issues their authors had no part in. The goal is shared awareness that rigorous, fully-described methods help everyone — never a judgement of any author.
Are you an author? We would genuinely like to hear from you — to clarify the record, add data or code, re-run the pipeline after an accession update, and publish your response right next to the assessment. Everything here is open and auditable.
🚩 Report an error in this record
Spotted something wrong — a verdict you’d contest, a data or value error, or a private detail that slipped through? Tell us, with a short justification. Authors and readers are equally welcome to write in; we review every report.
Prefer email, or the form below not working? Contact us at support@doesitreproduce.com.
Reproduction footprint
claude-opus-4-8Measured resources invested to assess this paper — sanitised (machine class only, no job ids/paths). Compute = HPC accounting (SLURM); tokens = the AI agent's session.