mumax³ ultrafast

The fastest micromagnetic simulator on a Mac.

English · 한국어 · 中文 · 日本語

Upstream mumax³ is built around NVIDIA CUDA, so it does not run on a Mac at all. This project replaces the GPU execution layer with a native Metal implementation and then optimizes it — and on an M4 MacBook Air it now runs 3.3× to 30× faster than every other micromagnetic simulator that runs on a Mac, using 5.9× to 26× less energy for the same physics.

The port changes the hardware backend, not the physical model. The .mx3 language, the high-level Go solver, material terms, integration methods, and output formats stay mumax³-compatible — and the results agree with the CUDA-era references to within the original upstream tolerances.

"Fastest. Most efficient. And the only one that actually uses the GPU."

taewoopark.com — author site

_{Open completed simulations directly in the optional desktop app, then rotate, zoom, recolor, and play the OVF result in 3D.}

A physicist with a Mac has, until now, had three options: keep a Linux box with an NVIDIA card, rent one, or run on the CPU and wait.

• mumax³ and mumax+ are CUDA-only. They do not run on Apple hardware.
• MicroMagnetic.jl lists Apple GPUs among its supported backends. Version 0.5.0 does not run on one. Its own examples/std4.jl, unmodified, fails at Sim() — the package defaults to Float64 and Apple GPUs have no double-precision hardware. Forcing set_precision(Float32) gets past that and then still fails inside GPU kernels: gpu_fill_kernel! for a plain exchange-only LLG step, and newell_f in the demag tensor. Every path reaches a double inside a Metal kernel.
• magnum.np has no Apple GPU path at all: magnumnp/__init__.py selects cuda:N or cpu, forces float64 at import, and builds the demag tensor in double precision. Reaching MPS took three source patches.
• OOMMF has no GPU backend for any vendor.

So the Mac has been a second-class machine for micromagnetics. It no longer has to be.

One M4 MacBook Air (10 GPU cores, 32 GB, fanless), one session, every simulator solving the identical problem: demag + exchange, Heun integration at a fixed 1e-13 s step, the same number of steps per mesh. Every arm therefore performs exactly two effective-field evaluations per step — mumax³ reports Neval = 2×steps, OOMMF reports energy_calc_count = 2×steps + 1.

3.28× to 29.97× faster than every external tool, at every size measured.

_{MicroMagnetic.jl appears twice because its two backends behave differently: the CPU backend runs and is benchmarked normally, while the Metal backend does not run at all. magnum.np likewise appears twice — MPS is its best case after three source patches, CPU is what pip install gives you.}

This is the axis nobody can settle against NVIDIA, because published comparisons divide measured throughput by a nominal board TDP and the answer moves by 3× depending on what fraction of TDP the card really draws. Restricting the question to one machine removes the assumption entirely: every arm ran on the same chip with powermetrics sampling the real GPU, CPU and combined rails.

_{512² mesh, 2000 Heun steps = 1.049×10⁹ cell-evaluations in every arm. Machine idle floor during the run: 0.195 W combined, 0.002 W GPU.}

OOMMF is only 3.3× behind on time but burns 16.4 W doing it, against 6.1 W on the GPU — so on energy it falls 8.9× behind. A fanless laptop does the same physics for the power of a light bulb filament.

83,886,080 cells (8192 × 10240, 23.69 GiB peak) complete without paging out — at 4 nm cells that is a 32.8 × 41.0 µm film, a whole patterned device rather than a corner of one. That is 5.0× more than any other GPU-capable tool on the platform.

OOMMF reaches the same 83.9M — and mumax3-ultrafast is 4.5× faster there (29.2 s against 131.1 s). Both fail at 104.9M on this machine.

A speed number is worthless if the answer is wrong. Every arm above was required to agree before its timing counted. After the same number of steps, all four independently written codes — three languages, three backends — return the same mean magnetization:

Worst disagreement anywhere in the sweep: 7.1×10⁻⁵.

The equations and solvers were not reimplemented. The native backend executes the existing mumax³ physical model through Metal, so the model you are citing is still mumax³. Validation against unchanged upstream CUDA-era regression references:

The 100% figure is tolerance conformance, not a claim of bit-for-bit identity — parallel GPU reductions can differ in their last floating-point bits. Thermal simulations use Philox instead of cuRAND's XORWOW, so a seed is reproducible on Metal but does not reproduce CUDA's sample-by-sample trajectory; the statistical behaviour is validated instead.

All 15 official example inputs are byte-for-byte identical to the upstream template, and their outputs, logs, and provenance are committed.

• Complete physics-validation method and data
• Official examples, outputs, provenance, and license

On a supported Mac, open Terminal and run:

/bin/bash -c "$(/usr/bin/curl -fsSL https://raw.githubusercontent.com/TaewoooPark/mumax3-ultrafast/main/install-macos.sh)"

The installer first looks for the prebuilt Apple Silicon engine and its published .sha256 file in the latest GitHub release. When those assets are available, it verifies the SHA-256 checksum, installs the executable as ~/.local/bin/mumax3, adds that directory to ~/.zprofile, and finishes with mumax3 -test. This prebuilt path does not require Homebrew, Go, Git, or a source checkout. The desktop app is never installed by this command.

If the engine archive returns an explicit HTTP 404—for example, for a version whose assets have not yet been published—the installer automatically falls back to a source build and may install Apple Command Line Tools, native Homebrew, and Go. Network and other connectivity errors do not trigger that fallback; the installer stops safely instead. It is safe to rerun after an interruption.

To force a source build from an existing checkout:

./install-macos.sh --from-source

Open a new Terminal afterwards so the updated path is loaded.

The mumax3-ultrafast engine and command-line workflow remain the primary installation above; the macOS desktop app is an optional interface on top. It keeps .mx3 files as the source of truth while adding an editor, explicit working-folder selection, one-click runs, live magnetization and solver metrics, runtime logs, and an integrated 3D OVF result viewer. Open OVF folder in Live Magnetization can also render results created outside the app; choose the folder that directly contains the .ovf files. In the result viewer, Projection maps a selected X, Y, or Z spin component from −1 to +1 along an editable two-color line (white to black by default); Direction and Magnitude palettes remain available.

Build and install the optional app locally, without an Apple Developer Program membership:

/bin/bash -c "$(/usr/bin/curl -fsSL https://raw.githubusercontent.com/TaewoooPark/mumax3-ultrafast/main/install-app-macos.sh)"

The installer resolves the latest tagged release, prepares private Node.js, pnpm, and Rust tooling under ~/Library/Caches/mumax3-ultrafast, builds and ad-hoc signs the app on this Mac, installs it as ~/Applications/mumax3 ultrafast.app, and installs the matching standalone engine. The first source build can take several minutes; later builds reuse the private cache. If Apple Command Line Tools are missing, finish the system installation prompt and run the command again. Re-run the same command to update. To remove only the app while preserving the engine, build cache, and simulation files:

/bin/bash -c "$(/usr/bin/curl -fsSL https://raw.githubusercontent.com/TaewoooPark/mumax3-ultrafast/main/install-app-macos.sh)" -- --uninstall

This local-source app is not Apple-notarized and may be restricted on managed Macs. When a GitHub Release includes mumax3-ultrafast-app-darwin-arm64.dmg, that asset is the faster signed and notarized installation path. See apps/desktop/README.md for options and the development workflow.

Script workspace — open or write an .mx3 file in the folder you choose.	Live run — follow magnetization, solver metrics, progress, and logs.
Results ready — open the completed run's OVF frames without leaving the workspace.	3D vector field — rotate, pan, zoom, recolor, and play the result.
Detail view — switch glyph styles or map an X/Y/Z spin projection onto any two endpoint colors.	Top view — inspect the texture in the simulation plane.

mumax3 example.mx3            # live Web UI at http://127.0.0.1:35367
mumax3 -http="" example.mx3   # headless, for benchmarks and batch jobs

Output lands in example.out/. Both modes execute the same simulation and produce the same output. The full Xcode application and an offline Metal compiler are not required — the shader library compiles through the system Metal runtime.

The implementation uses X-contiguous 32-wide SIMD tiles suited to Apple GPUs, keeps the GPU resident across blocking drains, splits large demag transforms one axis at a time to avoid MPSGraph's collapsed scheduling region, and compiles shaders at runtime so Command Line Tools alone are enough.

At research mesh sizes an Apple GPU is often idle waiting for the host rather than short of arithmetic: at 128×128 the host takes longer to encode a Dormand-Prince step than the GPU takes to run it. Three knobs address that, and none change what the default build does.

SpeculativeStep = true   // overlap host encoding with GPU execution — 1.53× measured
MinimizeOnGPU   = true   // keep minimize()'s BB step size on the device — 1.58× measured

mumax3 -j 3 sweep_*.mx3   # N queued inputs per GPU — 2.53× aggregate for three minimize() jobs

SpeculativeStep still enforces MaxErr, but the rejection lands one step late, so the sequence of time steps differs from the exact controller and the trajectory diverges at the ~1% level after a few thousand steps. It closes itself under FixDt, finite Temp, relax(), DemagExtrapolation, and post-step hooks. MinimizeOnGPU keeps every descent bit-identical; only the convergence check is one iteration late, so a minimization can stop one iteration further along. Validate either against a default run for your own problem.

The default automatically uses the vendored VkFFT backend for eligible 2D demag transforms whose padded dimensions are powers of two no larger than 512×512 and whose active data is a strict prefix; MPSGraph handles everything else. MUMAX3_METAL_FFT_BACKEND=mps keeps all plans on MPSGraph; vkfft extends VkFFT to the padded 1024×1024 tier.

High-order demagnetizing-field extrapolation accelerates demag-heavy solver 4/5/6 workloads, but it is an approximation and is off by default:

SetSolver(5)
DemagExtrapolation = true

Unsupported solvers and unsafe model states fail closed to exact convolution. The error depends on trajectory and time step, so a successful benchmark on another problem is not an accuracy guarantee — see the validation results and A/B instructions first.

Throughput per cell is not flat in problem size. It peaks at 256² on the measured M4, and at and below 128² a fixed per-evaluation overhead of about 172–187 µs dominates, where a wider GPU cannot help at all. bench/curve.txt has the measured curve.

Everything above is reproducible from this repository. Nothing is modelled.

./bench/capacity.sh name=/path/to/binary   # Metal limits, B/cell, vmmap split, ceiling
python3 bench/crosstool_svg.py             # re-render the README charts from the data

The cross-tool harnesses — one per simulator, all solving the same problem with the same integrator — live in crosstool/: run_crosstool.py (speed and physics), run_energy.py (powermetrics), run_capacity.py (ceilings). Method notes, including the two patches magnum.np needs to reach the Apple GPU and what was tried before concluding MicroMagnetic.jl's Metal backend cannot run, are in each script's docstring.

Measurement hygiene that materially changed results, recorded so others avoid them: swap must be watched through vm_stat's Swapouts, not Pageouts — on Apple Silicon the compressor leaves Pageouts nearly still while writing gigabytes — and mumax³'s per-geometry demag kernel cache reaches 8–10 GB per entry at these sizes, so it has to be dropped between runs.

Stated plainly, because a benchmark that hides its edges is worth nothing:

• Against NVIDIA on raw speed, this loses. On mumax³'s own 62-GPU benchmark table an M4 lands between a GTX 1650 mobile and a GTX 970. The claim here is scoped to Apple Silicon deliberately — it is the range in which every axis can be measured on one machine with no TDP assumption and no cross-machine normalization.
• Capacity ties OOMMF. Both reach 83.9M cells and both fail at 104.9M. mumax3-ultrafast is 4.5× faster at that size; it is not larger.
• The margin over the previous release narrows with mesh size — 5.4× at 128², 1.38× at 2048². This round's work targeted the latency-bound regime where research meshes actually sit.

Derived from mumax³, whose design and verification are described in the original paper. NVIDIA CUDA users should follow the official mumax³ installation documentation.

Distributed under the GNU GPL v3 or later. The project notices preserve the upstream CUDA linking permission and identify the macOS modifications. Licenses and attribution for Random123, Go, SVGo, and Freetype-Go are collected in the third-party notices.

Comparison targets are cited as measured, at the versions installed during the run: MicroMagnetic.jl 0.5.0 with Metal.jl 1.10 (arXiv:2406.16064), magnum.np 2.2.0, and OOMMF 2.0b0.

I am Taewoo Park, an undergraduate physics student at the Korea Advanced Institute of Science and Technology (KAIST). Since October 2025 I have conducted experimental spintronics research on magnetic domain wall motion and neuromorphic computing applications at the KAIST Ultrafast Spin Dynamics Laboratory (USDL), led by Professor Kab Jin Kim. From June 2023 through March 2024 I studied domain wall motion through theoretical modeling and micromagnetic simulation in the KAIST Quantum Spin Dynamics Laboratory under Professor Se Kwon Kim.

_{Same equations. Same scripts. Same answers. On Apple Silicon.}