openEMS solves electromagnetic fields with FDTD, from Octave or Python

A time domain solver, not a frequency domain one

openEMS is described as a free and open electromagnetic field solver using the FDTD method, and the method choice is the first thing to understand about the tool. A finite difference time domain solver advances the field in discrete time steps and solves Maxwell's equations on a spatial grid, which means one run produces the field over time and, by Fourier transform, the frequency domain results. That has practical consequences. A time domain solver is well suited to broadband problems, to impulsive excitation and to watching how energy propagates, and it works in the same domain as the measurement you want to compare against. The project names Octave and Matlab as well as Python as easy and flexible scripting interfaces, so the choice of interface is not a commitment to one language.

A graded mesh in Cartesian or cylindrical coordinates

The mesh is the part of an FDTD solver that determines what you can model, and the feature list names it precisely. There is a fully 3D Cartesian and cylindrical coordinate graded mesh, which means the cells can be small where the field varies quickly and large where it does not. That grading is what makes a 3D simulation of an antenna or a connector tractable on a laptop, because you are not forced to resolve the whole volume uniformly. Cylindrical coordinates are the natural choice for rotationally symmetric structures, and Cartesian for the rest. The geometry is not drawn in a GUI for this project but written in the project's own text format, which is the subject of the next section.

CSXCAD, QCSXCAD and the geometry side of the project

The repository layout is where the openEMS architecture becomes clear. The top level contains `CSXCAD`, the geometry and excitation definition front end, `QCSXCAD` for the geometry that openEMS consumes, and `AppCSXCAD`, the graphical front end for the same definitions. There is also `CTB`, `fparser` for Fortran parsing, `hyp2mat` for converting Hyperlynx style data, the `openEMS` directory for the simulation code itself, plus `doc-src/` for the documentation sources and `scripts/` for helper scripts. The key point is that the simulation code lives in the submodules, each of which has its own `AGENTS.md`, and the repository is a container for a set of related tools rather than a single program.

Dispersion, performance and the field output formats

Three capabilities stand out in the feature list. The first is dispersive media support, with Drude, Lorentz and Debye type models, which is what you need for real substances rather than an ideal vacuum, and without it any result involving a dielectric is wrong. The second is speed, with multi-threading and SIMD support in the form of SSE for high speed FDTD, and the documentation site links a longer list of features. The third is the output. Field dumps are written in the time domain and the frequency domain, as vtk or hdf5 files, which is a decision with consequences, because vtk opens in ParaView and other visualisers while hdf5 is what a Python post-processing script will read, and the two are not interchangeable for large runs. The post-processing routines that consume those dumps are available in Octave, Matlab and Python, so the analysis step stays in the same environment as the setup.

Building it, and the two documentation sites

The README does not carry build commands, and it points at the installation documentation instead, at the install index in the docs site, with the project website at openEMS.de and the documentation at docs.openEMS.de. The repository itself gives the shape of a build, since there is a top level `CMakeLists.txt`, a `scripts/` directory, an `update_openEMS.sh` helper for pulling the submodules in step, and `.readthedocs.yaml` for the documentation build, which tells you the docs are written for Sphinx. The contributor guidance is unusually explicit for a scientific code base. The README says pull requests are welcome, that `AGENTS.md` holds the working rules covering build, submodule handling, documentation and commit conventions, that those rules apply to human and AI assisted contributions alike, and that disclosure and sign-off requirements live in `AI_POLICY.md`.

Where this sits against commercial solvers

The difference in approach against a commercial field solver is mostly about what you own. In openEMS the geometry, the excitation and the results are text and data files in formats you can read with your own tools, and the simulation is reproducible from a script, which is what makes a study defensible or a regression test possible. A commercial package usually offers a smoother modelling environment and a validated solver behind it, and it also charges per seat or per year. The honest limitation of the open approach is that you are responsible for the convergence of your own simulation, since there is no vendor behind the results when the mesh is too coarse, and the documentation, not a support contract, is what tells you when that has happened.

Release pace and the licensing question

The release history shows an active project with a slow major version and quick iteration underneath. The listed tags are v0.37.0-rc2 on 2026-09-08, v0.37.0-rc3 on 2026-09-22 and v0.37.0 on 2026-10-09, and the last push to the repository was on 2026-10-19, so the 0.37 line is still moving. The version numbering under 1.0 also signals that the project considers its interface unsettled, which is normal for a scientific code base but worth knowing before you build a workflow on it. On licensing, the repository metadata does not identify a licence, and the README does not state one either, so the terms are not clear from what is published here. If your use is commercial or you need to redistribute the solver, resolve that question with the project before you depend on it.

Editorial conclusion

Adopt openEMS when you need a field solver you can script, reproduce and read rather than a commercial simulator with a licence attached, since the same solver is reachable from Octave, Matlab and Python and the geometry is written in a text format under version control. Do not adopt it expecting a turnkey GUI or a model library, because the repository ships the solver and its geometry tools rather than prebuilt models, and the documentation is what tells you how to assemble one. Verify first that the build instructions on docs.openEMS.de cover your platform, and note that the licence is not identified in the repository metadata, so read the licensing terms yourself before using it commercially.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. thliebig/openEMS-Project on GitHub