↓ Skip to main content
Pranav
  1. Projects/

NLP to Magnetic Configs

2025 - Present ·3 mins
NLP Electromagnetics Julia CUDA Magpylib Particle Dynamics Visualization
Pranav
Author
Pranav
Coding with Physics, Physics-ing with code
Table of Contents

Media
#

Work-in-progress demo: prompt -> magnet geometry -> field/trajectory simulation.

Overview
#

I built this for AEGIS. The goal was simple: make magnet iteration loops way faster. Instead of manually rebuilding geometry every time, I can type a prompt, generate magnet geometry, compute the B-field, and immediately inspect particle deflection in 3D.

Why? Because early magnet design is mostly “try idea -> run sim -> reject/keep -> repeat,” and the manual setup overhead kills momentum.

Status (work in progress)
#

This is a work-in-progress prototype, not production-ready yet.

  • Barrel toroids and other complex/custom magnet families do compute in the backend.
  • The magnetic field lines for those cases are computed correctly.
  • The weak point is parser/visualization reliability: the default visualizers do not consistently render those shapes, so I still use custom visualizers for them.

Physics model
#

Magnet geometry is represented as parameterized primitives (cuboids, cylinders, arrays) with polarization vectors. The pipeline builds a B-field grid with Magpylib, caches it, and then traces charged particles with a relativistic Boris pusher. Interpolation is trilinear so particle tracing stays fast without throwing away too much field fidelity.

magnet_code = call_llm_for_geometry(prompt)
result = execute_bfield_python(magnet_code, grid_size, grid_extent)
trajectories = run_boris_particles(result)

Modeling evolution
#

Phase 1: OOP-based prototyping
#

I started with a minimal HTTP server and a parameterized magnet builder just to prove the geometry + field path was stable. This phase locked down grid conventions, interpolation behavior, and the baseline Boris integrator.

Phase 2: OOP-Sim (current)
#

The current version accepts natural language prompts, generates Magpylib geometry code, and runs a full field + particle simulation. Julia handles the heavy B-field and Boris push, with CUDA acceleration when available and a CPU fallback when needed. The frontend renders magnets, field vectors/lines, and animated particle paths for core supported families (Halbach, toroid, quadrupole). More specialized geometries still rely on custom visualizers.

Diagnostics + visualization
#

  • Field-line tracing and arrow sampling for spatial intuition.
  • Animated particle trajectories with per-species colors.
  • Cached B-field grids for quick reruns and parameter sweeps.

Performance + ops
#

The B-field grid build is still the dominant cost and scales hard with resolution, so dense runs can take minutes even on good hardware. GPU acceleration helps a lot. CPU fallback works for portability, just slower. I am working toward remote GPU/CPU hosting plus a more CPU-first local mode so testing is less painful.

AI notes
#

This has honestly been a fun experiment showing how useful AI can be for early magnet development and concept iteration.

At the same time, it also made the reliability gap very obvious. The current stack is not production-worthy yet; generation consistency is still too weak for high-trust engineering workflows.

I also experimented with custom Ollama-based variants, and that sucked for this use case. The direction that probably makes sense is a more specialized custom model with stricter domain constraints.

Stack
#

  • Julia (HTTP, CUDA, StaticArrays)
  • Python (Magpylib, NumPy)
  • Three.js frontend for interactive 3D visualization
  • LLM prompt-to-geometry generation

Related