AI-Orchestrated EM Simulation
NASA PEC Almond Benchmark Results
A complete, published RF simulation benchmark executed end-to-end from a single natural language prompt. 45 minutes. No manual simulation setup.
1. Executive Summary
A single natural language prompt initiated and completed a full execution of the NASA PEC Almond monostatic RCS benchmark—Problem IIIA from the UT Austin Computational Electromagnetics Benchmark Suite. The pipeline ran end-to-end in approximately 45 minutes with no manual simulation setup: mesh generation, solver execution across eight configurations, post-processing, RMS error computation, comparison plotting, and results presentation were all orchestrated automatically.
Two distinct capabilities made this possible. First, Nullspace EM itself: a full-wave Method of Moments solver with proprietary Fast Direct Compression that ran all eight configurations—including the largest case at 37,502 unknowns—on a standard laptop (8 CPU cores, 2.2 GHz, 32 GB RAM). Solver execution accounted for roughly 35 of the 45 minutes. Second, an AI coding assistant that orchestrated the surrounding workflow: script generation, run management, data extraction, error computation, plotting, and report assembly—roughly 10 minutes of pipeline time that would otherwise have fallen to an engineer.
The simulation results, produced by the Nullspace EM solver suite, fall within the ±1 dB measurement uncertainty band reported by UT Austin, placing Nullspace EM squarely within accepted reference accuracy. No surrogate models or learned approximations are involved—every RCS value in this brief is a direct full-wave solution.
Two solver configurations were tested: Dense (direct Method of Moments with full impedance matrix assembly) and Compress (Fast Direct Compression Solver). Both produced virtually identical RCS results, confirming the numerical fidelity of the proprietary compression algorithm. At the highest frequency (10.25 GHz, 37,502 unknowns), the Compress solver delivered a 3.5× speedup and 75% reduction in peak RAM usage relative to the Dense solver.
This brief presents the benchmark definition, the automated workflow, the quantitative results, and the product architecture that made AI-driven orchestration possible.
2. The Benchmark
The NASA PEC Almond (Problem IIIA) is drawn from the UT Austin Computational Electromagnetics Benchmark Suite, a publicly available collection of canonical EM scattering problems with calibrated measurement data and reference simulation results. The benchmark suite is widely used in the CEM community to validate solver accuracy against traceable, independently measured data.
Geometry
The target is a perfectly electrically conducting (PEC) almond-shaped body with a characteristic dimension d = 9.936 inches. The almond geometry produces a non-trivial RCS pattern that exercises specular, diffraction, and surface wave mechanisms, making it a discriminating test of solver accuracy across a range of electrical sizes.
Frequencies
The benchmark specifies four frequencies that span a range of electrical sizes relative to the geometry: 3.5 GHz (fx1), 5.125 GHz (fx2), 7.0 GHz (fx3), and 10.25 GHz (fx4). At the highest frequency, the almond is approximately 8.6 wavelengths long, producing a moderately sized scattering problem.
Simulation Parameters
All simulations used a mesh density of λ/20 (twenty elements per wavelength), Quad9 (Q9) curvilinear surface elements, and basis order M = 1. The monostatic RCS was computed at broadside incidence (θ = 90°) over an azimuthal sweep of φ = 0° to 180° in 0.5° increments (361 observation points). Both VV (θθ) and HH (φφ) polarizations were computed at each frequency.
Solver Configurations
Two solver configurations were run at each frequency and polarization. Dense uses direct Method of Moments with full impedance matrix assembly and direct factorization—the standard reference approach for MoM solvers. Compress uses Fast Direct Compression Solver–accelerated MoM, which compresses the impedance matrix into low-rank blocks to reduce memory and computation. The Dense solver serves as the baseline for verifying that the compression algorithm introduces no meaningful numerical error.
The combination of four frequencies, two polarizations, and two solver configurations produced eight distinct simulation runs, each compared against the UT Austin calibrated measurement data.
3. What the AI Orchestrated
The entire benchmark study was initiated by a single natural language prompt that specified the problem definition, frequencies, mesh parameters, solver configurations, and desired outputs. An AI coding assistant read the prompt, generated the necessary simulation scripts, and executed the full pipeline without manual intervention at any step. A human engineer directed the process and reviewed the outputs; the AI handled the implementation.
The division of labour matters. Of the ~45 minutes end-to-end, roughly 35 were solver execution time—Nullspace EM running full-wave MoM simulations on the benchmark geometry. The AI did not approximate, predict, or shortcut any of that physics. The remaining ~10 minutes—script generation, meshing, post-processing, plotting, presentation assembly—were handled by the AI. This distinction separates the workflow described here from physics-constrained neural surrogates that have recently appeared in EM research, where a trained network replaces the full-wave solve itself. The results in this brief are all direct full-wave solutions.
Pipeline Steps
The automated pipeline consisted of six sequential stages:
Step 1: Script Generation (~2 min). The AI generated Nullspace EM input scripts for all four frequencies and both solver configurations, producing the mesh control files and solver input decks needed for each run.
Step 2: Meshing (~3 min). The Nullspace Prep mesh generator created λ/20 Quad9 surface meshes for each frequency. Mesh sizes ranged from 2,148 elements (4,296 unknowns) at 3.5 GHz to 18,751 elements (37,502 unknowns) at 10.25 GHz.
Step 3: Dense Simulations (~25 min). The direct MoM solver (Nullspace EM – Dense) was executed at all four benchmark frequencies for both VV and HH polarizations. The 10.25 GHz case dominated runtime at 22.4 minutes, requiring 11.0 GB of RAM for the full impedance matrix.
Step 4: Compress Simulations (~10 min). The Fast Direct Compression Solver was executed at all four frequencies and both polarizations. At 10.25 GHz, runtime dropped to 6.4 minutes with 2.76 GB of RAM—a 3.5× speedup and 75% memory reduction.
Step 5: Post-Processing (~3 min). Python extracted monostatic RCS data from each simulation. RMS error in dB was computed against UT Austin calibrated measurements for every frequency, polarization, and solver combination.
Step 6: Plotting and Presentation (~2 min). Comparison plots were generated using Python and matplotlib, overlaying Nullspace EM results against UT Austin measurements and reference simulations. A branded PowerPoint presentation was assembled programmatically with python-pptx.
Total pipeline duration was approximately 45 minutes end-to-end. The human engineer's role was to write the initial prompt, specify the benchmark parameters, and review the final outputs. All intermediate steps—script generation, mesh creation, solver execution, data extraction, error computation, and visualization—were handled by the AI orchestration layer.
4. Results
Performance Metrics
The following table summarizes computational performance for each solver configuration across the four benchmark frequencies. All runs were executed on a standard laptop (8 CPU cores @ 2.2 GHz, 32 GB RAM).
Key Findings
Solver equivalence. Dense and Compress produce virtually identical RCS results at all frequencies. The compression algorithm preserves full numerical accuracy while reducing computational cost.
Compress scaling advantage. The performance benefit of the compression algorithm grows with problem size. At 3.5 GHz (4,296 unknowns), the two solvers perform comparably. At 10.25 GHz (37,502 unknowns), Compress delivers a 3.5× speedup (6.4 min vs. 22.4 min) and reduces peak RAM from 11.0 GB to 2.76 GB—a 75% reduction.
Measurement-grade accuracy. All simulation results fall within or near the ±1 dB measurement uncertainty band reported by UT Austin.
Laptop-scale execution. The entire benchmark—including the largest case at 37,502 unknowns—executed on a standard laptop with 8 CPU cores and 32 GB of RAM. No workstation, cluster, or GPU was required.
5. Why This Is Possible with Nullspace
The 45-minute benchmark in this brief rests on two independent Nullspace capabilities. The solver produced the physics; the AI orchestrated the workflow. Each is a distinct piece of technology, and each is a distinct reason this workflow is hard to replicate with legacy tools.
A solver that runs on a laptop
Every RCS value in this brief was computed by Nullspace EM, a full-wave Method of Moments solver with a proprietary Fast Direct Compression algorithm. All eight simulation runs—including the largest case at 37,502 unknowns—executed on a standard laptop with 8 cores at 2.2 GHz and 32 GB of RAM. No workstation, no cluster, no GPU.
The Compress solver consumed 2.76 GB of peak RAM at 37,502 unknowns and completed that run in 6.4 minutes. The Dense solver, assembling the full impedance matrix without compression, consumed 11.0 GB and completed in 22.4 minutes on the same laptop. Both produced numerically equivalent results within the ±1 dB measurement uncertainty band. The compression algorithm is the reason the solver can fit problems of this class into laptop-scale hardware; the MoM foundation is the reason the results remain full-wave accurate against calibrated measurement.
This solver performance is independent of the AI workflow. An engineer running the same problem manually—setting up the mesh, configuring the solver, executing the runs—would see the same 6.4-minute 10.25 GHz runtime and the same 2.76 GB peak RAM. The AI does not make the solver faster. Nullspace's solver architecture does.
An AI-native workflow layer
The remaining ~10 minutes of the pipeline—script generation, mesh file creation, post-processing, error computation, plotting, and presentation assembly—were handled end-to-end by an AI coding assistant driving Nullspace EM through its Python API. This is the orchestration layer, and it is only possible because of how Nullspace is built.
Nullspace EM exposes its full simulation workflow—geometry import, mesh generation, solver configuration, execution, and post-processing—through a native Python API. There is no proprietary scripting language to learn, no middleware layer to bridge, and no GUI-dependent workflow to automate around. When an AI coding assistant generates a simulation script, it writes standard Python. When it reads a project file, it reads a Python data structure. When it configures a parametric sweep, it writes a Python loop.
This matters because legacy EM simulation tools were built decades before AI-assisted workflows existed. Their automation interfaces—proprietary scripting languages, COM/ActiveX APIs, macro recorders—were designed for human programmers writing manual automation. Retrofitting these interfaces for AI consumption requires wrappers, adapters, and translation layers that introduce friction, reduce reliability, and limit what the AI can inspect and control.
Nullspace also provides domain-specific training materials and configuration rules that guide the AI's technical decisions: mesh density selection, solver parameter defaults, convergence criteria, post-processing conventions. This is not a generic AI capability applied to an unfamiliar tool. It is a purpose-configured system in which the simulation platform and the AI orchestration layer were designed to work together.
Why the combination is the point
Either capability in isolation would be a meaningful advance. A laptop-scale full-wave MoM solver is a real technical achievement regardless of how it is driven. An AI orchestration layer is useful regardless of what solver sits underneath it.
The reason this benchmark matters is that both capabilities exist in the same product. An engineer can state a problem in natural language, have the AI handle the implementation, and have the solver produce full-wave results on their laptop—in less than an hour. That combined workflow is what a legacy tool cannot currently replicate: slow solvers make AI orchestration less useful (why automate a run that takes overnight?), and proprietary scripting languages make AI orchestration harder to build. Nullspace addresses both.
6. Implications
Domain experts can leverage AI without being AI experts. The prompt that initiated this benchmark was written in the language of RF engineering: frequencies, mesh density, solver types, polarizations. The engineer did not need to understand AI tool configuration, API integrations, or prompt engineering techniques. The AI met the engineer on their own technical ground.
The competitive window is open now. Legacy EM simulation vendors face a fundamental architectural challenge: their tools were not built for programmatic AI interaction. Retrofitting proprietary scripting languages and GUI-centric workflows for AI orchestration is a multi-year engineering effort. Nullspace's Python-native architecture provides this capability today, creating a structural advantage that widens as AI-assisted engineering workflows become standard practice.
This approach scales. The NASA PEC Almond is a well-defined canonical benchmark. The same prompt-driven workflow—script generation, parametric execution, automated post-processing—applies directly to more complex geometries, multi-frequency parametric sweeps, optimization campaigns, and design-of-experiments studies. The constraint is problem complexity, not workflow complexity.
7. Technical Specifications (Appendix)
Simulation Parameters
Full Performance Metrics Table
Pipeline Timing Summary