Murillo Reproduction Plan

Status: ALL PHASES COMPLETE — 22 papers, ~700 checks, 39/39 validation suites. Exp 022 (live NPU, 32⁴ production) finished Feb 27.
Purpose: Reproduce published computational physics work from the Murillo Group (MSU) on consumer hardware, then re-execute on BarraCuda’s Pure Rust vendor-agnostic GPU compute layer
Last Updated: February 27, 2026

The Two-Phase Approach

Every reproduction study follows the same pattern:

1. Phase A - Reproduce in Python: Run the original code (Sarkas, mystic, etc.) on our hardware to validate correctness. Match published results. This proves the HPC produces correct physics and gives us a performance baseline using the traditional scientific Python stack (NumPy, Numba, SciPy).

2. Phase B - Execute on BarraCuda: Re-implement the compute-intensive kernels as WGSL shaders running through ToadStool’s BarraCuda engine. Same physics, same math, but in Pure Rust with GPU execution on any vendor - NVIDIA, AMD, Intel, whatever has a WebGPU-compatible driver. No CUDA lock-in. No Python interpreter. No Numba JIT. No C/Fortran FFI. Just Rust dispatching WGSL shaders to whatever GPU is available.

Why this matters: Scientific computing is overwhelmingly locked to Python + CUDA. Sarkas itself acknowledges this - it’s “entirely written in Python without calls to C/Fortran hence avoiding a two-language problem.” But it still depends on NumPy (C underneath), Numba (LLVM underneath), and FFTW3 (C/Fortran). BarraCuda actually solves the problem Sarkas is trying to solve: a single-language compute stack that runs on any hardware. And it does it in a compiled, memory-safe language.

The Phase A → Phase B comparison is itself a research contribution: can a Pure Rust GPU compute layer match or exceed the performance of the established Python scientific stack for real plasma physics workloads?

BarraCuda: What We Have

ToadStool’s BarraCuda submodule has evolved into a comprehensive GPU compute engine. Current inventory from the latest git pull:

Key for MD physics: pairwise_distance, cdist, sum/mean reductions, sort/searchsorted (neighbor lists), einsum (tensor contractions), matmul_fp64 (double precision forces), cumsum/prefix_sum (integration), erf/erfc (Coulomb screening functions), histc (radial distribution g(r)).

Key for surrogate learning: full neural network stack (linear, conv, attention, normalization, activation functions, optimizers including SGD/Adam/NAdam/RMSProp/AdaBound/AdaFactor/RAdam/LAMB), loss functions, graph neural networks.

Background

Professor Michael Murillo leads the Murillo Group in MSU’s Department of Computational Mathematics, Science and Engineering (CMSE). His research spans computational plasma physics (strongly coupled Coulomb systems, inertial confinement fusion, warm dense matter) and agent-based modeling (infectious disease dynamics). He is a Fellow of the American Physical Society with 80+ peer-reviewed publications and a career that began at Los Alamos National Laboratory.

He taught Applied Machine Learning (CMSE 890, Spring 2025), where a conversation about reservoir computing, echo state machines, and neuromorphic hardware led directly to the BrainChip Akida work in ToadStool. The neuromorphic benchmark datasheet was shared with him in early 2026. An in-person conversation (February 2026) confirmed mutual interest in collaboration; he is currently traveling to California for a talk at an ignition-related conference (likely ICF/NIF community, consistent with his plasma physics work).

Murillo Group resources (all open source):

• Sarkas: Pure Python molecular dynamics for dense plasmas (MIT License) - github.com/murillo-group/sarkas
• Dense Plasma Properties Database: Open repository of plasma simulation data (VACF, g(r), EOS, ionization states) - github.com/MurilloGroupMSU/Dense-Plasma-Properties-Database
• Two-Temperature Model: UCLA-MSU collaboration for plasma equilibration modeling - github.com/MurilloGroupMSU/Two-Temperature-Model (updated January 2025)
• BIM_HNC: Binary Ionic Mixture structure in modified Hypernetted Chain approximation (Fortran)
• Thomas-Fermi Multispecies Ionization: Jupyter notebook-based ionization calculations

Key publication: “Efficient learning of accurate surrogates for simulations of complex systems” - Nature Machine Intelligence, May 2024. Introduces optimizer-driven sampling for training ML surrogates of expensive simulations, demonstrated on nuclear equation-of-state models.

Reproduction Study 1: Sarkas Molecular Dynamics

What

Reproduce Sarkas plasma simulations on the basement HPC, then port the core MD compute kernels to BarraCuda for vendor-agnostic GPU execution.

Phase A: Python Reproduction (Validate Correctness)

Run Sarkas examples (Yukawa potentials, Coulomb systems, binary ionic mixtures, ultracold neutral plasmas) on the basement HPC. Validate results against the Dense Plasma Properties Database reference data. Benchmark CPU performance across architectures.

Sarkas computational pipeline (what we need to understand before porting):

1. Initialization: Particle positions/velocities from configuration
2. Force calculation: Pairwise particle interactions (Coulomb, Yukawa, screened potentials) - the hot loop
3. Long-range forces: PPPM/Ewald via FFT (uses FFTW3/pyfftw) - most compute-intensive
4. Neighbor lists: Cell-linked lists or Verlet lists (sort/search)
5. Integration: Velocity-Verlet time stepping (basic arithmetic)
6. Diagnostics: VACF, g(r), structure factors, EOS (reductions + FFT)

The Python stack for each: NumPy arrays → Numba JIT for loops → pyfftw for FFTs → SciPy for special functions.

Hardware targets:

Deliverables:

• Sarkas tutorials validated against published reference data
• CPU performance comparison: EPYC 64c vs i9-14900K vs 5800X3D (same simulation, same parameters)
• Profiling data: where does Sarkas spend time? (force calc vs FFT vs neighbor list vs integration)

Phase B: BarraCuda Port (Vendor-Agnostic GPU Physics)

Take the profiled hot paths from Phase A and implement them as WGSL shaders dispatched through BarraCuda. The goal is a Pure Rust MD engine that runs on any GPU.

Kernel mapping (Sarkas Python → BarraCuda WGSL):

Key engineering challenge: FFT. Sarkas uses FFTW3 for Particle-Particle Particle-Mesh (PPPM) long-range force decomposition. BarraCuda has NTT/INTT (number theoretic transform - for FHE), but a true complex FFT shader is needed for PPPM. This is the primary new development required.

Hardware targets (Phase B runs on GPUs):

Deliverables:

• Pure Rust MD force kernel running on GPU via WGSL
• Same physics producing identical results to Sarkas Python (bit-for-bit or within float tolerance)
• Performance comparison: Python/NumPy/Numba on 64 CPU cores vs BarraCuda on RTX 5090 vs RTX 3090 vs RX 6950 XT
• The headline result: same plasma simulation running on NVIDIA and AMD from the same shader, no CUDA, no ROCm, no vendor SDK
• NPU exploration: can Akida accelerate any subproblem (force classification, surrogate potential)?

Available Data

• Sarkas examples: Yukawa potentials, Coulomb systems, binary ionic mixtures, ultracold neutral plasmas
• Dense Plasma Properties Database: Reference VACF, g(r), EOS data for validation (14+ subdirectories)
• Two-Temperature Model: Jupyter notebooks with UCLA collaboration data

Reproduction Study 2: Surrogate Learning (Nature Machine Intelligence 2024)

What

Reproduce the optimizer-driven sampling method from “Efficient learning of accurate surrogates for simulations of complex systems” on our hardware, then train the same surrogates entirely through BarraCuda’s neural network stack.

Phase A: Python Reproduction (Validate Results)

Run the Code Ocean capsule on our hardware. Reproduce the key figures. Benchmark training on consumer GPUs vs the original compute environment.

The paper uses:

• mystic optimizer for directed sampling (constrained optimization framework)
• Standard ML training: RBF networks, neural networks
• Nuclear EOS models (from CompOSE database and published tables)

Available Data (Open Access):

Deliverables:

• Reproduction of paper’s key figures on consumer GPU hardware
• Training time comparison: RTX 5090 vs RTX 3090 (Python/PyTorch baseline)

Phase B: BarraCuda Surrogate Training (Pure Rust ML)

Re-implement the surrogate training pipeline entirely in BarraCuda. The neural network components already exist:

The optimizer-driven sampling loop itself (mystic) is CPU-side logic. The compute-intensive part - training the neural surrogate on each batch of directed samples - is what moves to BarraCuda.

Hardware targets (Phase B runs on GPUs):

Deliverables:

• Same surrogate model trained via BarraCuda producing equivalent accuracy to Python/PyTorch
• Training time comparison: PyTorch on RTX 5090 vs BarraCuda on RTX 5090 vs BarraCuda on RX 6950 XT
• The headline result: scientific ML surrogate trained entirely in Pure Rust, running on any GPU vendor, no Python, no PyTorch, no CUDA
• Cross-vendor accuracy validation: NVIDIA-trained surrogate vs AMD-trained surrogate produce identical predictions

Reproduction Study 3: Agent-Based Modeling (Infectious Disease)

What

Run Murillo Group’s agent-based influenza models on the basement HPC, then explore BarraCuda GPU-accelerated agent simulation.

Phase A: Python Reproduction (CPU Scaling)

Agent-based models are inherently parallelizable and memory-intensive. Strandgate’s 64-core EPYC with 256GB ECC is purpose-built for this.

Why this study matters beyond benchmarks:

• Agent-based modeling of infectious disease has structural similarities to the primal coordination model in ecoPrimals. Agents interact through local rules (like primals coordinating through IPC), and macro behavior emerges from micro interactions (like NUCLEUS emerging from primal composition). This is the same computational paradigm.
• The author’s microbiology training (Medical Microbiology, Virology, Molecular Pathogenesis) provides domain knowledge that most computational physicists don’t have. Understanding influenza dynamics at the cellular level can inform model validation and parameterization.

Available Data:

• Murillo Group publications on agent-based influenza modeling
• Standard epidemiological datasets for validation (CDC FluView, WHO)
• Specific code/data to be requested from Murillo Group
• Note: Agent-based model code may not be open-source. This study depends on collaboration access.

Deliverables:

• Large-scale agent simulation runs on 64-core EPYC
• CPU scaling: how does performance change from 8 → 16 → 32 → 64 cores?
• Comparison vs i9-14900K (fewer cores, higher clock)

Phase B: BarraCuda Agent Simulation (GPU-Parallel Agents)

Agent-based models map naturally to GPU compute: each agent is an independent work item, interactions are local (pairwise distance), and state updates are parallel. BarraCuda already has the primitives:

The question: can hundreds of thousands of agents be simulated per GPU dispatch, with contact networks evaluated via message_passing.wgsl? If so, BarraCuda turns ABMs from a CPU-scaling problem into a GPU-throughput problem.

Hardware targets:

Deliverables:

• GPU-accelerated agent simulation via BarraCuda
• Population scaling: how many agents can BarraCuda handle per timestep on RTX 5090 vs 64 CPU cores?
• Cross-domain analysis: structural parallels between ABM and primal coordination
• NPU exploration: can Akida’s spiking networks model agent decision-making (state transition as spike event)?

Timeline

Completed

Post-NUCLEUS (Phase A - Python Reproduction)

Post-NUCLEUS (Phase B - BarraCuda Execution)

Infrastructure Dependencies

This is a long-term, whole-ecosystem project. The reproduction studies require a working NUCLEUS deployment before execution can begin at scale.

Blocking Requirements

1. NUCLEUS stability: Tower, Node, and Nest Atomics must be reliably composing before we route data and compute across the mesh.
2. Westgate as cold data hub: NestGate must be managing Westgate’s 76TB ZFS pool via content-addressed storage. All raw data, simulation output, and datasets land on Westgate. Compute nodes pull data over the mesh.
3. 10G backbone: The copper 10G NICs are installed on North/South/East/Westgate. Switch is acquired. Cables are the remaining bottleneck. Large MD simulation output and dataset transfers need the bandwidth.
4. biomeOS coordination: Workload routing (MD to Strandgate, surrogate training to Northgate, visualization to any available gate) requires biomeOS’s Neural API to be functional.

What Can Be Done Now (Pre-NUCLEUS)

See MISE_EN_PLACE.md for the full checklist. Key items:

• Clone repos locally for review
• Download Zenodo datasets
• Install Sarkas on one gate for tutorial validation
• Read the Nature paper thoroughly
• Review Sarkas documentation and tutorials

The Bigger Picture

Sarkas solved one problem: making MD accessible by writing it in pure Python instead of C/Fortran. But it still depends on NumPy (C underneath), Numba (LLVM underneath), pyfftw (FFTW3, C/Fortran underneath), and it’s locked to CPUs.

BarraCuda solves the next problem: making GPU compute accessible by writing it in Pure Rust with WGSL shaders that run on any GPU vendor. No CUDA. No ROCm. No HIP. No OpenCL. No vendor SDK. One set of shaders, every GPU.

If we can demonstrate that real plasma physics (Sarkas-equivalent simulations) and real scientific ML (surrogate training) run correctly and competitively on BarraCuda, that’s not just a reproduction study - it’s a demonstration that scientific computing doesn’t have to be locked to interpretive languages or proprietary GPU stacks.

This connects directly to the ecoPrimals thesis: sovereignty through constraint. BarraCuda constrained itself to WGSL/WebGPU (portable, vendor-neutral) and emerged with 226+ shaders that can run plasma physics on an AMD card or an NVIDIA card from the same binary. The same pattern that produced Taq polymerase from a hot spring produces universal GPU compute from a portability constraint.

Notes

• Professor Murillo returned from the ignition conference (California, week of Feb 10).
• Coffee meeting scheduled: Tuesday March 3, 2026. Check-in email going out Feb 27.
• hotSpring repo link shared previously. Technical summary prepared: hotSpring/whitePaper/TECHNICAL_SUMMARY_FEB2026.md — standalone, physics-focused, no ecoPrimals language. Suitable for sharing with Murillo or Bazavov.
• The FFT gap is closed (ToadStool Fft1DF64/Fft3DF64, roundtrip 1e-10). See BarraCuda Scientific Compute Gaps.
• DF64 is a novel discovery with publication potential: “Double-float arithmetic for lattice gauge theory on consumer GPU” (Computer Physics Communications or Physical Review E).
• NPU adaptive steering is a novel methodology with publication potential: “Neuromorphic co-processing for Monte Carlo simulation” (Neuromorphic Computing and Engineering).
• The hotSpring repo (github.com/syntheticChemistry/hotSpring) is public and AGPL-3.0 licensed.
• Exp 022 completed Feb 27, 2026: First production lattice QCD run with live neuromorphic hardware (AKD1000 via PCIe). ESN weights exported for cross-run learning. 10 NPU-steered β points, 5,900 measurements, 63% thermalization savings.
• WDM extension (Tier 4) is the natural next step — Murillo’s roadmap paper (arXiv:2505.02494) identifies computational accessibility as the bottleneck. hotSpring already has the primitives (MD, Green-Kubo, FFT, DF64). The gap is real physics: partial ionization, quantum corrections.

See also:

• hotSpring Results — thesis chapter on reproduction outcomes
• Faculty Spring Profiles — Murillo Group engagement context
• hotSpring Validation Summary — live validation status and binaries