An openEMS alternative with a GUI, a GPU solver, and live results

If you have used openEMS, you already know the trade. It is free, it is accurate, and the physics is solid. You pay for that with scripting, manual meshing, CPU-only run times, and a workflow stitched together from separate tools. This post is an honest look at where openEMS is strong, where it hurts, and what RayRF does differently.

We are not here to dunk on openEMS. It is a real contribution to the field and the right tool for plenty of people. The point is narrower: if the scripting and the wait times are the reason you avoid full-wave simulation, there is now a different option.

What openEMS does well

• It is free and open source. No license, no seat count, no renewal.
• The FDTD core is well understood and has been used in published work for years.
• It is fully scriptable, so it drops into automated pipelines and parameter sweeps if you are willing to write the code.
• It runs on Windows, Linux, and macOS, on any CPU.

Where openEMS gets in the way

The friction is not the physics, it is everything around it. A typical openEMS project is 50 to 200 lines of MATLAB or Python before you see a result. You define geometry in code, build the mesh by hand, run the solver from a script, then load the output into another tool to look at S-parameters or a radiation pattern. Each change means editing the script and waiting for a CPU run.

• No integrated GUI for drawing or editing a board.
• Manual mesh definition, which is where most accuracy bugs live.
• CPU-only, so larger meshes turn into long waits.
• Post-processing is a separate step in separate tools, not a tab next to the editor.

What RayRF changes

RayRF puts the whole loop in one window. You draw or import a board in a layer-based 2D editor, set the stackup and ports, slide a single quality preset, and click Run. The mesh is derived for you, with a manual override panel if you want it. The solver runs on your NVIDIA GPU and the S-parameter curves update while it runs. Smith chart, 2D and 3D radiation patterns, volumetric fields, and surface currents are all tabs in the same app.

Speed, on the same problem

Numbers only mean something when both tools run the same work. The case below is a 5.8 GHz patch on a 46.8M-cell mesh, stepped 5,000 times, with RayRF and openEMS solving the identical setup on the same workstation (RTX 5070 Ti GPU, Ryzen 9 9950X CPU). These are the same numbers shown on the benchmarks page.

The point is not the exact multiple, it is the difference between a 25 second answer and a 28 minute one. RayRF on the same CPU as openEMS still runs about 4.3x faster, so the gap is not only the GPU. That difference is what makes an interactive workflow possible at all.

Does the answer match hardware

Speed is worthless if the result is wrong. RayRF has been checked against 43 structures measured on a physical VNA, including patch antennas, a dual-band patch, and an interdigital bandpass filter. For many of those the resonant or pole frequencies track the measurement within 1 percent across the band. The 9 most representative are shown side by side on the validation page, and the head-to-head timing setup is on the benchmarks page.

Which one should you use

• Stay on openEMS if free is what matters most, you are comfortable scripting, you need macOS or non-NVIDIA hardware, or your work is outside planar PCB RF.
• Try RayRF if you want to draw a board and get S-parameters in minutes, you have an NVIDIA GPU, and the scripting and wait times are the reason you skip simulation today.

Frequently asked questions