{"id":"0831251f-8592-48fc-8e10-640583428911","arxiv_id":"2607.02746","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"CodeJeNN auto-generates self-contained C++ code from trained Keras models, delivering 2–38× faster inference than Keras backends and enabling neural-network surrogates inside CFD solvers.","lead":"CodeJeNN converts trained Keras neural networks into standalone C++ header files, so physics solvers can run inference without Python or deep-learning libraries. In tests it ran inference 2–38× faster than Keras backends and embedded a viscosity model in a CFD mixing-layer simulation with at most 0.25% velocity error.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The load-bearing premise is that CodeJeNN's generated C++ reproduces the Keras model exactly; the paper reports no direct output-equality check, so the speed and accuracy claims may be about a different program.","rationale":"The reader's weakest assumption focuses on whether the viscosity surrogate's constitutive-level errors transfer to the CFD flow field, and on the single-snapshot evidence for the 0.25% velocity error. That is a legitimate concern about the demonstration. However, I find an even more fundamental premise: the generated C++ must actually reproduce the trained Keras model. Without a direct numerical equivalence check between the transpiled code and the original model, the speedups in Table 2 and the CFD accuracy in Figure 5 could be measuring a different network. The paper's own Section 3.4 acknowledges that logic/algebraic errors and custom-activation mismatches can occur during inference, making this a concrete risk, not a hypothetical one. This concern does not change the overall verdict: the paper remains a plausible, useful software contribution, and the missing check is readily addressable. Therefore the appropriate outcome is still conditional acceptance, pending the requested verification artifact. I mark agreement as partial because the reader identified a related but different weakest assumption; the missing output-equality check is mentioned only as a missing artifact, not as the central risk.","tokens_in":10947,"tokens_out":5419,"duration_ms":58400,"concrete_test":"Generate C++ output for the MLP, CNN, and viscosity MLP from the paper. For each, run Keras and the generated C++ on the same 10,000 fixed, seeded input samples (dropout in inference mode, batch normalization using stored moving statistics). Compare final outputs and, where possible, layer-by-layer activations using the debug API. Set a pass threshold of max relative error < 1e-5 and max absolute error < 1e-6. If the generated C++ does not match, the speedups and CFD error are not attributable to the trained model and the artifact needs correction before the central claim can be accepted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that CodeJeNN auto-generates self-contained C++ code that reproduces a trained Keras model. That requires numerical equivalence between generated C++ inference and Keras inference for the same inputs. The paper never demonstrates this. Section 3.4 describes a debugging API that prints the first ten values of each layer, but no such comparison is reported in Section 4. The 'network is verified against the Wilke model' in Section 4.2 checks the physics surrogate against the target constitutive model; it does not check that the generated C++ matches the Keras model. If the transpiler has any logic/algebraic error (normalization ordering, padding/stride handling in the transposed convolution, dropout inference scaling, or custom activation mismatch—the paper itself notes custom activations are a common source of mismatch, §3.4), then the benchmark speeds and the 0.25% velocity error are produced by a different network than the one trained in Keras. Since the contribution is explicitly a transpiler, this is the most load-bearing premise; the accuracy-transfer question in §4.2 is secondary to whether the generated code is faithful.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"CodeJeNN is a Python tool that loads a trained Keras model and emits a self-contained C++ header implementing forward inference, supporting a specified set of layers (dense, convolution/transposed convolution, pooling, normalization, dropout, etc.) and activations. The paper describes the workflow, algorithm structure, and limitations; benchmarks generated-code inference against Keras with TensorFlow and PyTorch backends in eager and JIT modes on one MLP and two CNN configurations using 10,000 random samples; and demonstrates integration in an OpenFOAM/DetonationFOAM hydrogen-air mixing-layer simulation in which a 385-parameter MLP replaces Wilke's mixture-viscosity model. Reported results are roughly 25x/38x speedups over eager TensorFlow/PyTorch Keras for the MLP, about 2.5x/9x over the corresponding JIT baselines, and a maximum x-velocity error of 0.25% in the CFD demonstration.","tokens_in":11230,"tokens_out":12993,"duration_ms":150001,"significance":"If the claims hold, CodeJeNN is a useful and well-scoped tool: it emits dependency-free, inlined, user-modifiable C++ inference code from Keras models, and the paper ships a reproducible benchmark protocol (single thread, dry run, 10,000 samples, three runs with standard deviations) against fair external baselines (TF/PyTorch eager and JIT on the same trained models). The speedup arithmetic in Section 4.1 checks out (e.g., 12.01/0.48 ~ 25x; 18.20/0.48 ~ 38x). The paper is also unusually candid about its envelope: Table 2's third column shows CodeJeNN slower than both JIT baselines in the memory-bound CNN case, and Section 3.4 explicitly lists topology and configuration limits. The CFD demonstration is a genuine end-to-end embedding into an OpenFOAM solver. However, the central claim has two load-bearing premises -- that the generated C++ reproduces the trained Keras model, and that accuracy is not sacrificed -- and the evidence for both is presently incomplete, as detailed below.","major_comments":[{"comment":"No direct numerical comparison is reported between CodeJeNN-generated C++ and Keras inference on the same inputs. The debug API described in Sec. 3.4 prints the first ten per-layer values, but no such comparison is shown for either benchmark model; the verification in Sec. 4.2 (Eq. (7)) is the surrogate against Wilke's rule, not the generated C++ against the trained Keras model. This is load-bearing because the benchmark MLP includes BatchNormalization and Dropout and the CNN includes a transposed convolution -- classic inference-mode/scaling mismatch points -- and Sec. 3.4 concedes 'there can still be logic/algebraic errors' after successful generation. A mis-transpiled network that still approximates Wilke could equally yield the small flow-field error in Sec. 4.2, so that test does not close the loop. Request a per-layer and final-output equivalence check (e.g., max absolute/relative","section":"Sec. 3.4 / Sec. 4.1"},{"comment":"The 'without sacrificing accuracy' claim rests on one simulation and one reported snapshot. The surrogate has mean relative viscosity error 0.12 and maximum 8.12 against Wilke's rule over 2,000 random samples, yet the reported flow-field velocity error is at most 0.25% at the Fig. 5 snapshot. The paper does not connect these numbers: it reports neither viscosity-error statistics over the states the CFD solver actually visits nor time-averaged/multi-snapshot velocity-error statistics. Also, the surrogate is trained on Wilke's rule generated by the accompanying utility and then verified against the same Wilke rule, so the demonstration is a self-consistency test of the pipeline, not a validation of the constitutive model -- which is fine for the tool's purpose, but the transfer of the 0.25% figure to states outside this case is asserted. Request: (i) report surrogate viscosity error over t","section":"Sec. 4.2, Eq. (7), Fig. 5"}],"minor_comments":[{"comment":"The text says the error field is evaluated after 'five more flow-through times,' while the Fig. 5 caption says 'Error after one flow-through time.' Reconcile, since the snapshot time determines which flow state is compared.","section":"Sec. 4.2 / Fig. 5 caption"},{"comment":"The unbounded-memory CNN column (CodeJeNN 10.75 s vs JIT-TF 3.60 s and JIT-PyTorch 8.47 s) shows generated code slower than both JIT baselines. The surrounding text discusses this correctly as a memory-bound transition, but the abstract's unqualified 'showing speedups' should be qualified to match the demonstrated cases.","section":"Abstract / Table 2"},{"comment":"The 25x/38x headline figures are for Keras in eager mode with JIT disabled (the stated baseline). TensorFlow default graph execution typically sits between eager and XLA; state explicitly that the headline speedups are versus eager mode to avoid overreading.","section":"Sec. 4.1"},{"comment":"No random seeds are given for training the benchmark models or for generating the 10,000-sample inference sets. Please provide the exact trained .keras files or the seeds used for Table 2.","section":"Sec. 4.1 / reproducibility"},{"comment":"Text issues: 'feedfoward' (Fig. 1); 'This allow pinpointing errors layer differences within a model' (Sec. 3.4); inconsistent 'detonatFOAM' vs 'DetonationFOAM' (Sec. 4.2). Also, Eq. (2) defines convolution without stride/dilation/padding indices although those are supported options; state the default convention.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper is a good fit for a computational-software venue; the tool is simple, useful, and honestly documented. The main risk to the decision is the equivalence-check gap: if the benchmarks were produced by a mis-transpiled program, the headline results would be void, so I would treat the requested C++-vs-Keras equivalence table as a condition for acceptance rather than a suggestion. The CFD accuracy claim is a single-case demonstration and should be framed as such. I did not find grounds for reject; both load-bearing issues are well-scoped and fixable within the paper's framework."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is a solid software description: CodeJeNN turns a trained Keras model into a self-contained C++ header, and the benchmarks against Keras backends are real and internally consistent. The MLP speedups (25–38×) are plausible, the JIT comparisons are fair, and the CFD demonstration shows the tool can be embedded in a solver. The authors are honest about limitations in §3.4, and the AI disclosure is transparent. The repo link is there. That is the good part.\n\nThe main hole is exactly what the stress-test note flags: no direct output-equality check between the generated C++ and the original Keras model. The debugging API is described, but no comparison is reported. If the transpiler has an algebraic error—say, in normalization order or transposed-convolution strides—the benchmark speeds and the 0.25% velocity error are produced by a different program. The CFD case gives indirect evidence that the generated network is a reasonable viscosity surrogate, but it does not establish that the C++ reproduces the Keras model. That should be the first thing a referee asks for.\n\nThe second soft spot is the abstract's \"without sacrificing accuracy.\" It is oversold. The larger CNN in Table 2 is slower than JIT baselines, and the accuracy claim rests on one CFD case where the surrogate has a mean relative viscosity error of 0.12 (max 8.12) against Wilke. The flow error staying under 0.25% is nice, but it is one simulation, one snapshot. The claim should be qualified.\n\nThe citation picture is mostly fine—ONNX and RoseNNa are cited—but the wider keras2cpp ecosystem is missing, which is worth noting as a minor gap. The missing artifacts (commit-pinned repo, benchmark scripts, the DetonationFOAM patch) are addressable and should be supplied.\n\nWho is this for? Computational physics groups that train small Keras models and want dependency-free C++ inference. It fills a real niche next to RoseNNa. I would send it to peer review, but the verdict should be conditional: ask for a direct fidelity check (e.g., compare generated C++ outputs to Keras on a test set, with a stated tolerance), qualify the accuracy claim, and complete the reproducibility package. With those, it is a useful contribution.","headline":"CodeJeNN is a useful Keras-to-C++ transpiler with honest benchmarks, but the abstract oversells 'without sacrificing accuracy' and the paper never directly shows the generated C++ matches the trained Keras model.","tokens_in":11830,"tokens_out":2130,"would_cite":true,"duration_ms":24285,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":null,"created_at":"2026-08-04T01:41:58.916296+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":null,"supporting_citations":[],"review_version":2}