{"id":"056d8662-688c-46f3-9aee-5707006cce22","arxiv_id":"2501.09271","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A new GlobalStore component allows SNiPER-based physics software to cache multiple events and process them in parallel, giving near-linear speedups up to five threads.","lead":"This paper presents a parallelized event data management system for high-energy physics software, combining the SNiPER framework with the PODIO toolkit so multiple events can be processed concurrently with dedicated input and output threads. It matters because next-generation experiments like the Super Tau Charm Facility will produce hundreds of petabytes of data per year and need faster offline processing.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Correctness rests only on visual histogram overlap: no event-level comparison, no event-count check, and no statistical test, so Fig. 10 cannot rule out dropped, duplicated, or reordered events in the parallel path.","rationale":"The reader's weakest assumption is that event-level parallelism is valid for STCF simulation and EMC reconstruction. I agree that this is the key assumption, but the more precise problem is that the paper never actually tests it at the event level: Fig. 10 compares aggregate distributions, which are insensitive to event loss, duplication, or order-dependent corruption. The architecture is plausible and the GlobalStore status mechanism is a reasonable design, but the described output timing and 'promptly clears' behavior create enough ambiguity that event-level loss cannot be ruled out without a direct check. The speedup result also lacks error bars and hardware details, but that is secondary to whether the parallel outputs are correct. These concerns do not overturn the reader's conditional verdict; they strengthen the conditions under which the paper should be accepted. Reproducible code and an event-level output comparison would settle the matter.","tokens_in":8439,"tokens_out":7283,"duration_ms":74236,"concrete_test":"Rerun the OSCAR benchmark with both serial and MT modes writing event IDs and per-event reconstructed cluster energies/crystal depositions; then compare the two output files event-by-event, verifying exact count and matching values within floating-point tolerance. Also run a two-sample Kolmogorov-Smirnov test on the Fig. 10 distributions; if any event is missing, duplicated, or reordered, or if the KS test rejects at the 1% level, the consistency evidence fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4 validates the central consistency claim by overlaying reconstructed EMC distributions in Fig. 10 and stating they are 'largely consistent' between single- and multi-threaded modes. No event-count equality is quoted, no goodness-of-fit test is reported, and no event-by-event comparison is made. This is load-bearing because the Section 3 design defers output: the output thread writes only after all events are completed, while GlobalStore 'promptly clears these processed events to accommodate incoming events.' If any event is dropped, duplicated, or its data mutated before write-out, aggregate histograms over 20,000 single-electron events would still look nearly identical. The speedup claim in Fig. 11 also relies on three repetitions without error bars and on an unspecified hardware/OS context, but the primary gap is the unverified event-level correctness of the parallel output path.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents the design and implementation of a parallelized event data management (PEDM) system built on the MT-SNiPER framework and the PODIO event data model toolkit. The system introduces a GlobalStore component that caches multiple events, dispatches them to worker threads via Muster, and uses dedicated input/output threads to decouple I/O from processing. The authors validate the system in the OSCAR offline software for the STCF experiment by simulating and reconstructing 20,000 single-electron events, comparing reconstructed EMC distributions between serial and multi-threaded modes, and measuring speedup versus thread count. The paper claims that the PEDM system produces output consistent with the serial mode and achieves near-linear speedup up to about five worker threads.","tokens_in":8717,"tokens_out":2413,"duration_ms":25585,"significance":"If the correctness and performance claims are substantiated, the paper would be a useful engineering contribution to HEP offline software, demonstrating a concrete integration of MT-SNiPER and PODIO with a generic parallel event data management design that could be adopted by other experiments. The use of standard software components (SNiPER, PODIO, TBB) and a real application in OSCAR gives the work practical relevance. The paper's strengths are its clear architectural description of the GlobalStore and I/O decoupling, and the explicit demonstration of speedup on a realistic simulation/reconstruction chain. However, the current validation is not statistically rigorous and does not establish event-level correctness of the parallel output path.","major_comments":[{"comment":"The correctness claim rests entirely on visual agreement of reconstructed EMC histograms between serial and multi-threaded modes. The paper reports no event-count equality, no event-by-event comparison, and no statistical test (e.g., a chi-square or Kolmogorov-Smirnov test) of the distributions. For 20,000 single-electron events, aggregate histograms would appear nearly identical even if a small fraction of events were dropped, duplicated, or reordered. The authors should add an explicit event-count check and an event-level comparison (for example, comparing per-event cluster energies or at least the total number of written events) to demonstrate that the parallel path preserves exactly the same events as the serial path.","section":"Section 4, Fig. 10"},{"comment":"There is an internal inconsistency in the description of the output lifecycle. The text states that 'the output thread sequentially writes the marked events into the root file as persistent data' only after all events have been processed, and also that 'the GlobalStore promptly clears these processed events to accommodate incoming events.' If processed events are cleared from GlobalStore, it is unclear where their data resides until the output thread writes them. The sentence that 'events processed in worker threads can be written out without waiting for previously processed events' appears to contradict the sequential-write-after-completion description. The authors should clarify the data flow: is event data copied to a separate output buffer, or does the output thread write from GlobalStore before clearing? This is load-bearing for the guarantee that no event data are lost or mutated before write-out.","section":"Section 3, Fig. 9 and accompanying text"},{"comment":"The speedup measurement is based on only three repetitions per thread count, with no error bars, no standard deviation, and no description of the hardware and software environment (CPU model, number of physical cores, memory, OS, compiler, ROOT/TBB versions). The near-linear speedup claim up to five threads and the subsequent deviation therefore lack the uncertainty quantification and reproducibility information expected for a performance claim. At minimum, the authors should report the run-to-run spread, the machine configuration, and ideally repeat the benchmark with a second workload to show that the result is not particular to the single-electron EMC chain.","section":"Section 4, Fig. 11"}],"minor_comments":[{"comment":"The legend labels 'Rec-MT' and 'Rec' are not defined in the caption; the paper should explicitly state which one corresponds to multi-threaded and which to single-threaded mode, or use the same terms as the text ('multi-threading' and 'single-threading').","section":"Section 4, Fig. 10"},{"comment":"There is a typographical error in the grant number: '2021YF A0718403' should likely be '2021YFA0718403'.","section":"Acknowledgements"},{"comment":"The caption 'Conditional execution of algorithm subsets' is unclear; the figure appears to illustrate the incident mechanism between tasks, so the caption should describe the actual content of the figure rather than a vague phrase.","section":"Section 2.1, Fig. 3 caption"},{"comment":"The terms 'EventStore', 'event store', and 'GlobalStore' are used with inconsistent capitalization and sometimes without a definite article; a consistent naming convention would improve readability.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper is a system description with a benchmark that is currently too weak to fully support the central correctness claim. The missing event-level validation is the main technical gap, and the internal inconsistency in the output-write description should be resolved before publication. The paper fits the scope of an instrumentation/software journal, but the authors should be asked to either provide the additional validation or temper the claims to what the current evidence supports."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper delivers a real piece of engineering: GlobalStore extends PODIO's single-event EventStore into a multi-event buffer with worker-local data access, and the integration with MT-SNiPER plus dedicated I/O threads is clearly described. That is genuinely new for this ecosystem and plausibly useful for JUNO, LHAASO, nEXO, and STCF. The benchmark shows near-linear speedup up to about 5 threads and visually consistent reconstructed distributions, which is a reasonable existence proof.\n\nThe soft spots are all in validation. The core claim that parallel processing preserves event-level correctness is supported only by overlay histograms in Fig. 10, with no event-count check, no goodness-of-fit test, and no event-by-event comparison. That matters because the design defers output: the GlobalStore clears processed events to free slots, and the output thread writes later. If an event were dropped, duplicated, or mutated, aggregate distributions for 20,000 single-electron events would still look nearly identical. The stress-test note is right to flag this. The design may well be correct—the Ready/Occupied/Done states are a sensible guard—but the paper does not demonstrate it.\n\nThe performance section is also thinner than it should be: three repetitions, no error bars, a single workload, and no stated hardware/OS context. The speedup curve is plausible but not rigorous. I am not manufacturing a flaw here; these are fixable with modest effort, and the missing artifacts (code/data release) would make the whole thing verifiable.\n\nIs the central argument sound? Probably yes, the speedup is a measurement and the consistency is likely real, but the evidence presented does not fully rule out the alternative. The authors should be asked to add a direct event-by-event comparison, quote event counts, and either release the benchmark code or describe the environment in enough detail to reproduce.\n\nWho is this for? Developers working on SNiPER-based offline software and people integrating PODIO into threaded frameworks. They will get value from the design discussion even if the benchmark stays weak. The paper deserves a serious referee—it is a real implementation, not a toy—but it needs major revision before I would trust it as evidence of correctness. I would not cite it for the performance numbers, but I might cite it as a reference for the GlobalStore design once it is more solidly validated.","headline":"Useful engineering for the SNiPER/PODIO ecosystem, but the validation is too thin to prove event-level correctness and the performance claims need more rigor.","tokens_in":9118,"tokens_out":1892,"would_cite":false,"duration_ms":33840,"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":"This paper shows that a redesigned event-data management system, caching multiple events in a GlobalStore with dedicated input and output threads, lets particle-physics offline software process events in parallel and cuts runtime with…","keywords":["offline data processing","multi-threading","SNiPER","PODIO","event data model","GlobalStore","Super Tau Charm Facility","high energy physics"],"falsifier":"Process the same 20,000-event sample in serial mode and in parallel with more than five worker threads, and compare event-by-event reconstructed EMC clusters; if the per-event outputs differ even though histograms match, the claimed consistency fails. Alternatively, introduce a shared calibration constant that is updated per event and check whether parallel-mode distributions diverge from serial.","tokens_in":8249,"feed_emoji":"⚛️","tokens_out":6333,"duration_ms":55595,"temperature":0.7,"pith_summary":"The paper aims to show that a common event data management system for high-energy physics offline software can be made parallel by integrating the MT-SNiPER framework with PODIO's event data model and adding a new GlobalStore for multi-event caching. This matters because future experiments such as the Super Tau Charm Facility will generate hundreds of petabytes of data per year, and single-threaded processing will not keep up. Using 20,000 simulated single-electron events, the authors run full detector simulation and electromagnetic-calorimeter reconstruction in multiple threads and find that processing time drops with near-linear speedup up to about five worker threads, while reconstructed physics distributions remain largely consistent with serial mode.","feed_headline":"Parallel event cache speeds particle-physics data processing","feed_subtitle":"Redesigned GlobalStore and dedicated I/O threads keep physics results consistent while cutting runtime.","key_machinery":"The central object is the GlobalStore, a thread-safe in-memory cache that holds multiple event elements, each tagged with an index and a status (Ready, Occupied, Done). Workers lock an event, process it within a thread-local SNiPER Task, and mark it Done; a dedicated input thread fills the store from disk while a dedicated output thread writes completed events to root files. GlobalStore replaces PODIO's single-event EventStore, which had not been designed for multithreading.","core_discovery":"The authors claim that by replacing PODIO's single-event EventStore with a thread-safe GlobalStore that caches many events at once, and by assigning data input and output to two dedicated threads, event processing in the offline software becomes naturally parallel. Each worker thread runs a thread-local SNiPER Task that behaves like a serial job, acquiring events from the GlobalStore, processing them, and marking them done; the output thread later writes completed events to root files in order. The performance study in OSCAR, the STCF offline software, shows that full detector simulation and EMC reconstruction of 20,000 single-electron events produce reconstructed cluster energies and energy-deposition distributions that are largely consistent between single-threaded and multi-threaded modes, and the speedup ratio is close to linear up to about five threads.","pith_inferences":["If the event-independence assumption holds beyond EMC reconstruction, the same GlobalStore design should extend to other OSCAR chains such as tracking and particle identification with similar speedups.","The consistency check compares aggregate histograms; a stricter event-by-event comparison of serial versus parallel output could reveal order-dependent effects that mean distributions would mask.","The speedup plateau suggests that for many-core machines, the next step would be intra-event parallelism or batching larger workloads per task.","The pattern of decoupling I/O onto dedicated threads and using a shared status-indexed event cache is framework-agnostic and could be applied to other PODIO-based data processing systems."],"forward_implications":["OSCAR's full detector simulation and EMC reconstruction chain runs faster with the PEDM system, reducing total processing time for large event samples.","The speedup remains close to ideal up to about five worker threads, after which scheduling overhead makes the gain deviate from linear.","Reconstructed EMC cluster energy and 3x3 and 5x5 crystal energy-deposition distributions in multi-threaded mode are largely consistent with serial mode.","Because the design is general, other HEP experiments using SNiPER and PODIO can adopt the same global-store plus dedicated-I/O pattern for parallel event processing."],"supporting_citations":[{"why":"Supplies the SNiPER framework whose Task, Services, and DataStore structure the PEDM system extends.","marker":"[7]"},{"why":"Implements MT-SNiPER, the TBB-based multithreading that lets multiple workers run in parallel.","marker":"[15]"},{"why":"Provides PODIO and its EventStore, the EDM toolkit whose single-event store the paper redesigns.","marker":"[17]"},{"why":"Describes the Muster scheduler in MT-SNiPER that maps SNiPER Tasks to TBB workers.","marker":"[22]"},{"why":"Defines Intel TBB, the threading library that underlies the worker threads.","marker":"[19]"},{"why":"Describes OSCAR, the STCF offline software in which the PEDM system is benchmarked.","marker":"[18]"},{"why":"Documents that PODIO's EventStore was never intended for multithreading, motivating the GlobalStore redesign.","marker":"[23]"}],"fun_headline_variants":["Parallel data store boosts HEP processing speed","Thread-safe event cache scales physics runs linearly","GlobalStore parallelizes HEP data flow up to 5x","Near-linear speedup from parallel event caching","New cache design speeds particle data processing"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The benchmark assumes events are statistically independent, so each worker thread can process and write events in any order without changing the physics results.","fun_headline_variants_meta":{"raw":{"variants":["Parallel data store boosts HEP processing speed","Thread-safe event cache scales physics runs linearly","GlobalStore parallelizes HEP data flow up to 5x","Near-linear speedup from parallel event caching","New cache design speeds particle data processing"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000537,"raw_usage":{"total_tokens":2553,"prompt_tokens":896,"completion_tokens":1657,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":512,"completion_tokens_details":{"reasoning_tokens":1587}},"tokens_in":512,"tokens_out":1657,"duration_ms":11892,"temperature":1.0,"reasoning_tokens":1587,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T20:05:33.262719+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Process the same 20,000-event sample in serial mode and in parallel with more than five worker threads, and compare event-by-event reconstructed EMC clusters; if the per-event outputs differ even though histograms match, the claimed consistency fails. Alternatively, introduce a shared calibration constant that is updated per event and check whether parallel-mode distributions diverge from serial.","supporting_citations":[{"cited_title":"Journal of Physics: Con- ference Series 664(7), 072053 (2015) https: //doi.org/10.1088/1742-6596/664/7/072053","cited_arxiv_id":null,"evidence_quote":"Supplies the SNiPER framework whose Task, Services, and DataStore structure the PEDM system extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Implements MT-SNiPER, the TBB-based multithreading that lets multiple workers run in parallel."},{"cited_title":"(ed.) Intel ® Threading Building Blocks (TBB), pp","cited_arxiv_id":null,"evidence_quote":"Defines Intel TBB, the threading library that underlies the worker threads."},{"cited_title":"Of Frames and schema evolution -- The newest features of podio","cited_arxiv_id":"2312.08199","evidence_quote":"Documents that PODIO's EventStore was never intended for multithreading, motivating the GlobalStore redesign."}],"review_version":1}