Pith. sign in

REVIEW 3 major objections 5 minor 3 cited by

petrifyML supplies the missing converters that turn HEP-trained machine-learning models into ONNX or dependency-free native code, so published LHC analyses can be re-run and re-interpreted long after their original toolkits age out.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-04 16:42 UTC pith:OOVBDLAX

load-bearing objection A genuinely useful set of HEP-ML-to-ONNX/code converters, with the MVAUtils feature-count caveat being the main thing separating this from a clean accept. the 3 major comments →

arxiv 2509.11830 v2 pith:OOVBDLAX submitted 2025-09-15 hep-ph hep-ex

Enabling stable preservation of ML algorithms in high-energy physics with petrifyML

classification hep-ph hep-ex
keywords petrifyMLONNXboosted decision treesTMVAlwtnnMVAUtilsscientific reproducibilityHEP reinterpretation
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Machine learning in LHC physics has moved from an internal calibration detail to a public, analysis-defining component, so reproducing a physics result increasingly means reproducing the exact behavior of a trained algorithm. The paper presents petrifyML, a pip-installable Python package that converts model files from the HEP-standard tools TMVA, lwtnn, MVAUtils, and scikit-learn into two portable forms: the industry-standard ONNX format, or standalone C++/Python code with no toolkit dependencies. This fills a concrete gap because TMVA and lwtnn do not natively write ONNX, and MVAUtils files normally require ROOT to read. The payoff, if the conversions are faithful, is a lightweight path to preserve and re-interpret the ML models that ATLAS has published in non-standard formats.

Core claim

The paper's central claim is that petrifyML closes the preservation gap for HEP ML models by providing converter routines for every major non-ONNX format currently used in the field's published analyses. Concretely, it converts lwtnn and TMVA neural networks to ONNX, converts TMVA and scikit-learn boosted decision trees to ONNX or to native C++/Python, and converts MVAUtils-stored xgboost and lgbm forests to ONNX using the ONNX TreeEnsemble operator. The summary goes further, asserting that at the time of writing the package can convert all non-standard model formats published by the ATLAS collaboration without native ONNX support. Each converter can generate a validation script that runs bo

What carries the argument

The load-bearing mechanism is a set of converter pipelines built on the ONNX TreeEnsemble operator and on direct code generation. For BDTs from MVAUtils (xgboost/lgbm origin), the package parses the ROOT file with uproot and constructs the tree ensemble directly as an ONNX model, with optional sigmoid output for classifiers and user-adjustable opset/IR versions for compatibility. For TMVA and scikit-learn BDTs, it emits plain-text C++ or Python functions that encode each decision tree, preserving behavior without any dependency. For neural networks, it rebuilds TMVA MLPs as Keras models and exports via tf2onnx, and maps supported lwtnn layer types and activations directly to ONNX. The valida

Load-bearing premise

For MVAUtils BDTs, correct conversion depends on the user supplying the true number of input features, because the ROOT format does not record it and the converter's automatic guess can silently miss a feature that is absent from the early trees.

What would settle it

Construct a synthetic MVAUtils ROOT file from an xgboost forest in which the final feature is used only in a late tree, run petrify-mvautilsxgboost-to-onnx without --nf, and compare the ONNX output against the original xgboost output on inputs that vary that feature; any divergence shows the feature-count guess was wrong and the conversion silently dropped information.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • lwtnn-published networks become usable from Python for the first time, since ONNX inference is Python-native whereas lwtnn is C++-oriented.
  • ATLAS MVAUtils forests, including the 125,000-tree higgsino search forest, become runnable in reinterpretation tools without ROOT, removing a major practical obstacle for tools like Rivet, ColliderBit, and CheckMATE.
  • TMVA and scikit-learn BDTs can be preserved as self-contained C++ or Python source, guaranteeing unchanged inference with zero dependencies for small and medium forests.
  • Users can pin ONNX opset and IR versions to keep generated files loadable by older OnnxRuntime releases, and older opsets remain usable in future releases.
  • The package currently covers all ATLAS-published model formats lacking native ONNX support, so reinterpretation frameworks need not vendor aging HEP ML toolkits for those analyses.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the conversions prove faithful on a wider battery of physics-scale inputs, the natural next step is to treat ONNX as the preservation lingua franca for HEP ML, with petrifyML-style bridges for any remaining legacy format; the package's own validation scripts only sample one or a few input sets, so the community would need a broader test harness.
  • The MVAUtils feature-count blind spot suggests that published model formats should carry explicit provenance metadata (number of features, classifier vs response mode, class count); without it, silent conversion errors can go unnoticed until inference time.
  • The same converter architecture could be extended to other experiment-specific formats or to newer lwtnn layer types as ATLAS publishes them; the paper leaves those as future work but the modular design is intended to make such extensions straightforward.
  • A testable extension is to run petrifyML over every ATLAS HEPData ML deposit and compare against original MVAUtils/lwtnn/TMVA on inputs at physically relevant scales, not just random inputs; this would confirm or bound the 'all non-standard formats' claim.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. This release note presents petrifyML, a Python package and set of command-line tools for converting HEP ML model configurations into ONNX or dependency-free native C++/Python code. The supported inputs are lwtnn neural networks, TMVA multilayer perceptrons and boosted decision trees, scikit-learn gradient-boosted trees, and MVAUtils ROOT files originating from xgboost or lgbm. The paper documents installation, command-line options, generation of validation scripts, and known limitations, and claims in Section 6 that the package can convert all non-standard model formats published by the ATLAS collaboration without native ONNX support. No quantitative validation results, test coverage reports, or versioned code repository are shown in the preprint.

Significance. If the converters work as described, petrifyML fills a genuine gap in HEP model preservation: lwtnn and TMVA lack native ONNX export, and MVAUtils files are otherwise tied to ROOT. The paper is honest about several limitations, notably the MVAUtils feature-count ambiguity (Section 4.1.2 and footnote 3), the undefined behaviour for wrong --nClasses (Section 3.2.3), and the small sample of publicly released lwtnn files (footnote 6). The generated validation scripts are a useful practical feature. However, the central preservation claim is not backed by any end-to-end numerical comparison in the paper, and one documented failure mode can silently produce wrong ONNX output unless the user supplies external metadata. These issues are fixable and the contribution is potentially valuable, but the manuscript needs revision before the claims can be accepted.

major comments (3)
  1. [§4.1.2, footnote 3] The MVAUtils converters' default --nf heuristic is documented as being able to produce a silently wrong ONNX file: for a forest released with Refs. [24,25], the final input feature is invisible in the MVAUtils ROOT format, and the error is only apparent later when inference fails. This directly undermines the Section 6 claim that petrifyML 'can convert all non-standard model formats published by the ATLAS collaboration without native ONNX support.' As written, conversion of that class of files is not guaranteed by the package alone; it requires the user to supply the true feature count from SimpleAnalysis or similar. Please make --nf mandatory for MVAUtils inputs (or have the converter refuse to emit ONNX when the feature count cannot be verified), and adjust the abstract/summary to state this external-metadata requirement.
  2. [§3, §4.1.3, §5.2.3] No quantitative validation is reported. The paper explains that --write-validation/--run-validation emit comparison scripts, but it never demonstrates, even for one model, that the ONNX/C++/Python output matches the original framework's output. Since the stated purpose is accurate preservation, the paper should include at least one reproducible end-to-end test (e.g., a small TMVA, scikit-learn, lwtnn, or MVAUtils model with original vs converted scores) or a link to a public CI run with equivalence tests and coverage results. Without this, the core claim remains plausible but unverified.
  3. [§3, first paragraph] The statement that conversion to native code 'guarantees verbatim performance in perpetuity' is too strong. Identical source code can produce different floating-point results across compilers, architectures, and library versions. Recommend replacing 'guaranteeing verbatim performance' with a more precise claim such as 'removes framework dependencies and reproduces the model arithmetic in self-contained code', while noting the usual caveats about floating-point reproducibility.
minor comments (5)
  1. [§4.1.4] 'Version compatability options' contains a typo: 'compatibility'.
  2. [§2 / general] No source repository, version number, or permanent identifier (e.g., Zenodo DOI) for petrifyML is provided; only the PyPI install command is given. Adding a stable reference would improve reproducibility and is standard for software release notes.
  3. [§5.2.1, footnote 6] The sample of publicly released lwtnn files is currently one neural network. The statement that 'the present coverage is sufficient to cover all lwtnn json files so far publicly released by ATLAS' should explicitly acknowledge this sample size in the main text, not only in a footnote.
  4. [§3.2.3] Supplying an incorrect --nClasses value leads to 'undefined behaviour'. Consider adding a defensive check, or documenting whether the XML header contains the class count so that the converter can verify the user-supplied value.
  5. [§4.1.3, §5.2.3] The generated validation scripts use randomly generated inputs, which may be unphysical for some models. The paper already suggests replacing them, but a warning at generation time when no user inputs are provided would be a helpful safeguard.

Circularity Check

0 steps flagged

No circularity: petrifyML is a format-conversion tool; its claims are validated against external model files and runtime comparisons, not defined by its own outputs.

full rationale

The paper is a software release note describing converters from external ML model formats (TMVA, lwtnn, MVAUtils, scikit-learn) to ONNX or native code. There is no derivation chain, no fitted parameter, and no quantity that is defined in terms of the paper's own output. The central claim—that the package converts these formats—is checkable against the original model files and against runtime comparisons with the original toolkits (e.g., Sections 4.1.3 and 5.2.3 provide validation scripts that compare ONNX inference with MVAUtils/lwtnn inference). The known correctness limitation about the MVAUtils nfeatures guess (Section 4.1.2 and footnote 3) is explicitly acknowledged: the ROOT format does not record the number of input features, so the converter may guess wrong and silently produce an incorrect ONNX file unless the user supplies the true count from an external source such as SimpleAnalysis. This is a real operational caveat, but it is not circularity—it is an external-metadata dependency and an honest statement of a limitation. Similarly, the --nClasses requirement for TMVA multi-class BDTs and the opset/ir-version compatibility notes are practical constraints, not tautological reasoning. The citation of the Les Houches guide to reusable ML models is a community endorsement of ONNX, not a self-citation chain that forces the paper's conclusions. No equation or claim reduces to its own input by construction. Therefore the appropriate circularity score is 0.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

The paper introduces no fitted scientific parameters and no new physical entities. Its central claim rests on assumptions about the completeness of TMVA XML, the parseability of MVAUtils ROOT files by uproot, the sufficiency of the supported lwtnn schema, and the ability of user-specified ONNX opset/IR versions to be read by the target runtime. None of these are established by data in the preprint.

axioms (4)
  • domain assumption MVAUtils ROOT files can be parsed by uproot and the tree structure is faithfully represented; feature count is recoverable from external sources when guessing fails.
    Invoked in Section 4.1.2; if the parsed ROOT representation omits or obscures tree details, the ONNX TreeEnsemble output will be wrong.
  • domain assumption TMVA XML files contain complete, unambiguous descriptions of BDTs and MLPs (weights, splits, activations) sufficient to reconstruct them in other frameworks.
    Used in Sections 3.2 and 5.1; for multi-class BDTs the user must additionally supply nClasses, and wrong values cause undefined behavior (Section 3.2.3).
  • domain assumption The subset of lwtnn layer types and activations covered (Dense, Normalization; Relu, Sigmoid, Softmax, Elu, Tanh) is sufficient for all publicly released ATLAS lwtnn models.
    Stated in Section 5.2.1 and Table 1; at the time of writing this is one published network, so the empirical basis is thin.
  • domain assumption ONNX opset and IR version defaults produce files loadable by the target OnnxRuntime; if not, the user must set --opset and --ir-version correctly.
    Section 4.1.4 documents a known incompatibility between ONNX 1.18 defaults and OnnxRuntime 1.22.0, so conversion usability depends on version management.

pith-pipeline@v1.3.0-alltime-deepseek · 8670 in / 11342 out tokens · 115706 ms · 2026-08-04T16:42:27.030190+00:00 · methodology

0 comments
read the original abstract

Machine learning (ML) in high-energy physics (HEP) has moved in the LHC era from an internal detail of experiment software, to an unavoidable public component of many physics data analyses. Scientific reproducibility thus requires that it be possible to accurately and stably preserve the behaviours of these, sometimes very complex algorithms. We present and document the petrifyML package, which provides missing mechanisms to convert configurations from commonly used HEP ML tools to either the industry-standard ONNX format or to native Python or C++ code, enabling future re-use and re-interpretation of many ML-based experimental studies.

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Data Preservation in High Energy Physics: Global Report 2026

    hep-ex 2026-07 accept novelty 3.0

    The 2026 DPHEP report records substantial progress in HEP data preservation, including modern reanalyses of LEP legacy data and expanding open-data policies, alongside sustainability challenges.

  2. Search for pair-produced vector-like $T$-quarks decaying into $Ht$ final states in the lepton-plus-jets channel in $pp$ collisions at $\sqrt{s}$=13 TeV with the ATLAS detector

    hep-ex 2026-05 unverdicted novelty 3.0

    No excess observed in search for vector-like T-quarks in Ht channel; 95% CL mass limits set at 1.40 TeV (SU(2) singlet), 1.56 TeV (doublet), and 1.66 TeV (100% BR to Ht).

  3. Open LHC Monte Carlo Event Generation

    hep-ph 2026-05 unverdicted novelty 2.0

    A review of initiatives to make LHC Monte Carlo event generations available as open data to minimize redundant simulations and resource use.

Reference graph

Works this paper leans on

29 extracted references · 5 canonical work pages · cited by 3 Pith papers

  1. [1]

    Induction of decision trees,

    J. R. Quinlan, “Induction of decision trees,” Machine Learning, vol. 1, no. 1, pp. 81–106, 1986. doi: 10.1007/BF00116251

  2. [2]

    COMPUTATION AND CONTROL WITH NEURAL NETS,

    A. Corneliusen et al. , “COMPUTATION AND CONTROL WITH NEURAL NETS,” Nucl. In- strum. Meth. A , vol. 293, pp. 507–516, 1990. doi: 10.1016/0168-9002(90)91491-S

  3. [3]

    ATLAS b-jet identification performance and efficiency measurement with t¯t events in pp collisions at √s = 13 TeV,

    ATLAS Collaboration, “ATLAS b-jet identification performance and efficiency measurement with t¯t events in pp collisions at √s = 13 TeV,” Eur. Phys. J. C , vol. 79, no. 11, p. 970, 2019. doi: 10.1140/epjc/s10052-019-7450-8 . arXiv: 1907.05120 [hep-ex]

  4. [4]

    Identification of heavy, energetic, hadronically decaying particles using machine-learning techniques,

    CMS Collaboration, “Identification of heavy, energetic, hadronically decaying particles using machine-learning techniques,” JINST, vol. 15, no. 06, P06005, 2020. doi: 10.1088/1748-0221/ 15/06/P06005. arXiv: 2004.08262 [hep-ex]

  5. [5]

    Les Houches guide to reusable ML models in LHC analyses,

    J. Y. Araz et al. , “Les Houches guide to reusable ML models in LHC analyses,” Dec. 2023. doi: 10.21468/SciPostPhysCommRep.3. arXiv: 2312.14575 [hep-ph]

  6. [6]

    The ONNX development team, Onnx: Open neural network exchange , https://github.com/ onnx/onnx, Accessed: 2025-09-01

  7. [7]

    The toolkit for multivariate data analysis, TMV A 4,

    P. Speckmayer et al. , “The toolkit for multivariate data analysis, TMV A 4,” J. Phys. Conf. Ser., vol. 219, J. Gruntorad and M. Lokajicek, Eds., p. 032 057, 2010. doi: 10 . 1088 / 1742 - 6596/219/3/032057

  8. [8]

    D. H. Guest et al. , Lwtnn/lwtnn: V2.14.1 , version v2.14.1, Dec. 2024. doi: 10 . 5281 /zenodo . 14276439. [Online]. Available: https://doi.org/10.5281/zenodo.14276439

  9. [9]

    O. R. developers, Onnx runtime , https://onnxruntime.ai/, Version: 1.18.0, 2021

  10. [10]

    Array programming with NumPy,

    C. R. Harris et al. , “Array programming with NumPy,” Nature, vol. 585, no. 7825, pp. 357–362, Sep. 2020. doi: 10.1038/s41586-020-2649-2 . [Online]. Available: https://doi.org/10.1038/ s41586-020-2649-2

  11. [11]

    The pandas development team, Pandas, version latest, Feb. 2020. doi: 10.5281/zenodo.3509134. [Online]. Available: https://doi.org/10.5281/zenodo.3509134

  12. [12]

    [Online]

    Mart ´ ın Abadiet al., TensorFlow: Large-scale machine learning on heterogeneous systems, Software available from tensorflow.org, 2015. [Online]. Available: https://www.tensorflow.org/

  13. [13]

    Chollet et al

    F. Chollet et al. , Keras, https://keras.io, 2015

  14. [14]

    Pivarski, ”scikit-hep/uproot: 3.12.0”, Jul

    J. Pivarski, ”scikit-hep/uproot: 3.12.0”, Jul. 2020. doi: 10.5281/zenodo.3952728

  15. [15]

    Krekel et al

    H. Krekel et al. , Pytest, 2004. [Online]. Available: https://github.com/pytest-dev/pytest

  16. [16]

    Scikit-learn: Machine learning in Python,

    F. Pedregosa et al. , “Scikit-learn: Machine learning in Python,” Journal of Machine Learning Research, vol. 12, pp. 2825–2830, 2011

  17. [17]

    doi: 10.5281/zenodo.2641997

    ATLAS Collaboration, Athena, 2019. doi: 10.5281/zenodo.2641997

  18. [18]

    XGBoost: A scalable tree boosting system,

    T. Chen and C. Guestrin, “XGBoost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , ser. KDD ’16, San Francisco, California, USA: ACM, 2016, pp. 785–794, isbn: 978-1-4503-4232-2. doi: 10. 1145/2939672.2939785. [Online]. Available: http://doi.acm.org/10.1145/2939672.2939785

  19. [19]

    Lightgbm: A highly efficient gradient boosting decision tree,

    G. Ke et al., “Lightgbm: A highly efficient gradient boosting decision tree,” in Advances in Neural Information Processing Systems , I. Guyon et al. , Eds., vol. 30, Curran Associates, Inc., 2017. [Online]. Available: https : / / proceedings . neurips . cc / paper _ files / paper / 2017 / file / 6449f44a102fde848669bdd9eb6b76fa-Paper.pdf. 7 Acknowledgements 9

  20. [20]

    ROOT: An object oriented data analysis framework,

    R. Brun and F. Rademakers, “ROOT: An object oriented data analysis framework,” Nucl. Instrum. Meth. A , vol. 389, M. Werlen and D. Perret-Gallix, Eds., pp. 81–86, 1997. doi: 10.1016/S0168- 9002(97)00048-X

  21. [21]

    CheckMATE 2: From the model to the limit,

    D. Dercks et al., “CheckMATE 2: From the model to the limit,”Comput. Phys. Commun., vol. 221, pp. 383–418, 2017. doi: 10.1016/j.cpc.2017.08.021. arXiv: 1611.09856 [hep-ph]

  22. [22]

    Search for pair production of higgsinos in events with two Higgs bosons and missing transverse momentum in s=13 TeV pp collisions at the ATLAS experiment,

    ATLAS Collaboration, “Search for pair production of higgsinos in events with two Higgs bosons and missing transverse momentum in s=13 TeV pp collisions at the ATLAS experiment,” Phys. Rev. D , vol. 109, no. 11, p. 112 011, 2024. doi: 10.1103/PhysRevD.109.112011 . arXiv: 2401. 14922 [hep-ex]

  23. [23]

    v1, 2024

    ATLAS Collaboration, HEPData entry for ’Search for pair production of higgsinos in events with two Higgs bosons and missing transverse momentum in √s = 13 TeV pp collisions at the ATLAS experiment’ (Version 1) , HEPData (collection), https://doi.org/10.17182/hepdata.136030. v1, 2024

  24. [24]

    Search for R-parity violating supersymmetry in a final state containing leptons and many jets with the ATLAS experiment using √s = 13 TeV proton–proton collision data,

    ATLAS Collaboration, “Search for R-parity violating supersymmetry in a final state containing leptons and many jets with the ATLAS experiment using √s = 13 TeV proton–proton collision data,” Eur. Phys. J. C , vol. 81, no. 11, p. 1023, 2021. doi: 10.1140/epjc/s10052-021-09761-x . arXiv: 2106.09609 [hep-ex]

  25. [25]

    ATLAS Collaboration, HEPData entry for ’Search for R-parity violating supersymmetry in a final state containing leptons and many jets with the ATLAS experiment using √s = 13 TeV proton–proton collision data’ (Version 1) , HEPData (collection), https://doi.org/10.17182/ hepdata.104860.v1, 2021

  26. [26]

    SimpleAnalysis: Truth-level Analysis Framework,

    ATLAS Collaboration, “SimpleAnalysis: Truth-level Analysis Framework,” 2022.doi: 10.17181/ CERN.R6S3.0QKV

  27. [27]

    [Online]

    tf2onnx - Convert TensorFlow, Keras, Tensorflow.js and Tflite models to ONNX . [Online]. Avail- able: https://github.com/onnx/tensorflow-onnx

  28. [28]

    org/10.17182/hepdata.134010.v1, 2025

    ATLAS Collaboration, HEPData entry for ’Search for pair-production of vector-like quarks in pp collision events at √s = 13 TeV with at least one leptonically decaying Z boson and a third- generation quark with the ATLAS detector’ (Version 1) , HEPData (collection), https://doi. org/10.17182/hepdata.134010.v1, 2025

  29. [29]

    ATLAS Collaboration, “Search for pair-production of vector-like quarks in pp collision events at√s = 13 TeV with at least one leptonically decaying Z boson and a third-generation quark with the ATLAS detector,” Phys. Lett. B, vol. 843, p. 138 019, 2023. doi: 10.1016/j.physletb.2023. 138019. arXiv: 2210.15413 [hep-ex]