The research, published in Frontiers in High Performance Computing, draws an unusual analogy between the world of science and the world of business. Large enterprises long ago abandoned the idea that every application should talk directly to every other application through shared databases. Instead, they adopted event-driven architectures, in which a distributed streaming service such as Apache Kafka acts as a single source of truth. Applications publish immutable events to topics, other applications subscribe to those topics, and the streaming service decouples producers from consumers in both time and space. A faulty application simply restarts and picks up where it left off in the stream. The authors describe such event stores as a database turned inside out, and they pose a provocative question: what would a parallel file system turned inside out look like?

The motivation is rooted in the changing character of HPC workloads. Scientific workflows increasingly integrate multimodal data streams from computations, simulations, and instruments, from small telemetry events to gigabyte-scale scientific datasets. Provenance capture, telemetry, and anomaly detection generate background I/O traffic from many sources. Coupling supercomputers with light sources, telescope arrays, and gravitational wave detectors introduces data-management challenges that neither parallel file systems nor tightly coupled in situ processing handle well. Parallel file systems suffer from a POSIX consistency model that forces locking and synchronization, serialization overheads, and the infamous computation-and-I/O gap that bottlenecks performance at scale. In situ approaches bypass the file system for speed but sacrifice persistence, fault tolerance, and impedance matching between components that produce data at different rates.

Mofka, built on the Mochi suite of HPC data-service components, aims to occupy the middle ground. Its design goals read like a checklist of supercomputer peculiarities: efficient use of high-performance networks such as InfiniBand, Omni-Path, and HPE Slingshot, including native RDMA support that moves data directly from application memory to storage with as few copies as possible; efficient threading on massively multicore nodes, mixing hardware threads with user-level co-routines; handling of event payloads ranging from kilobytes to multiple gigabytes; support for scientific data formats that lets consumers specify interest in only sections of multidimensional arrays before transfer; and high modularity so the network stack, scheduling policies, and storage backends can be fine-tuned per use case. Polaris at Argonne features two network interface cards per node, and Aurora features eight, and Mofka’s Plumber component automatically assigns server processes to their closest NIC to maximize network resources.

The architecture’s most distinctive decision is the division of every event into two parts. A small, structured metadata part, interpretable by both clients and servers, travels through an optimized control path: it is validated by a user-provided validator, routed by a partition selector, and serialized into batches sent via RDMA to a log provider. A potentially much larger data part, opaque to the server, travels by RDMA directly to and from user-provided memory and its final storage destination, bypassing intermediate buffers entirely. On the consumer side, a data selector decides which portion of the data to pull, all, none, or an arbitrary subset, before any transfer occurs, and a data broker tells the client library where to place it. In a weather application, one consumer might select a two-dimensional slice at ground level for a color map while another pulls the full three-dimensional chunk for volume rendering, from the same topic.

Benchmarks on Argonne’s Improv and Polaris supercomputers and Oak Ridge’s Frontier exascale machine compared Mofka against Kafka and Redpanda, which speak the same protocol. The results were revealing, and sometimes humbling. In single producer-consumer tests, Mofka outperformed both rivals in almost all scenarios on Improv, while on Polaris Redpanda performed better in production of events of one kilobyte and up. When one server served increasing numbers of client nodes, Mofka throughput doubled as server nodes doubled on Improv, while Kafka and Redpanda stagnated, apparently capped by their reliance on TCP at roughly one gigabyte per second. When events carried one kilobyte of metadata plus ten megabytes of data, using the separated data path with in-memory storage pushed production to 6,257 megabytes per second and consumption to 8,529 megabytes per second, roughly six times the metadata-only path. The team also learned that swapping glibc’s allocator for jemalloc more than doubled consumer throughput in some configurations, and that Kafka and Redpanda frequently timed out and failed to complete benchmarks as concurrency increased, making them difficult to use on HPC systems without an experienced administrator.

Three real-world applications demonstrated the framework’s utility. TekApp, a streaming tomographic reconstruction mini-app derived from the Trace code, reconstructs three-dimensional volumes from X-ray projections at the Advanced Photon Source. Its original ZeroMQ-based configuration required components to run simultaneously with frequent synchronization; with Mofka, the workflow became loosely coupled and fault tolerant, with per-event overhead reduced by at least twelve times across components and up to five hundred times better performance for large twenty-five-megabyte events between the reconstruction and denoising stages. MOFA, an AI-driven discovery pipeline for metal-organic frameworks for carbon capture, links a diffusion-based generative model with a ladder of physics simulations in a closed learning loop; replacing its single Redis instance with distributed Mofka topics eliminated a single point of failure, although experiments showed that Mofka currently suffers latency in latency-bound, small-message scenarios when Python’s threading limitations force blocking calls. Flowcept, a provenance and performance instrumentation tool, streams profiling data from a multinode, multi-GPU large language model hyperparameter search on Polaris; Mofka’s overhead ranged from 0.22 to 1.33 percent of workflow runtime, against 6.31 to 26.09 percent for Kafka and up to 36.96 percent for Redis, with Mofka spending just 7.30 seconds blocking on communication during a heavyweight profiling run while Kafka blocked for 36.19 seconds and Redis for 265.81 seconds.

The authors are candid about the lessons learned. Batch size matters enormously, and larger is not always better: for the SIRT component producing twenty-five-megabyte events, increasing batch size actually increased overhead because batching delays transfers whose performance is driven by the data path rather than the number of RPCs. More partitions equal more parallelism, even from a single process to a single server. Python bindings carry significant overhead, with object conversions and the Global Interpreter Lock often costing more than event serialization or transfer. Threading strategies, process placement, and oversubscription frequently mattered more than which streaming system was used at all. In one experiment on Polaris, oversubscribing thirty-two cores with sixteen processes and background threads dramatically changed results, and the use of an Argobots user-level thread combined with librdkafka’s POSIX threads caused interference that made Mofka’s API detrimental to consumption performance.

The comparison the authors ultimately draw is with file systems rather than messaging systems: comparing Mofka with Kafka, they write, is like comparing Lustre with NFS. The former is HPC-ready, uses high-performance networks, and offers the right features for scientific I/O; the latter is useful but will always rely on Ethernet and carry performance limitations. Kafka’s development started in 2011 and Redpanda’s in 2019, each backed by a company and hardened by enterprise use, yet a prototype built with limited resources in a short time outperforms them in many HPC scenarios, which the team sees as an encouraging first step justifying further investment. Future work will add data replication using an RDMA-enabled implementation of the RAFT protocol, authentication and access control to turn Mofka into a multiuser service, and bridges to technologies such as Octopus to form a scientific event fabric spanning instruments, supercomputers, edge devices, and the cloud. If they succeed, the humble event stream, the backbone of internet commerce, may become the backbone of computational science as well.

Subject of Research: Toward a persistent event-streaming system for high-performance computing applications

Article Title: Toward a persistent event-streaming system for high-performance computing applications

Article References: Dorier, M., Gueroudji, A., Hayot-Sasson, V., Nguyen, H. D., Ockerman, S., Souza, R., Bicer, T., Pan, H., Carns, P., Chard, K., Chard, R., Gonthier, M., Huerta, E., Lenard, B., Nicolae, B., Patel, P., Wozniak, J., Foster, I., Rao, N. S., & Ross, R. B. (2025). Toward a persistent event-streaming system for high-performance computing applications. Frontiers in High Performance Computing, 3, Article 1638203. https://doi.org/10.3389/fhpcp.2025.1638203

Image Credits: AI Generated

DOI: 10.3389/fhpcp.2025.1638203

Keywords: Mofka, event streaming, high-performance computing, RDMA, Kafka, Redpanda, Mochi, supercomputers, scientific workflows, data management, exascale, provenance

The reproducibility argument deserves particular attention. In computational science, reproducibility is often discussed in terms of software versions, container images, and data provenance, but the environment in which an experiment runs—the topology of machines, the network paths between them, the placement of services—can be just as consequential. Two researchers running the same workflow code on differently configured infrastructure may observe different performance characteristics, different failure patterns, and even different scientific outcomes. By capturing infrastructure provisioning and experiment configuration in declarative specifications, Kiso extends the reproducibility envelope downward through the software stack, so that the entire experimental context, from bare metal allocation to workflow execution, can be described, shared, and re-instantiated. This aligns with a growing movement in the computational sciences to treat experimental infrastructure as a first-class artifact of research, subject to the same standards of documentation and version control as analysis code.

The framework’s reliance on EnOSlib reflects a pragmatic design philosophy. Rather than reimplementing low-level interactions with each testbed, Kiso builds on a library that already abstracts over multiple experimental platforms, allowing it to target Chameleon’s cloud resources, edge devices, and other backends through a common interface. This layering has practical consequences for researchers: a change of testbed does not necessarily require a rewrite of the experiment description, and new platforms can be incorporated as the underlying library expands its coverage. It also insulates the framework from the churn inherent in research infrastructure, where hardware is refreshed, services are migrated, and interfaces evolve over timescales much shorter than the typical research project.

The choice of HTCondor as the coordination substrate for Pegasus workflows is similarly consequential. Traditional HPC schedulers assume a shared filesystem and relatively homogeneous, tightly coupled resources—assumptions that fail on the edge-to-cloud continuum, where edge nodes may be intermittently connected, bandwidth-limited, and geographically dispersed. HTCondor’s architecture, developed over decades of distributed high-throughput computing research, was designed for exactly this kind of loosely coupled federation: workers can join and leave, network partitions can be tolerated, and the matchmaking process can place jobs on whatever resources are available without requiring a global filesystem. For edge-to-cloud experiments, this means that a sensor node in the field and a virtual machine in a cloud data center can participate in the same workflow execution without artificial synchronization barriers, and that transient outages at the edge do not necessarily abort the entire experiment.

The extension toward agentic experiments represents a natural but nontrivial evolution. Multi-agent systems, particularly those built on large language models and other reasoning components, impose demands that differ from traditional data-intensive workflows. Agents may need to communicate in patterns that are not known at planning time, adapt their behavior based on intermediate results, and negotiate access to shared resources in real time. The framework’s declarative provisioning and extensible task abstractions provide a substrate for these patterns: agents can be deployed as containerized services on provisioned resources, communication channels can be established across sites during configuration, and monitoring and output collection can capture the traces of agent interaction that researchers need for analysis. The COLMENA work cited in the article illustrates this direction, demonstrating how agent-based applications can be deployed and studied on distributed infrastructure using the same foundations that support conventional workflows.

This convergence of workflow management and agent-based computing has implications for complex systems science more broadly. Agent-based modeling has long been a staple of complexity research, but such models have typically been simulated on single machines or clusters under controlled conditions. The emerging generation of agentic frameworks—in which autonomous agents powered by machine learning models plan, negotiate, and adapt—raises the possibility of studying self-organizing behavior in real cyber-physical systems rather than purely in simulation. Such studies require exactly the capabilities Kiso provides: consistent resource provisioning across heterogeneous sites, reliable cross-site communication, systematic collection of results and telemetry, and the ability to repeat an experimental configuration under controlled variation. In this sense, the framework can be read as infrastructure for a new class of complex systems experiments, one in which the adaptive behavior of interest is embodied in deployed software agents rather than abstract simulation entities.

The edge-to-cloud continuum itself is worth examining more closely. Edge devices—IoT sensors, embedded computers, vehicles, environmental monitoring stations—generate data at the point of observation, and processing that data locally can preserve privacy, reduce bandwidth demands, and enable low-latency responses. Yet edge devices are constrained in compute, memory, and power, so computationally intensive analysis must be offloaded to cloud resources. The scientific questions that arise from this architecture—how to schedule tasks across the continuum, how to tolerate intermittent connectivity, how to balance latency against throughput—are precisely the questions that require realistic testbed experimentation rather than pure simulation. Simulation remains valuable for exploring parameter spaces cheaply, but it inevitably abstracts away the network dynamics, hardware variability, and environmental noise that dominate real deployments. Testbed-based experiments complement simulation by exposing solutions to these realities, and frameworks like Kiso lower the barrier to conducting such experiments systematically.

The human dimension of this problem should not be underestimated. Research groups are typically composed of domain scientists—biologists, geoscientists, ecologists—whose expertise lies in their science rather than in systems administration. When an experiment requires provisioning virtual machines, configuring network routes, installing software stacks, and debugging connectivity across sites, the systems burden can consume weeks of effort and introduce silent errors that compromise results. Historically, this burden has been absorbed either by dedicated research software engineers, who are a scarce resource, or by domain scientists improvising solutions of variable quality. By automating provisioning and configuration, Kiso redistributes this burden: the expertise needed to set up a distributed experiment is encoded once in the framework and its declarative specifications, then reused by every researcher who adopts it. This democratization of distributed experimentation may prove as important as any technical capability, since it determines who can participate in edge-to-cloud research at all.

The modular architecture of the framework also positions it well for future evolution. Because infrastructure provisioning, deployment, experiment execution, and monitoring are separated into distinct layers, each can improve independently. New testbeds can be added as provisioning backends; new workflow systems can be supported alongside Pegasus; new agent frameworks can be integrated as task types; new monitoring approaches can be adopted as instrumentation needs grow. This modularity reflects lessons learned from earlier generations of scientific software, where monolithic designs often struggled to keep pace with changing infrastructure landscapes. It also means that Kiso can serve as a stable foundation while the agentic AI ecosystem, which is evolving extremely rapidly, continues to shift beneath it.

Looking forward, several research directions follow naturally from this work. One is the systematic study of fault tolerance and adaptation in edge-to-cloud workflows, where the framework’s ability to provision controlled topologies makes it possible to inject failures and observe system responses under repeatable conditions. Another is the empirical investigation of multi-agent coordination at scale, where questions about communication overhead, emergent behavior, and resource contention can be addressed with real deployments rather than idealized models. A third is the integration of measurement and telemetry into the experimental loop, so that the monitoring capabilities built into the framework become not just a convenience but a scientific instrument in their own right. In each of these areas, the combination of declarative provisioning, containerized services, and workflow-level orchestration offers a methodological template: experiments as reproducible, versioned, and shareable artifacts spanning the full edge-to-cloud continuum.

Ultimately, the contribution of Kiso lies less in any single technical mechanism than in the unification it achieves. Provisioning, configuration, execution, and monitoring have each been addressed by existing tools, but the gap between them is where much of the friction of distributed experimentation has lived. By closing that gap within a single coherent framework, and by extending it toward the emerging demands of agentic computing, the work offers the complex systems community a foundation on which the next generation of adaptive, self-organizing, and geographically distributed experiments can be built—and, crucially, repeated.

Subject of Research: Kiso: a foundation for complex, agentic, and reproducible experiments

Article Title: Kiso: a foundation for complex, agentic, and reproducible experiments

Article References: Mayani, R., Vahi, K., Rynge, M., Thareja, K., Casas-Moreno, X., Jin, H., Mandal, A., Lordan, F., Raghavan, K., Badia, R. M., & Deelman, E. (2026). Kiso: a foundation for complex, agentic, and reproducible experiments. Frontiers in Complex Systems, 4, Article 1800335. https://doi.org/10.3389/fcpxs.2026.1800335

Image Credits: AI Generated

DOI: 10.3389/fcpxs.2026.1800335

Keywords: Kiso, edge-to-cloud computing, scientific workflows, reproducibility, multi-agent systems, HTCondor, Pegasus WMS, FABRIC testbed, Chameleon Cloud, COLMENA, distributed computing, cyber-physical systems

The motivation comes from a shift in how artificial intelligence is used in high-energy physics. Machine learning has long been embedded in the field, powering event reconstruction, jet tagging, anomaly detection, fast simulation and statistical inference. More recently, however, agents built on LLMs have begun to move beyond isolated inference tasks toward the orchestration of entire scientific workflows, including code generation, tool invocation, structured context management and human-in-the-loop analysis. Parameter-space exploration, the authors argue, is a natural next target, because a substantial part of the work lies not in choosing a sampling algorithm but in assembling the surrounding computational machinery: connecting external physics programs, modifying input cards point by point, reading output observables, defining likelihoods and constraints, and storing the whole setup alongside its results.

EasyScan_HEP 2 takes a distinctive architectural stance. Rather than improving the scan engine itself, the framework lets AI assist the configuration layer. The scientific content of any scan remains encoded in an explicit .ini configuration file that specifies the scan method, input parameters, external programs, input-output mappings, constraints, plots and result folder. An LLM agent can generate or revise this file from a natural-language request, but the file itself remains the single source of truth, executable by the same backend that powered the original EasyScan_HEP. This design means the AI never silently changes the physics; it only drafts a document that the user can inspect before anything runs.

Several machine-readable interfaces make this workflow practical. The package is now an installable Python tool with a command available from any working directory. A dry-run configuration checker parses the .ini file and reports errors, warnings and informational messages without launching any scan points, catching common failure modes such as unsupported scan methods, wrong paths, missing likelihood constraints, duplicated variable names, invalid numerical ranges or plot variables that no input or output block defines. Crucially, the checker can return machine-readable output, allowing an agent to repair its own mistakes iteratively. The authors are careful to note that the checker verifies only syntactic and operational consistency, not whether the underlying physics model is correct.

The run interface has also been made agent-friendly. An explicit overwrite policy replaces interactive prompts, and a structured JSON report records whether the run succeeded, the return code, the command used, the launch directory, the configuration path, the log path, the result directory and the overwrite action. A separate result-reader command summarizes an existing result directory without rerunning the scan, counting rows, listing generated plots and identifying a representative best row by minimizing chi-squared or minus-two-log-likelihood columns where available. Because this summary comes from a deterministic reader rather than the model’s interpretation of terminal output, users do not have to trust the agent’s reading of raw logs.

To quantify the benefit, the team ran a controlled evaluation with 11 benchmark tasks, each repeated three times under three conditions, giving 99 isolated runs using the gpt-5.6-terra model with medium reasoning effort in the same Codex environment. Condition S used EasyScan_HEP with its documentation and the registered agent skill; condition D used the package without the skill; and condition M had the model implement each scan directly without EasyScan_HEP. Both EasyScan_HEP conditions completed all 33 runs end to end, while the direct-implementation condition completed 31 of 33 and required 77 task executions, including 27 failed launches. The median number of code lines requiring user review was roughly five times larger without the framework.

The skill itself delivered a modest but measurable efficiency gain: first-execution success rose from 22 to 25 out of 30 executable runs, and total task executions fell from 46 to 40. The authors emphasize that the benchmark does not capture broader functions of the skill, such as organizing an end-to-end workflow, guiding software setup, and converting missing information in a user prompt into explicit follow-up questions. That conservative behavior is deliberate: if a user does not specify the location of an external program, the skill asks for the path rather than searching the file system and risking a wrong choice among multiple installed versions, since such details must be checked by the user in any case.

The modular design also made it straightforward to add three new scan methods through an LLM-agent-guided workflow. BESTFIT performs differential-evolution minimization of the configured chi-squared via SciPy, aimed at quickly locating a good-fit point. EMCEE adds ensemble Markov-chain Monte Carlo sampling with a configurable number of walkers, writing a flattened chain file for post-processing. DYNESTY brings Python-based nested sampling, storing log-likelihoods, log-weights and evidence-related quantities without requiring the native MultiNest libraries. Because a new method only needs to decide how points are proposed in parameter space, while the common workflow handles priors, external programs, constraints and plotting, the extension route has been encoded directly into the agent skill.

To demonstrate the framework on real physics, the authors scanned the Z2-symmetric real singlet scalar extension of the Standard Model, a minimal Higgs-portal model in which a new stable scalar can serve as a dark matter candidate. A two-dimensional grid scan over the singlet mass and portal coupling, with the singlet self-coupling fixed, chained together micrOMEGAs 7.1 for the relic dark matter density and PhaseTracer 2 for the electroweak phase transition, including an explicit convention conversion in which the portal coupling passed to PhaseTracer differs by a factor of two. The same scan could be prepared three equivalent ways: by writing the configuration file directly, through the agent skill from a natural-language prompt, or via a local single-user Web interface that loads, edits, checks and runs the same files. A follow-up plot of the transition strength and relic-density contours was produced by simply asking the agent to post-process the saved result table.

The broader significance is that EasyScan_HEP 2 offers a template for how AI agents can enter computationally intensive science without eroding scientific accountability. The agent drafts and repairs configurations, but the checker validates them, the Web interface exposes them, the runner records exactly how they were executed, and the result reader summarizes outputs deterministically. Generated configurations must still be inspected by the user, and no agent replaces physics validation. As LLM-agent workflows mature across the field, from collider analyses to dark-matter phenomenology, this configuration-centered approach, keeping every calculation tied to an explicit, checkable scan description, may prove to be the model that lets physicists embrace autonomous assistants while keeping the final word firmly in human hands.

Subject of Research: LLM-agent-assisted parameter-scan workflows for high-energy physics phenomenology

Article Title: EasyScan_HEP 2: LLM-agent parameter-scan workflows in high energy physics

Article References: Xiao, Y., Yue, Y., & Zhang, Y. (2026). EasyScan_HEP 2: LLM-agent parameter-scan workflows in high energy physics. The European Physical Journal C, 86(9), Article 1101. https://doi.org/10.1140/epjc/s10052-026-16358-9

Image Credits: AI Generated

DOI: 10.1140/epjc/s10052-026-16358-9

Keywords: large language models, AI agents, high-energy physics, parameter scans, EasyScan_HEP, beyond the Standard Model, dark matter, electroweak phase transition, scientific workflows, reproducibility, Markov-chain Monte Carlo, nested sampling