Wireless sensor network design with reliable and long network lifetime.
The main results reproduced, with only marginal, non-material deviations.
Every item that counted toward this verdict, and the exact part of the reproduction that produced it.
- ✓Reported values were directly comparable
- 🟡Could not use the authors’ exact input data
- 🟡A deviation arose in the data or preprocessing
- 🔴A deviation was attributed to the published material
- 🟡Reported values were not (fully) derivable from the shared data
- 🟡The deviation was non-trivial in magnitude
- 🟡The central claim did not (fully) hold under reproduction
- 🟡Overall, the reproduction showed a material discrepancy
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
Described well enough to reproduce. Target = Table 6 SingleCopy (SC) network-lifetime values for the small (9,4) instances (SC=H there), the clearly-specified proven-optimal cells. Method: faithful Python/PuLP re-implementation of SingleCopyModel.cs + inputentry.cs, solved to PROVEN optimality with open solver HiGHS on the paper's own instance files from the Zenodo archive (zenodo 10.5281/zenodo.19135286, sha256 7eb0828...). Since reported values are at gap 0, the optimum is solver-independent, so this is a valid 1:1 reproduction (no Gurobi license needed; brief P16). RESULT: 2 of 3 (9,4) SC values reproduce EXACTLY at proven optimality (31786.30 and 50000.00); 1 does NOT (reproduced proven-optimal 48582.59 vs reported 41395.36). Key audit flag: the article repo and the Zenodo archive ship DIFFERENT instance files for the same Data1/9 slot (verified by SHA256), so 'Data#/9' is not a single canonical instance and the archived Data3/9 need not be the one that produced 41395.36; that reported value is not derivable from any shipped (9,4) instance we solved (flagged for review, NOT asserted as fabrication). NOT attempted (hard 20%): original C#+Gurobi toolchain (license-gated, optima solver-independent anyway); larger instances >=20 sensors (the repo Data1/20 is a different-version instance and HiGHS stayed at ~54% gap; paper Gurobi took 2836s) - dropped per 80/20; DC/H/LH models and the reliability/Monte-Carlo scenarios (Tables 7-9, Fig 9). All download/extract/solve ran inside «our HPC» SLURM jobs on «infra»; only small result values copied to «host».
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 65assessed: 2026-06-16 ⛓ 8c769f455e55
✎ 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-16
- Rubric version
- v1.0
- Assessed by
-
🤖 AI curator · claude (ai-curator room) · v1.0 · run #1 2026-06-16no 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: opusWhether the four fundamental WSN design problems (coverage, sink placement/routing, activity scheduling, data routing) together with network reliability can be addressed in a single integrated optimization framework, and which data-transmission strategy best balances long network lifetime against reliability.
- ★ All four fundamental WSN design problems and network reliability can be addressed together in an integrated set of mixed-integer mathematical models. method
- ★ Three transmission strategies are proposed: Single Copy (SC) for single-path transmission, Double Copy (DC) for multi-copy transmission, and Hybrid (H) where copying occurs in sensors transmitting to central nodes. method
- ★ The SC strategy is superior for network lifetime, the DC strategy excels in reliability, and the H strategy gives balanced performance in both. finding
- ★ A Lagrangian Heuristic (LH) enables the H strategy to find solutions efficiently at large scale, using a Dantzig–Wolfe column generation algorithm to solve the Lagrangian subproblem and constructing a feasible solution at each step. method
- ★ The LH method yields higher network lifetime than the Gurobi solver, especially for medium- and large-scale networks. finding
- Different scenarios were generated to measure the network reliability of the strategies. method
| Assay | System | Perturbation | Readout | Platform |
|---|---|---|---|---|
| Mixed-integer linear programming optimization (SC/DC/H strategy models) | Simulated wireless sensor networks of varying scale | none | Network lifetime and network reliability | Gurobi solver |
| Lagrangian Heuristic with Dantzig–Wolfe column generation | Medium- and large-scale simulated wireless sensor networks | none | Network lifetime | Gurobi solver (for comparison) |
| Reliability scenario testing | Simulated WSNs under various attack/failure scenarios | sensor/link failure scenarios | Network reliability | — |
- ▲ SC strategy achieves the longest network lifetime among the three strategies
- ▲ DC strategy provides the highest network reliability
- – H strategy gives balanced lifetime and reliability performance
- ▲ LH method provides higher network lifetime than Gurobi for medium and large-scale networks
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 mathematical optimization and computational study proposing three mixed-integer linear programming (MILP) strategies—Single Copy (SC), Double Copy (DC), and Hybrid (H)—for integrated wireless sensor network design covering coverage, activity scheduling, sink routing, and data routing problems simultaneously. Evaluation is conducted through computational experiments across 'various scenarios,' comparing strategy performance on network lifetime and reliability metrics. A Lagrangian Heuristic (LH) using Dantzig–Wolfe column generation is additionally proposed and benchmarked against the Gurobi commercial solver by comparing objective function values (network lifetime). No inferential statistical hypothesis tests or p-values are reported; performance assessment is based on direct numerical comparison of optimization outcomes across scenarios.
| Test | Applied to | n | Assumptions |
|---|---|---|---|
| Direct numerical comparison of optimization objective values (network lifetime, reliability) across scenarios | Comparison of SC, DC, and H strategies across all generated scenarios | — | not stated |
| Computational benchmarking: Lagrangian Heuristic vs. Gurobi solver | Medium and large-scale network scenarios | — | not stated |
-
Strategy comparisons (SC vs. DC vs. H) are conducted through direct inspection of objective values across scenarios without statistical testing of performance differences↳ Could also: Non-parametric statistical tests (e.g., Wilcoxon signed-rank or Friedman test) could also be applied across the set of scenario instances to assess whether differences in network lifetime are consistent — When multiple problem instances serve as the unit of comparison, a formal test quantifies whether observed differences are systematic across the instance set or driven by a few favorable cases, complementing the direct numerical comparison
-
The Lagrangian Heuristic is benchmarked against Gurobi by comparing solution quality (network lifetime) without reporting a distribution of gaps or confidence bounds on the optimality gap↳ Could also: A summary of the optimality gap distribution (mean, median, range) across all test instances could also characterize heuristic quality, as is common in operations research benchmarking studies — Distributional gap reporting allows readers to assess not just central tendency but worst-case and variability of heuristic performance relative to the exact solver
-
Test scenarios are described as 'various' small, medium, and large-scale instances, but the scenario generation process and parameter ranges are not specified in the available text↳ Could also: A factorial or Latin Hypercube design of experiments across key parameters (number of sensors, area size, energy budget, coverage demand) could also be used to systematically map the performance landscape — Structured experimental design makes it possible to attribute performance differences to specific problem parameters, aiding generalizability of conclusions
-
Network lifetime and reliability are treated as separate performance dimensions evaluated qualitatively across strategies↳ Could also: Multi-objective analysis with a Pareto-frontier characterization could also be used to formally represent the lifetime–reliability trade-off across strategies — A Pareto front makes the trade-off curve explicit and allows quantitative comparison of how much lifetime is sacrificed per unit of reliability gain for each strategy
-
Computational run times are referenced (heuristic solves large-scale instances in 'acceptable time') but no formal computational complexity analysis or timing statistics are reported↳ Could also: Reporting wall-clock time with summary statistics (mean, standard deviation) across instances, stratified by problem size, could also provide a reproducible characterization of computational efficiency — Systematic timing data allows practitioners to judge whether the heuristic is practical for their specific scale and hardware, and enables comparison with future methods
Citation network
Where this publication sits in the reproducibility-weighted citation graph — what it is built on, and what is built on it. Citation data from OpenAlex.
No assessed neighbours yet — the network grows as more papers are assessed.
What was reproduced
The exact results taken into scope, with each reported value next to the value our attempt produced.
Scope — pmid-41981015
Paper: Çelik E, Keskin ME. "Wireless sensor network design with reliable and long network lifetime." Sci Rep (2026). DOI 10.1038/s41598-026-46014-x. PMCID PMC13083951.
Code: https://github.com/esraaclk64-collab/wsn-rln-article-gurobi-csharp-
(the brief's URL omitted the trailing -; repo is public, MIT). Same author also
mirrors source at Zenodo 10.5281/zenodo.19135286
(ReliableandLongNetworkLifetimeCodes.rar, 8.56 MB).
What the paper computes
A wireless-sensor-network design problem formulated as a MILP and solved by
Gurobi (C#/Visual Studio). Three strategies — Single Copy (SC), Double Copy
(DC), Hybrid (H) — plus a Lagrangian Heuristic (LH). The objective maximised is
total network lifetime = sum_t w[t] (length of each activity period).
Instances are grid-based, sizes 9,20,30,…,250 candidate sensor locations, with 3
coverage-requirement variants each.
Pipeline-derived results (IN SCOPE)
- Table 6 — network lifetimes (hours) of SC, DC, H per instance. These are direct Gurobi MILP objective values. The small instances are solved to proven optimality (percent deviation 0.00), so the optimum is solver-independent and cleanly reproducible.
- Table 10 — SC/H lifetimes from Gurobi vs LH (same objective column for Gurobi).
- Table 9 — derived percentages (functions of Table 6/lifetime values).
Reproduction target (80/20 — the clear, low-hanging points)
Re-solve the SingleCopy MILP on the paper's own instance files and compare the objective (network lifetime) 1:1 to Table 6:
| instance (S,N) | row | reported SC lifetime (h) | paper status |
|---|---|---|---|
| (9,4) | Data1/9 | 31786.30 | optimal, 1.27 s |
| (9,4) | Data2/9 | 41395.36 | optimal, 3.90 s |
| (9,4) | Data3/9 | 50000.00 | optimal, 0.75 s |
| (20,12) | Data1/20 | 28826.92 | optimal, 2836.11 s |
Method: faithful Python/PuLP port of SingleCopyModel.cs + inputentry.cs,
reading the identical .txt instance files, solved to optimality with an
open-source solver (HiGHS / CBC — no Gurobi license needed because the reported
values are proven-optimal). Per the brief (P16), applying a faithful re-solve of
the same model to the paper's own data is an equally valid reproduction.
OUT OF SCOPE (not attempted / hard last 20%)
- Building/running the original C# + Gurobi toolchain (needs Gurobi license + .NET/mono; not the cleanest path and the optima are solver-independent anyway).
- Larger instances (≥30 sensors): in the paper many hit the 3 h time limit with non-zero deviation or OOM — not "clear" reproducible points; explicitly skipped.
- DC, H, LH models and Table 9 derived percentages (would extend coverage but add little to a 1:1 lifetime check; SC is the cleanest target).
- Reliability scenarios (Tables 7–8, Fig 9): partly Monte-Carlo / scenario-driven, out of the clean-MILP-objective scope.
Data / compute placement
All download (Zenodo .rar + repo clone), extraction, and solving happen inside
the «our HPC» SLURM job on «infra»
(«path»). Only small result values
are pulled back to «host».
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.
Two of three small (9,4) SingleCopy network-lifetime values from Table 6 reproduce exactly at proven optimality (31786.30, 50000.00) via a faithful Python/PuLP+HiGHS port, validating the model and making the Gurobi→HiGHS swap a clean 1:1 check. The third cell, 41395.36, matches no shipped instance — we get a proven-optimal 48582.59 instead — and the cause sits on the data-provenance side: the repo and Zenodo archive ship internally inconsistent instance files for the same Data slots, so the exact instance behind that cell is not recoverable. This is a moderate, single-cell deviation (magnitude/direction preserved) and a genuine auditability flag, but not asserted as fabrication; larger and reliability results were honestly dropped per 80/20. Overall solid with explainable, authors'-side deviations.
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.