AURA-MFP

Undergraduate Independent Research into High Performance Computing

15× Faster PV Simulations

AURA-MFP combines Monte Carlo photon transport, high-fidelity CFD, and machine learning to deliver computational efficiency without sacrificing accuracy. Our Goals: achieve an RMSE < 2.0 K at 15× speedup over traditional methods.

Multi-Fidelity Architecture

We are currently looking at the potential for a framework that intelligently switches between three fidelity levels based on physics-informed machine learning, optimizing the accuracy-cost tradeoff in real-time.

Low Fidelity (LF)

Goal: 1.0s

Poisson + Coarse CFD
25×25 grid

Medium Fidelity (MF)

Goal: 8.5s

Diffusion BTE + S₄ DOM
50×50 grid

High Fidelity (HF)

Goal: 100s

Monte Carlo + Fine CFD
100×100 grid

ML Orchestrated (SimV4)

(placeholder)

Adaptive LF/MF/HF selection
(placeholder) 25x25 grid

ML Orchestrated (SimV4)

(placeholder)

Adaptive LF/MF/HF selection
(placeholder) 50×50 grid

ML Orchestrated (SimV4)

(placeholder)

Adaptive LF/MF/HF selection
(placeholder) 100×100 grid

Future Validation Metrics

Metric	SimV1 (HF)	SimV4 (ML)	Target
Temperature RMSE [K]	NA	NA	< 2.0
Energy Error [%]	< NA	< NA	< 2.0
Wall-Clock Time [s]	NA	NA	< 10
Speedup Factor	NA	NA	> 10×

🌟 AURA-MFP Architecture Explorer

Atmosphere-Unified Radiation Assessment with Multi-Fidelity for Photovoltaics

Beta v2.0 | February 2026 | Confidential Working Document

101

Total Source Files

73

Fortran Modules

18

Python Modules

55.6K

Lines of Code

87%

Overall Progress

Layered Architecture

Click any layer to expand details. The layer numbers (4→3→2→1) follow the handbook's architecture table — see Layer 4 for why the C interpreter carries the highest number.

Layer 3 — Rust GUI  bin/aura_mfp ▼ details

egui/eframe native desktop · live CSV plots · terminal · run_config.json reader

Source Files

• gui/src/main.rs — entry point
• gui/src/app.rs — root egui app loop
• gui/src/config.rs — reads/writes run_config.json
• gui/src/process_mgr.rs — calls C layer to spawn Python
• gui/src/terminal.rs — live stdout terminal widget
• gui/src/ffi/mod.rs — FFI bindings to aura_interp.h
• gui/src/tabs/params.rs — simulation parameter forms
• gui/src/tabs/graphs.rs — real-time CSV plot renderer (notify watcher)
• gui/src/tabs/data.rs — results data table
• gui/src/tabs/help.rs — inline documentation
• gui/build.rs — links aura_interp.c at build time
• gui/Cargo.toml — eframe 0.27, notify crate

Runtime Behaviour

• User fills params tab → serialised to run_config.json
• Click Run → calls aura_spawn_python() (C Layer 4)
• Polls ring buffers from C layer every frame for live stdout
• graphs.rs watches results/live_data.csv via notify crate — re-renders plots on every FLUSH
• Terminal widget streams stdout/stderr in real time
• On completion, data tab reads all results CSVs

Why Layer 3, not Layer 4?

Rust is the user-facing shell but it depends on the C ABI (Layer 4) to safely perform OS-level process management. Layer 4 provides the stable interface; Layer 3 consumes it.

Calls Into ↓

Layer 4 — C Interpreter ABI  aura_interp.c / .h ▼ details

fork/exec process spawning · ring-buffer stdout capture · JSON config serialisation

Source Files

• c_interp/aura_interp.c — 845 LOC, C11/POSIX
• c_interp/aura_interp.h — public ABI header, consumed by Rust FFI

Key API Functions

• aura_spawn_python(config_path) — fork/exec Python subprocess
• aura_read_stdout(buf, len) — drain ring buffer
• aura_config_flush(config) — serialise run_config to JSON
• aura_process_alive(pid) — poll subprocess status
• aura_kill_process(pid) — clean shutdown/cancel

Why Does Layer 4 Have the Highest Number?

In the handbook's architecture table, Layer 4 is listed first — at the top — because it is the outermost, user-visible ABI surface. Its number reflects architectural position in the abstraction stack, not call order.

The C layer is called by Rust (Layer 3) at runtime, but it is numbered 4 because it is the stable public contract: "The stable ABI that insulates Rust from OS details." Any future GUI technology (Layer 3 replacement) would still use this same C header without changes.

Think of it like POSIX system calls — they are a lower-level primitive but form the outermost stable interface in the OS abstraction model.

↓

Layer 2 — Python Orchestration  python/run_sim.py ▼ details

Perez POA · Fresnel IAM · Faiman thermal · GP/PSO/RL surrogate management · 14,529 LOC across 18 modules

Key Modules

• run_sim.py (209) — entry point, routes modes, location presets
• pv_physics_engine.py (1,966) — Perez POA, Fresnel IAM, Faiman, SAPM, M_spectral
• simv1_wrapper.py (520) — Stage 1 pre-processing → Fortran subprocess
• simv2_wrapper.py (722) — LHS sampling, PSO swarm management
• simv3_wrapper.py (879) — GP BO, fidelity oracle calls
• simv4_wrapper.py (671) — Python Q-table, ε-greedy, SAPM surrogate
• weather_bridge.py (533) — AR(1)+Fourier weather generation
• bayesian_analysis.py (1,201) — GP posterior viz, Sobol, MCMC diagnostics
• build_manager.py (692) — build/prepare-data/test targets
• data_acquisition.py (579) — generates all data/ files
• live_plotter.py — polls results/live_data.csv every 500ms
• optical_properties.py — si_nk_table.dat reader/interpolator

Execution Flow

• Spawned by C Layer 4 via fork/exec python run_sim.py
• Reads run_config.json written by Rust GUI
• SimV1: Stage 1 physics pre-processing (POA, IAM, thermal model) → writes fortran_bc.csv → Stage 2 subprocess to Fortran
• SimV2: LHS sampling → PSO loop → repeated Fortran subprocess calls for fitness evaluation
• SimV3: GP BO → _evaluate_at_fidelity() → Fortran subprocess per acquisition point
• SimV4: ε-greedy Q-learning over SAPM surrogate + HiFi oracle Fortran calls
• All modes: streams stdout back through C ring buffer to Rust terminal

⚠️ Gap 3: simv1_wrapper.py writes M_spectral to fortran_bc.csv col 3 but Fortran never reads it (~5% photon energy error).
⚠️ Gap 1: build_manager.py --test does not invoke pytest; conftest.py missing.

↓

Layer 1 — Fortran 2018 Physics Kernel  bin/aura_mf ▼ details

BTE MC · Crank-Nicolson 3D heat · Navier-Stokes · PSO · co-Kriging BO · Q-learning RL · adjoint · 37,096 LOC, 73 modules

Module Groups (73 total, 37,096 LOC)

• src/core/ (6 modules, 2,748 LOC) — precision, constants, error, types, data, tuning
• src/solvers/ (13 modules, 7,179 LOC) — BTE MC, BTE diffusion, CN heat, ADI, NS, BC, lofi/mefi/hifi
• src/materials/ (5 modules, 2,573 LOC) — silicon, optical, thermal, material stack
• src/environment/ (9 modules, 6,642 LOC) — NREL SPA solar, Bird 1984 spectral, AR(1)+Fourier weather, climate zones
• src/optimization/ (9 modules, 5,730 LOC) — PSO (Clerc), co-Kriging GP, MCMC, adjoint, acquisition functions
• src/machine_learning/ (5 modules, 2,441 LOC) — Q-learning RL, state features, reward, decision tree
• src/utils/ (8 modules, 4,166 LOC) — I/O (FLUSH), fidelity manager, tensor surrogate, timers
• src/commands/ (5 files, 6,581 LOC) — main.f90 + sim1–4_command_module

Execution Model

• Invoked via subprocess by Python (Layer 2): ./bin/aura_mf --mode simv1 ...
• main.f90 parses all CLI flags → builds tuning_config → dispatches to sim1/2/3/4_command_module
• Writes results/live_data.csv with FLUSH every N steps → picked up by Rust graphs.rs via notify watcher
• Writes mode-specific CSVs: simv1_timeseries, pso_convergence, simv3_gp_diagnostics, simv4/rl_actions
• Self-test mode: ./bin/aura_mf --test runs 8 physics unit tests, exits 0 on pass
• SimV4: also runs its own Q-learning RL loop (separate from Python — see Gap 6)

Physics Methods

• BTE Monte Carlo with AM1.5G CDF wavelength sampling
• Crank-Nicolson θ=0.5 3D heat (unconditionally stable)
• Incompressible Navier-Stokes with Boussinesq buoyancy
• Kennedy-O'Hagan co-Kriging, EI/UCB/PI/PIAF acquisition
• Clerc-constriction PSO + CP-ALS tensor surrogate
• Lagrange multiplier adjoint sensitivity (Albany Taylor test)

Module Explorer

Dependency Analysis

🔝 Most Depended-On Modules

1. precision_module - Used by all 73 Fortran modules (must compile first)
2. types_module - Used by ~40 modules (all solver and command layers)
3. constants_module - Used by ~28 modules
4. error_module - Used by ~15 modules
5. silicon_module - Used by ~8 modules (BTE MC, optical, material)

🔄 Longest Dependency Chains

Chain 1 (deepest — SimV4 RL path):

main.f90 → sim4_command → ml_orchestrator → rl_interface → state_feature_module → types_module → precision_module

Chain 2 (SimV1 HiFi path):

main.f90 → sim1_command → hifi_solver → bte_monte_carlo → silicon_module → constants_module → precision_module

Chain 3 (Python → Fortran → Physics):

simv3_wrapper.py → run_sim.py → [subprocess] → sim3_command → bayesian_module → lofi_solver → precision_module

📊 Fortran Compilation Order (Dependency Levels)

Level 0 — Foundation (compile first):

precision_module

Level 1:

constants_module, error_module

Level 2:

types_module, timer_module, validation_module

Level 3:

data_module, tuning_module, linear_solvers, silicon_module, optical_module, thermal_module

Level 4:

material_module, optical_properties_module, solar_module, atmospheric_module, weather_module, bte_diffusion, bte_monte_carlo, boundary_conditions_module, adaptive_timestep_module, tensor_surrogate_module

Level 5:

environmental_module, climate_zone_module, weather_data_module, surface_radiation_module, air_layer_module, implicit_heat_solver_module, lofi_solver_module, adjoint_module, mcmc_sampler_module, acquisition_module, state_feature_module, reward_function_module, decision_tree_module

Level 6:

weather_driver_module, mefi_solver_module, solver_selection_module, unified_heat_solver_module, conjugate_ht, navier_stokes, pso_module, bayesian_module, adjoint_gradient_check_module, rl_interface_module, fidelity_manager_module, io_module, sim_utils_module, cleanup_utilities

Level 7–8 — Top layer (compile last):

hifi_solver_module, simv2_pso_fitness_module, optimization_module, ml_orchestrator_module, timestep_adjustment → then sim1/2/3/4_command_module → main.f90

Development Roadmap

✅ Completed (verified in v2.0 codebase)

• ✓ Core infrastructure: precision/constants/types/error/data/tuning modules (6 modules, 2,748 LOC)
• ✓ All physics solvers: BTE MC + BTE diffusion + CN heat + Navier-Stokes + ADI + BC + lofi/mefi/hifi (13 modules, 7,179 LOC)
• ✓ Full material stack: silicon + optical + thermal + material modules (5 modules, 2,573 LOC)
• ✓ Complete environment layer: NREL SPA solar, Bird 1984 spectral, atmospheric, weather, AR(1)+Fourier climate driver (9 modules, 6,642 LOC)
• ✓ All optimisation algorithms: PSO (Clerc), co-Kriging GP (Kennedy-O'Hagan), MCMC (Metropolis-Hastings), adjoint, EI/UCB/PI/PIAF acquisition (9 modules)
• ✓ RL components: state features, reward function, decision tree fallback, ml_orchestrator (4 of 5 ML modules complete)
• ✓ Rust egui GUI (bin/aura_mfp): live CSV plots, terminal, params tab, config persistence
• ✓ C interpreter bridge (aura_interp.c): fork/exec, ring-buffer stdout, JSON config
• ✓ SimV1 high-fidelity runner: BTE MC + CN heat + NS + adjoint sensitivity
• ✓ SimV2 multi-fidelity + PSO: LF/MF/HF alternating + Clerc constriction + tensor surrogate
• ✓ SimV3 Bayesian BO: co-Kriging GP + EI/UCB/PI/PIAF + --fidelity flag (Gap 2 resolved)
• ✓ Python physics engine (pv_physics_engine.py): Perez POA, Fresnel IAM, Faiman thermal, SAPM, M_spectral
• ✓ Python wrappers for SimV1/2/3/4, weather bridge, bayesian analysis, build manager
• ✓ data_acquisition.py wired to build_manager.py prepare-data target (Gap 5 resolved)
• ✓ Makefile + CMakeLists.txt build system (494 LOC, correct dependency order)
• ✓ 3 test files written (839 combined LOC) — test_pv_physics_engine, test_simv2_wrapper, test_tuning_module_consistency

⚠️ In Progress — Open Gaps

• ⚙️ Gap 1 (Critical ~16h): Test suite not wired — conftest.py, pytest.ini missing; test_weather_bridge.py in wrong directory; build_manager.py --test does not invoke pytest
• ⚙️ Gap 3 (~3h): M_spectral not propagated to Fortran — hifi_solver_module hardcodes 1.0; ~5% photon energy error under non-STC atmosphere
• ⚙️ Gap 4 (~3h): Adjoint gradient check bypassed — adjoint_gradient_check_module.f90 is complete but call site in sim1_command_module.f90 is commented out (missing forward_eval function pointer)
• ⚙️ Gap 6 (~16–32h, design decision): SimV4 dual RL architecture — Python Q-table (SAPM, 128 states, 0.1ms/eval) and Fortran Q-table (HiFi, ~50s/eval) are completely separate and never communicate
• ⚙️ T0-A (Blocker): data/ directory entirely missing — data/si_nk_table.dat absence causes hard exit at startup; all 7 required data files need to be generated

📅 Planned (2026)

• 🎯 CI/CD pipeline (GitHub Actions): make test + pytest + cargo test on push
• 🎯 fidelity_manager_module ↔ simv3_wrapper.get_scaling_factor() sync audit + regression test
• 🎯 SimV4 RL unification (Option A recommended: Python orchestrates, Fortran executes single-step oracle calls)
• 🎯 Extend Sandia PVMC validation dataset for SimV1 regression suite
• 🎯 Multi-GPU support (CUDA/OpenACC for BTE MC photon batches)
• 🎯 MPI parallelisation for large grid runs
• 🎯 NetCDF I/O for long time-series datasets
• 🎯 Experimental validation against physical PV hardware

🔬 Research Phase (2027+)

• 🔬 Physics-informed neural network surrogates replacing co-Kriging GP
• 🔬 Transfer learning across PV geometries and materials
• 🔬 Full Pareto-front multi-objective optimisation (power + degradation + cost)
• 🔬 Integration with climate models (WRF, CESM) for long-horizon yield simulation
• 🔬 Uncertainty quantification framework for publication-grade results

🎯 Development Priorities (by blocker impact)

1. Generate missing data/ files (T0-A) — Hard blocker: optical_module.f90 hard-exits without data/si_nk_table.dat at startup
2. Wire pytest test suite (Gap 1, ~16h) — Zero automated coverage currently; create conftest.py + pytest.ini; move test_weather_bridge.py
3. Propagate M_spectral to Fortran (Gap 3, ~3h) — ~5% photon energy error under non-STC conditions; add --spectral-mismatch CLI flag to main.f90
4. Re-activate adjoint gradient check (Gap 4, ~3h) — Module complete; add simv1_forward_eval() wrapper and procedure pointer in sim1_command_module
5. Unify SimV4 RL architecture (Gap 6, ~16–32h) — Design decision required; recommended: Python orchestrates, Fortran executes single-step oracle actions

Simulation Modes

SimV1: Full High-Fidelity

3D BTE Monte Carlo + Crank-Nicolson heat + Navier-Stokes + adjoint sensitivity

Status: 90% Complete

Runtime: 15–45 minutes (grid-dependent)

Use case: Highest accuracy; adjoint-guided parameter studies

Implemented:

• BTE MC (AM1.5G CDF sampling, Beer-Lambert α=1e5 m⁻¹, Fresnel at all interfaces)
• Crank-Nicolson θ=0.5 3D heat (ADI splitting, unconditionally stable)
• Navier-Stokes with Boussinesq buoyancy, CFL sub-stepping
• Lagrange multiplier adjoint: dJ/d[k_thermal, alpha, h_conv]
• Perez POA + Fresnel IAM + Faiman thermal (Python Stage 1)

Open: Gap 3 — M_spectral hardcoded 1.0 (~5% photon energy error); Gap 4 — adjoint gradient check bypassed at call site

SimV2: Multi-Fidelity + PSO

Alternates LF Beer-Lambert and HiFi BTE MC; Particle Swarm Optimization with CP-ALS surrogate

Status: 95% Complete

Runtime: ~5–10× faster than SimV1 for equivalent design search

Use case: Panel design optimisation; parameter screening

Implemented:

• Clerc constriction PSO (w=0.729, c1=c2=1.49445, theoretically stable)
• LF/MF/HF alternating fidelity with T_corrected blending
• CP-ALS tensor surrogate for fitness landscape approximation
• PSO fitness: J = w_T·RMSE + w_cost·t_cpu + w_unif·uniformity
• Latin Hypercube Sampling for initial Python-side sampling

SimV3: Bayesian Optimisation

Kennedy-O'Hagan co-Kriging GP surrogate + EI/UCB/PI/PIAF acquisition; --fidelity override resolved

Status: 90% Complete

Runtime: Optimal accuracy/cost; GP_MAX_TRAIN capped at 200 points

Use case: Global optimum search with uncertainty quantification

Implemented:

• Kennedy-O'Hagan co-Kriging: f_HF(x) = ρ·f_LF(x) + δ(x), Cholesky solve
• Acquisition: EI (Mockus 1974), UCB (κ=2), PI, PIAF (penalises T_cell > 85°C)
• MCMC (Adaptive M-H): R-hat + ESS diagnostics, posterior UQ
• --fidelity 0/1/2 CLI flag (Gap 2 resolved)
• Writes simv3_gp_diagnostics.csv and simv3_summary.csv

SimV4: RL-Orchestrated

Q-learning agent allocates compute budget across LF/HF evaluations — DUAL ARCHITECTURE UNRESOLVED

Status: 60% Complete

Runtime: Adaptive (learns optimal budget allocation policy)

Use case: Research / autonomous multi-fidelity exploration

Implemented (partial):

• State features: T gradient, rate-of-change, remaining budget, Sobol indices
• Reward: r = improvement(Pmp) - cost(action) + physics penalty (Ng 1999 shaping)
• Decision tree fallback policy (sigma_frac/R2/n_HF heuristics)
• Python: ε-greedy Q-table over SAPM surrogate (128 states, ~0.1ms/eval)
• Fortran: separate Q-table over HiFi solver (~50s/eval, different state space)

Open: Gap 6 — Two independent Q-tables that never communicate. Must unify (recommended: Python orchestrates, Fortran as single-step oracle).

⚠️ Development in Progress

This dashboard is currently under active development. Full WebSocket integration and real-time rendering are scheduled for Phase 3 of the AURA-MFP roadmap (Q2 2026).