Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

CelloAI: Leveraging Large Language Models for HPC Software Development in High Energy Physics

T0 review · 4 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Open-weight language models can match commercial assistants at HEP code porting when retrieval supplies the missing kernels first.

desk verdict Useful local RAG system and a needed measurement, but the central retrieval-completeness table contradicts its own score definition. read the letter →

arxiv 2508.16713 v1 pith:DAVE4CPL submitted 2025-08-22 cs.SE cs.AIhep-ex

Mohammad Atif , Kriti Chopra , Ozgur Kilic , Tianle Wang , Zhihua Dong , Charles Leggett , Meifeng Lin , Paolo Calafiura
show 1 more author
Salman Habib
This is my paper
classification cs.SEcs.AIhep-ex
keywords CelloAIretrieval-augmentedgeneration(RAG)HPCsoftwaredevelopmenthighenergyphysicskernelportingsyntax-awarechunkingcallgraphopen-weightLLMs
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

CelloAI is a locally hosted coding assistant for high-energy physics code. The paper's central claim is that LLM porting failures in HPC are mostly a retrieval problem: when a codebase exceeds a few hundred kernels, commercial assistants miss most of them, and open-weight models cannot port kernels they never see. CelloAI's retrieval pipeline—separate code and text collections, syntax-aware Tree-sitter chunking, exact-symbol reranking, and two-hop callgraph lineage—restores coverage, raising open-weight models from 2-4 of 8 kernels to 8 of 8 on the FastCaloSim porting test. Retrieval completeness scores jump from 0.227 to 0.790 for one embedding model on CUDA and to 0.936 on OpenMP. If this is right, privacy-preserving local LLMs can take over a meaningful slice of scientific code migration, with the remaining hard kernels blocked by memory-mapping reasoning.

What carries the argument

CelloRetriever—a hybrid retrieval pipeline that embeds code and prose in separate vector collections, chunks code with Tree-sitter into complete functions and classes, reranks candidates by exact symbol matches, and augments the prompt with a two-hop callgraph lineage (immediate callers and callees in natural language). The pipeline's job is to make the context given to the LLM complete, because the paper's argument is that retrieval completeness, not model size or specialization, is what decides whether kernels get ported.

What would settle it

Run a static analyzer over Patatrack to count every __global__/__device__ function and kernel launch site, then compare the total to the asserted 1,490; if the true count differs by more than a few percent, every completeness ratio in Table VII changes along with the embedding-model ranking. Alternatively, rerun the kernel-collection prompt on a small codebase with a manually enumerated kernel list and check whether CelloRetriever's top-40 context reproduces the reported score.

Watch

Extended reading notes

Core claim

The paper claims that the reason open-weight LLMs fail at HPC porting is not generation ability but missing context: models cannot enumerate or port kernels they never see. CelloAI's retrieval system—separate code/text embeddings, Tree-sitter syntax-aware chunking, exact-symbol reranking, and two-hop callgraph lineage appended to the prompt—fixes coverage. With it, local 14B-123B models identify and port all eight FastCaloSim kernels, while most baselines get two to four, and retrieval completeness rises substantially, e.g., from 0.227 to 0.790 for one embedding model on CUDA and to 0.936 on OpenMP. Easy and moderate kernels compile; hard kernels still fail on host-device memory-map reasonin

Load-bearing premise

Completeness scores divide retrieved kernels by curated ground-truth totals for each testbed (for example, 1,490 CUDA kernels for Patatrack, 8 for FastCaloSim), and those totals are asserted without a described counting method; if they are wrong, every reported score and model ranking changes.

Editorial extensions

If this is right

  • A local, deterministic retrieval layer can make small open-weight models match or beat closed commercial assistants on kernel enumeration and coverage in multi-thousand-kernel codebases.
  • Code-porting workflows can be structured as two-step prompts—first enumerate kernels, then port them with callgraph context—rather than asking the model to scan the repository.
  • The hard-kernel bottleneck shifts from kernel discovery to host-device data-motion reasoning, which the paper identifies as the target for future fine-tuned porting models.
  • Generated documentation can be inserted safely by wrapping LLM output in comment blocks and watermarking it, so automatic documentation does not risk executing hallucinated code.
  • Reproducibility demands pinned local models plus tuned decoding parameters; temperature choices trade reproducibility against output quality.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The exact-symbol rerank is effectively a deterministic filter layered on semantic search; the same 'semantic recall plus exact-match precision' pattern could improve RAG for other symbol-dense scientific code, such as Fortran or Python numerical libraries, without retraining.
  • The reported completeness scores divide by curated kernel totals whose counting method is not described; an independent static-analysis census of kernels in each testbed would make cross-application comparisons more portable than the current per-application ratios.
  • Hard-kernel failures cluster around host-device data motion, suggesting a targeted retrieval item—canonical memory-map snippets rather than full kernels—might be the next testable extension of the context-assembly pipeline.
  • The callgraph augmentation adds only two hops; whether more hops help or dilute context is an open question the paper does not test.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. CelloAI is a locally hosted, RAG-based coding assistant targeting HEP/HPC software. It separates code and text into independent ChromaDB collections, uses Tree-sitter syntax-aware chunking, applies a retrieval pipeline (CelloRetriever) with exact-symbol pattern matching, and augments prompts with two-hop callgraph lineage. The paper evaluates the pipeline on four HEP testbeds (FastCaloSim, P2R, Patatrack, WireCell) for kernel retrieval completeness with four embedding models, for documentation generation, and for CUDA-to-OpenMP porting with several open-weight LLMs. The central claims are that CelloRetriever consistently improves kernel-retrieval coverage over the same embedding models without it, and that the full CelloAI pipeline improves the number of kernels that local LLMs can port, with downstream compile/correctness checks. The paper also reports a blinded instruction-adherence study and openly discusses limitations in memory mapping and directive selection for hard kernels.

Significance. If the quantitative claims hold, the paper makes a useful applied contribution: it demonstrates a privacy-preserving, on-premise LLM workflow for a real and pressing problem—porting HEP code to heterogeneous architectures—and evaluates it on real codebases from ATLAS, CMS, and DUNE. The downstream porting experiment with compile/correctness checks is valuable and less prone to the circularity that affects the retrieval metric. The paper also gives credit for explicitly enumerating failure modes and for comparing multiple open-weight model families. However, the main retrieval-completeness result is not reproducible from the data as published: key scores in Table VII contradict the counts in the same table, and the ground-truth totals that define the metric are not justified. The central retrieval claim therefore needs correction and additional transparency before the paper can be accepted as written.

major comments (4)
  1. [§V.A.3, Table VII] The reported completeness scores are not derivable from the counts in the same table under the metric stated in the text (mean per-application ratio of retrieved to total kernels). For example, Lajavaness/bilingual-embedding-large CUDA CelloRetriever: (8/8 + 191/1490 + 44/119)/3 = 0.499, not the reported 0.790. SFR-Embedding-Code-2B_R CelloRetriever: (8/8 + 179/1490 + 53/119)/3 = 0.522, not 0.359. Since this table is the quantitative basis for the claim that CelloRetriever consistently improves retrieval across embedding models, the values must be corrected or the computation clarified. Please show the per-application ratios, define how multi-application means are computed, and state how rows with zero retrieved kernels are handled.
  2. [§V.A.3, ground-truth curation] The completeness metric divides retrieved kernels by a "curated ground-truth list from various applications," but the paper never states how these ground-truth totals were obtained. The totals (e.g., 1,490 CUDA kernels for Patatrack, 8 for FastCaloSim, 119 for P2R) are load-bearing: changing any total changes every score, the embedding-model ranking, and the headline retrieval claim. The paper should provide the curation procedure, the exact list or a versioned artifact, and explicit inclusion/exclusion rules (e.g., whether __global__ and __device__ functions both count, how lambdas and templated kernels are handled, whether namespaces or file paths affect the count). Without this, the scores cannot be independently verified.
  3. [§V.C, Table VIII] The text states that with CelloAI "each model ports all kernels, except Llama-3.3-70B-Instruct which ports 7/8 kernels," but Table VIII shows Llama-3.3-70B CelloAI coverage as 6/8. This discrepancy is directly relevant to the claim that CelloAI raises coverage for open-weight models. In addition, the meaning of "coverage" is ambiguous: it appears to count kernels for which the model produced some ported code, independent of whether that code compiles or is correct, because the table lists Compilable/Correct separately. Please define coverage precisely and reconcile the text/table mismatch.
  4. [§IV.C and §V.A.3, metric alignment] There is a partial circularity risk in the retrieval evaluation. CelloRetriever's pattern-matching step explicitly reranks chunks with exact symbol matches to the top, and the completeness metric counts how many ground-truth kernel names appear in the retrieved/emitted context. The reported improvement of CelloRetriever over Base is therefore partly attributable to the metric rewarding exactly what the reranker is designed to do. This does not invalidate the system for the kernel-enumeration task, but the paper should separate the effect of the reranker from the effect of the collections/chunking: e.g., report a no-pattern-matching ablation, or present retrieval quality on a task that is not purely symbol-name matching. The downstream porting results (Table VIII) are less circular and should be featured more prominently as evidence for the end-to-end claim.
minor comments (4)
  1. [Table II] The header layout is difficult to read: "Code T ext" appears as a column heading and the next row splits into file/word counts. Please reformat so that the two collection types (Code, Text) and their units are clearly labeled.
  2. [§V.C, instruction adherence] The blinded human study is scored by the authors on a 0–10 scale. Please report the rubric in more detail and, if possible, agreement statistics (e.g., per-item variance) to make the ratings reproducible. This is a secondary metric, but it is currently presented without inter-rater information.
  3. [General] No artifact URL, repository link, or versioned configuration is provided. For an applied systems paper in this area, releasing the retrieval pipeline configuration, ground-truth lists, and evaluation prompts would substantially increase reproducibility and trust in the quantitative claims.
  4. [Figure 1 caption] The caption reads "Categorization of an coding assistant's tasks"; "an" should be "a".

Circularity Check

1 steps flagged · score 4.0 of 10

Retrieval-completeness improvement is partly by construction: CelloRetriever's exact-symbol reranking is evaluated with a kernel-name completeness metric, so the reported gain is in part the direct effect of the reranker's own design; the downstream porting test is less circular, and Table VII contains an arithmetic inconsistency that is a reproducibility issue rather than circularity.

  1. self definitional [Section IV.C (CelloRetriever pattern matching) and Section V.A.3 (completeness metric), Table VII]
    "CelloRetriever applies a lightweight pattern-matching pass that identifies strings within ```triple backquotes``` and then re-orders these candidates... the pattern matching layer reranks the documents with exact symbol matches at the top... we measure the fraction of correctly retrieved code blocks against a curated ground-truth list from various applications. The final score is calculated as the mean of completeness ratio across various applications"

    The completeness metric counts how many curated ground-truth kernel names are recovered in retrieved chunks. CelloRetriever's only task-specific mechanism is a reranker that moves exact symbol matches to the top. Thus the reported Base-to-CelloRetriever improvement on this metric is largely the direct output of the reranker's objective, not an independent test of retrieval quality. The claim that CelloRetriever 'consistently enhances retrieval' is to a significant degree a restatement of the reranker definition: the quantity being measured (kernel-name recovery) is the quantity being optimized (exact-symbol matching). It is not fully circular because the candidate set still comes from embedding retrieval and the reranker cannot invent absent kernels, but the retrieval-completeness result i

full rationale

The central porting-coverage claim (Section V.C, Table VIII) is independent of the circularity concern: models receive retrieved context and must generate compiling OpenMP code, so the measured coverage is a substantive LLM output, not forced by the retriever. The callgraph and chunking discussions are design-motivated rather than derived by circular argument. Self-citations to testbeds [22-25] are contextual and not load-bearing. The main circular step is the alignment between CelloRetriever's exact-symbol reranking and the kernel-name completeness metric, which makes the retrieval-completeness improvement partly definitional. Separately, there is a reproducibility problem that is not circularity: in Table VII the CUDA scores do not follow from the table's own counts under the stated 'mean of completeness ratio' definition (e.g., Lajavaness CelloRetriever implies 0.499, not 0.790; SFR-Embedding-Code-2B_R implies 0.522, not 0.359). This further weakens the quantitative support for the retrieval claim but does not change the circularity verdict. Overall score reflects a moderate, partial circularity in the retrieval evaluation, with an independent porting evaluation keeping the paper from being fully circular.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

This is an engineering evaluation paper, so the ledger captures evaluation assumptions rather than physical postulates. The system depends on hand-set retrieval and prompt parameters (top-k, callgraph depth, rerank heuristic) and on the accuracy of the authors' ground-truth kernel lists and evaluation protocol. No new physical entities are introduced.

free parameters (3)
  • Retrieval top-k (code 40, text 50)
    The numbers of chunks fed to the LLM are hand-selected; Tables VI and VII and the porting results depend on this budget. No sweep or sensitivity analysis is reported.
  • Callgraph lineage depth (two hops)
    Section IV.D fixes callers/callees to two hops without an ablation; prompt length and downstream coverage depend on this choice.
  • Exact-symbol pattern-matching rerank
    The reranking heuristic in CelloRetriever (Section IV.C) is hand-designed, and its priority over embedding scores is not parameterized or ablated.
assumptions (4)
  • domain assumption The curated kernel totals in Tables IV and VII are correct ground truth for the completeness metric.
    Used in Section V.A.3; every score is a ratio over these totals.
  • domain assumption The two-turn evaluation protocol (kernel collection then porting prompt) is a fair representation of HEP porting workflows.
    Tables VIII and IX rest on this protocol; baseline models may lack codebase access, confounding the coverage comparison.
  • domain assumption Doxygen-generated callgraphs and the two-hop summaries are complete and accurate for the HEP codebases.
    Section IV.D; incomplete or stale lineage would mislead the LLM and change porting outcomes.
  • domain assumption The authors' blinded instruction-adherence ratings are unbiased.
    Section V.C; authors scored their own anonymized model outputs with no external judges or inter-rater reliability reported.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CelloAI: Leveraging Large Language Models for HPC Software Development in High Energy Physics." pith.science (2026). https://pith.science/paper/DAVE4CPL

@misc{pith2026250816713,
  author       = {Pith},
  title        = {Pith review of: CelloAI: Leveraging Large Language Models for HPC Software Development in High Energy Physics},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DAVE4CPL}},
  note         = {Machine review of arXiv:2508.16713}
}
read the original abstract

Next-generation High Energy Physics (HEP) experiments will generate unprecedented data volumes, necessitating High Performance Computing (HPC) integration alongside traditional high-throughput computing. However, HPC adoption in HEP is hindered by the challenge of porting legacy software to heterogeneous architectures and the sparse documentation of these complex scientific codebases. We present CelloAI, a locally hosted coding assistant that leverages Large Language Models (LLMs) with retrieval-augmented generation (RAG) to support HEP code documentation and generation. This local deployment ensures data privacy, eliminates recurring costs and provides access to large context windows without external dependencies. CelloAI addresses two primary use cases, code documentation and code generation, through specialized components. For code documentation, the assistant provides: (a) Doxygen style comment generation for all functions and classes by retrieving relevant information from RAG sources (papers, posters, presentations), (b) file-level summary generation, and (c) an interactive chatbot for code comprehension queries. For code generation, CelloAI employs syntax-aware chunking strategies that preserve syntactic boundaries during embedding, improving retrieval accuracy in large codebases. The system integrates callgraph knowledge to maintain dependency awareness during code modifications and provides AI-generated suggestions for performance optimization and accurate refactoring. We evaluate CelloAI using real-world HEP applications from ATLAS, CMS, and DUNE experiments, comparing different embedding models for code retrieval effectiveness. Our results demonstrate the AI assistant's capability to enhance code understanding and support reliable code generation while maintaining the transparency and safety requirements essential for scientific computing environments.

Figures

Figures reproduced from arXiv: 2508.16713 by the authors.

Figure 1
Figure 1. FIG. 1. Categorization of an coding assistant’s tasks into AI [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. FIG. 2. CelloRetriever: Combined retrieval pipeline for code [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

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

  1. HEPTAPOD: Orchestrating High Energy Physics Workflows Towards Autonomous Agency

    hep-ph 2025-12 conditional novelty 4.0 of 10

    HEPTAPOD uses LLM agents to drive FeynRules, MadGraph, Pythia, and analysis tools through schema-validated tool calls and run-card templates, demonstrated on a leptoquark signal scan.

Reference graph

Works this paper leans on

46 extracted references · 38 canonical work pages · cited by 1 Pith paper

  1. [1]

    They do not offer options for on- premise deployment and their usage is metered by tokens and policy limits

    Proprietary Models: These foundation LLMs are the most popular closed-weight models for re- mote inference. They do not offer options for on- premise deployment and their usage is metered by tokens and policy limits. They typically get up- graded quickly as the vendors constantly upgrade the back-ends. Examples include OpenAI GPT- o3/5, Claude-Opus, Gemin...

    work page

  2. [2]

    They offer access to agentic loops to fix bugs, add tests, and run shell commands

    API-based Services: These are command-line or SaaS layers that sit on top of a proprietary model and orchestrate multi-step “agent” workflows for code generation. They offer access to agentic loops to fix bugs, add tests, and run shell commands. Their usage is also charged per token. Examples in- clude APIs from OpenAI, Gemini, Anthropic, Per- plexity AI,...

    work page

  3. [3]

    They feed local code contexts to one or more remote or local models

    AI Assistants plugged into IDE or Shell : These are lightweight clients that live inside an IDE or Linux shell. They feed local code contexts to one or more remote or local models. The choice of model is often configurable by the user. They are tightly integrated with IDE/shell (inline comple- tions, refactor, run tests) but offer the possibility of offli...

    work page

  4. [4]

    LLM-based Automated Self-correcting pipeline for Scientific codes

    Open-weight LLMs: Several organizations re- lease model checkpoints under permissive licenses, but they typically require custom workflows and computational infrastructure. Open-weight mod- els democratize research and on-premise deploy- ment. Their unique advantage is full data-privacy, offline generation, and a transparent access to large context window...

    work page

  5. [5]

    Explain the underlying al- gorithm for the function X as it relates to Y

    **Output a flat list** of those function names under the heading Table 1, one per line, along with the source file path where each appears. First, **only produce the list of BASE IMPL functions**. After you’ve confirmed the list, devise a strategy to replace each function with an equivalent PORT IMPL version considering important operations like data tran...

    work page

  6. [6]

    Retrieved code and text from the same collection

    Separate Collections for Code and Text Retrieved [top 50] Code Text FastCaloSim (CUDA) 25 25 P2R (CUDA) 42 8 Patatrack (CUDA) 50 0 WireCell (Kokkos) 22 28 WireCell (OpenMP) 32 18 TABLE V. Retrieved code and text from the same collection. To demonstrate the necessity of separate collections, we first examine retrieval behavior when the code and text share ...

    work page

  7. [7]

    par- tial routines,

    Syntax-aware Code Chunking To demonstrate the importance of boundary-aware chunking for scientific code retrieval, we compare Cel- loAI’s syntax-aware approach against conventional fixed window chunking. We analyze code fragmentation by counting incomplete function retrievals in the assembled context. Table VI quantifies how many of the first 40 code chun...

    work page

  8. [8]

    Benchmarking Embedding Models for Code and Text We evaluate CelloRetriever’s performance across four distinct embedding models that vary in specialization, release date, embedding dimensions, and total number of parameters. The selected models include two text based models (sentence-transformers/all-MiniLM-L6-v2 and Lajavaness/bilingual-embedding-large) a...

    work page 2021

Show all 46 references
  1. [9]

    For every BASE IMPL function in Table 1 rewrite the implementation in PORT IMPL

  2. [10]

    Preserve numerical results bit-wise where feasible (double precision)

  3. [11]

    Insert explicit device memory management where the BASE IMPL runtime previously handled mapping: allocate once per event batch and reuse

  4. [12]

    Use features from PORT IMPL that are known to be more efficient

  5. [13]

    performance notes

    Supply a two-sentence performance note per kernel (expected speed-up, occupancy bottlenecks). TABLE IX. Prompt for porting GPU kernels. The keywords BASE IMPL, IDENTIFIER, PORT IMPL are same as Table III. C. Interactive Coding Assistant Finally, we provide an interactive codin...

  6. [14]

    Minaee, T

    S. Minaee, T. Mikolov, N. Nikzad, M. Chenaghlu, R. Socher, X. Amatriain, and J. Gao, Large language models: A survey, arXiv preprint arXiv:2402.06196 (2024)

    2024 arXiv

  7. [15]

    X. Gu, M. Chen, Y. Lin, Y. Hu, H. Zhang, C. Wan, Z. Wei, Y. Xu, and J. Wang, On the effectiveness of large language models in domain-specific code genera- tion, ACM Transactions on Software Engineering and Methodology 34, 1 (2025)

    2025

  8. [16]

    Y. Yao, J. Duan, K. Xu, Y. Cai, Z. Sun, and Y. Zhang, A Survey on Large Language Model (LLM) Secu- rity and Privacy: The Good, The Bad, and The Ugly, High-Confidence Computing 4, 100211 (2024), arXiv:2312.02003

    2024 arXiv

  9. [17]

    Ciangottini, A

    D. Ciangottini, A. C. Forti, L. Heinrich, N. Skidmore, C. Alpigiani, M. Aly, D. Benjamin, B. Bockelman, L. Bryant, J. Catmore, et al. , Analysis facilities for the HL-LHC white paper, Computing and Software for Big Science 9, 14 (2025)

    2025

  10. [18]

    F. M. L´ opez, Dune: science and status, arXiv preprint arXiv:2502.08493 (2025)

    2025 arXiv

  11. [19]

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brock- man, et al., Evaluating large language models trained on code, arXiv preprint arXiv:2107.03374 (2021)

    2021 arXiv

  12. [20]

    Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrit- twieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago, et al. , Competition-level code generation with alphacode, Science 378, 1092 (2022)

    2022

  13. [21]

    Roziere, J

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, R. Sauvestre, T. Remez, et al., Code llama: Open foundation models for code, arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

  14. [22]

    Granite Team, Granite 3.0 language models (2024)

    I. Granite Team, Granite 3.0 language models (2024)

    2024

  15. [23]

    R. Li, L. B. Allal, Y. Zi, N. Muennighoff, D. Kocetkov, C. Mou, M. Marone, C. Akiki, J. Li, J. Chim, et al. , Starcoder: may the source be with you!, arXiv preprint arXiv:2305.06161 (2023)

    2023 arXiv

  16. [24]

    Hugging Face, https://huggingface.co/

  17. [25]

    Laban, H

    P. Laban, H. Hayashi, Y. Zhou, and J. Neville, LLMs get lost in multi-turn conversation, arXiv preprint arXiv:2505.06120 (2025)

    2025 arXiv

  18. [26]

    M. Seo, J. Baek, S. Lee, and S. J. Hwang, Paper2code: Automating code generation from scientific papers in ma- chine learning, arXiv preprint arXiv:2504.17192 (2025)

    2025

  19. [27]

    Gokdemir, C

    O. Gokdemir, C. Siebenschuh, A. Brace, A. Wells, B. Hsu, K. Hippe, P. Setty, A. Ajith, J. G. Pauloski, V. Sastry, et al. , HiPerRAG: High-performance retrieval augmented generation for scientific insights, in Proceed- ings of the Platform for Advanced Scientific Computing Conf...

    2025

  20. [28]

    K. G. Yager, Domain-specific chatbots for science using embeddings, Digital Discovery 2, 1850 (2023)

    2023

  21. [29]

    W. F. Godoy, P. Valero-Lara, K. Teranishi, P. Bal- aprakash, and J. S. Vetter, Large language model eval- uation for high-performance computing software devel- opment, Concurrency and Computation: Practice and Experience 36, 1 (2024)

    2024

  22. [30]

    L. Chen, N. K. Ahmed, A. Dutta, A. Bhattacharjee, S. Yu, Q. I. Mahmud, W. Abebe, H. Phan, A. Sarkar, B. Butler, N. Hasabnis, G. Oren, V. A. Vo, J. P. Munoz, T. L. Willke, T. Mattson, and A. Jannesari, The Landscape and Challenges of HPC Research and LLMs, (2024), arXiv:2402.02018

    2024 arXiv

  23. [31]

    Nichols, A

    D. Nichols, A. Marathe, H. Menon, T. Gamblin, and A. Bhatele, Hpc-coder: Modeling parallel programs us- ing large language models, inISC High Performance 2024 Research Paper Proceedings (39th International Confer- ence) (Prometeus GmbH, 2024) pp. 1–12

    2024

  24. [32]

    Valero-Lara, W

    P. Valero-Lara, W. F. Godoy, K. Teranishi, P. Bal- aprakash, and J. S. Vetter, ChatBLAS: The first AI- generated and portable BLAS library, in SC24-W: Work- shops of the International Conference for High Perfor- mance Computing, Networking, Storage and Analysis (IEEE, 2024) pp. 19–24

    2024

  25. [33]

    M. T. Dearing, Y. Tao, X. Wu, Z. Lan, and V. Taylor, Lassi: An LLM-based automated self-correcting pipeline for translating parallel scientific codes, in 2024 IEEE In- ternational Conference on Cluster Computing Workshops (CLUSTER Workshops) (IEEE, 2024) pp. 136–143

    2024

  26. [34]

    Godoy, P

    W. Godoy, P. Valero-Lara, K. Teranishi, P. Balaprakash, and J. Vetter, Evaluation of OpenAI codex for HPC par- allel programming models kernel generation, in Proceed- ings of the 52nd International Conference on Parallel Processing Workshops (2023) pp. 136–144

    2023

  27. [35]

    M. Atif, Z. Dong, C. Leggett, M. Lin, and V. Tsulaia, Porting ATLAS fast calorimeter simulation to GPUs with performance portable programming models, in EPJ Web of Conferences, Vol. 295 (EDP Sciences, 2024) p. 11018

    2024

  28. [36]

    M. Lin, Z. Dong, T. Wang, M. Atif, M. Battacharya, K. Knoepfel, C. Leggett, B. Viren, and H. Yu, Portable programming model exploration for LarTPC simulation in a heterogeneous computing environment: OpenMP vs. Sycl, arXiv preprint arXiv:2304.01841 (2023)

    2023 arXiv

  29. [37]

    M. Atif, M. Battacharya, P. Calafiura, T. Childers, M. Dewing, Z. Dong, O. Gutsche, S. Habib, K. Knoepfel, M. Kortelainen, et al. , Evaluating portable paralleliza- tion strategies for heterogeneous architectures in high en- ergy physics, arXiv preprint arXiv:2306.15869 (2023)

    2023 arXiv

  30. [38]

    M. Atif, P. Ding, K. H. M. Kwok, and C. Leggett, Pack- aging HEP heterogeneous mini-apps for portable bench- marking and facility evaluation on modern HPCs, arXiv preprint arXiv:2505.08933 (2025)

    2025 arXiv

  31. [39]

    Ather, S

    H. Ather, S. Berkman, G. Cerati, M. J. Kortelainen, K. H. M. Kwok, S. Lantz, S. Lee, B. Norris, M. Reid, A. Reinsvold Hall, D. Riley, A. Strelchenko, and C. Wang, Exploring code portability solutions for HEP with a particle tracking test code, Frontiers in Big Data 12 7, 10.33...

    2024

  32. [40]

    Bocci, V

    A. Bocci, V. Innocente, M. Kortelainen, F. Pantaleo, and M. Rovere, Heterogeneous reconstruction of tracks and primary vertices with the CMS pixel tracker, Frontiers in big Data 3, 601728 (2020)

    2020

  33. [41]

    Z. Dong, K. Knoepfel, M. Lin, B. Viren, and H. Yu, Evaluation of portable programming models to acceler- ate LarTPC detector simulations, in Journal of Physics: Conference Series, Vol. 2438 (IOP Publishing, 2023) p. 012036

    2023

  34. [42]

    Danial, cloc: v1.92 (2021)

    A. Danial, cloc: v1.92 (2021)

    2021

  35. [43]

    Marker, https://github.com/datalab-to/marker

  36. [44]

    ChromaDB, ChromaDB, https://www.trychroma.com/ (2025)

    2025

  37. [45]

    A. J. Yepes, Y. You, J. Milczek, S. Laverde, and R. Li, Fi- nancial report chunking for effective retrieval augmented generation, arXiv preprint arXiv:2402.05131 (2024)

    2024 arXiv

  38. [46]

    Tree-sitter, https://tree-sitter.github.io/ tree-sitter/

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.