Palace, a 3D finite element solver for superconducting quantum devices

What the acronym stands for, and what the code is for

Palace is an open-source, parallel finite element code for full-wave 3D electromagnetic simulations in the frequency or time domain, and the name expands to PA, for Parallel, LA, for Large-scale, C, for Computational, E, for Electromagnetics.

The project sits inside AWS Labs and is described in the README as developed by the Design and Simulation group in the AWS Center for Quantum Computing. That origin explains the feature list. The headline capability is eigenmode calculations with optional dielectric or radiative loss including lumped impedance boundaries, and the automatic postprocessing of energy participation ratios for circuit quantization, along with interface or bulk participation ratios for predicting dielectric loss.

Energy participation ratios are the quantity that connects a 3D field solution to a circuit model. A designer needs to know how much of the stored energy sits in a particular dielectric, because dielectric loss and the resulting coherence time follow from it. Calculating that in a circuit-level tool is not possible; it needs the field solution. Palace is the tool that produces it.

The other simulation modes are broad. Frequency domain driven simulations with surface current excitation and lumped or numeric wave port boundaries, with wideband frequency response calculation using uniform frequency space sampling or an adaptive fast frequency sweep algorithm. An explicit or fully-implicit time domain solver for transient analysis. Lumped capacitance and inductance matrix extraction through electrostatic and magnetostatic formulations.

The audience is narrow and specific: people designing superconducting quantum computing components. The examples directory makes that concrete, with an `adapter/`, an `antenna/`, a `cavity2d/`, a `circular_hole/`, a `coaxial/`, a `cpw/`, a `cpw2d/`, a `cylinder/`, a `dielectric_grating/`, an `iris_filter/`, a `rational_impedance/`, a `ring_disk/`, a `rings/`, a `spheres/` and a `transmon/` directory, each with configuration files and meshes.

The licence is Apache-2.0, the last push to the repository was on 2026-10-20, and the recorded releases are v0.18.1 from 2026-09-21, v0.18.0 from 2026-09-10 and v0.17.0 from 2026-06-29.

MFEM and libCEED, and what the finite element stack gives you

Palace does not implement its own discretisation. It uses the MFEM finite element discretization library and the libCEED library for efficient exascale discretizations, and the feature list says as much when it credits arbitrary high-order finite element spaces and curvilinear mesh support to MFEM.

That division of labour is the right one for a research code. The hard, general part of finite element work, the weak formulation, the element families, the mesh handling, the solvers, is what MFEM is for, and Palace builds the electromagnetic problem on top of it. Writing that from scratch would consume the entire project budget before any physics happened.

libCEED is the other half and it addresses a different problem. MFEM's default operator assembly is well suited to small problems, and as the high-order space gets finer the cost of applying the operators becomes the bottleneck. libCEED provides a partial assembly and operator decomposition approach that keeps the operators matrix-free, and Palace's feature list credits the scalable solution algorithms with matrix-free p-multigrid using high-order operator partial assembly, along with parallel sparse direct solvers and algebraic multigrid preconditioners.

So there are three solver strategies in the box, and the choice depends on the problem. p-multigrid with partial assembly is the scalable one, aimed at the largest simulations. Sparse direct solvers are dependable and memory-hungry. AMG preconditioners are the general-purpose option. The documentation claims fast performance on platforms ranging from laptops to HPC systems, which is the intended range.

On top of that sits the mesh and refinement machinery. Palace supports a wide range of mesh file formats for structured and unstructured meshes, with built-in uniform or region-based parallel mesh refinement. It also offers solution-based Adaptive Mesh Refinement for all simulation types aside from transient, with nonconformal refinement supported for all mesh types and conformal refinement for simplex meshes.

The transient exclusion from AMR is a sensible constraint and a clue about the design. In an eigenmode or frequency sweep calculation the solution is stationary in time, so a fixed mesh refinement criterion is well defined. In a transient run the field changes over time, and refining based on a solution snapshot is a different problem the project has chosen not to solve.

Installing through Spack, and what the build asks of your machine

Installation is via Spack, the HPC package manager, and the command is short.

The command is `spack install palace`.

Running `spack info palace` gives more information about the available configuration options and dependencies, which is the right first step on a cluster where the defaults may not match your hardware.

The container route uses Spack's own container support, and the source build instructions are in the documentation. The build has a requirement that is easy to miss: as part of the CMake build process, most dependencies are downloaded and installed automatically and thus an internet connection is required. On an HPC cluster that often means building during a session with network access and then installing the result, rather than building on a login node with no outbound access.

The system requirements are the real cost of this project.

- CMake version 3.27 or later - C++20 compatible C++ compiler - C and Fortran (optional) compilers for dependency builds - MPI distribution - BLAS, LAPACK libraries - CUDA Toolkit or ROCm installation (optional, for GPU support only)

The Fortran requirement is easy to overlook and it is not optional in practice, because optional compilers are needed for dependency builds. Several of the numerical libraries in this space are Fortran. The GPU support is genuinely optional and the project supports both NVIDIA and AMD, using pure CUDA and HIP code as well as MAGMA and other libraries, including multi-GPU parallelism.

The documentation is hosted with a stable and a dev version, and the docs can be built locally. That requires Julia with Documenter, and the setup is three commands.

julia --project=docs -e "using Pkg; Pkg.instantiate()"

cd docs/build && python -m http.server 8000

The documentation generation itself is `julia --project make.jl` from within the `docs/` directory. The presence of a Makefile target that regenerates the configuration documentation and another that regenerates a schema compatibility document tells you the config surface is large and versioned deliberately.

The example set as a curriculum

Palace's most useful contribution for a newcomer is the examples directory, and it is worth reading as a progression rather than a list.

There are two-dimensional cases and three-dimensional ones. `cavity2d/` and `cpw2d/` are the 2D entries. The 3D set covers a `cylinder/`, `spheres/` and `rings/`, which are the closed-geometry eigenmode problems. `coaxial/` and `cpw/` are the transmission line geometries, and `cpw/` is a coplanar waveguide, the standard planar superconducting qubit geometry. `iris_filter/` is a filter with an iris aperture, `dielectric_grating/` and `circular_hole/` are periodic structures, `antenna/` is a radiating element, and `adapter/` is a transition.

Then the two most domain-specific ones. `transmon/` is the transmon qubit geometry, which is the most widely used superconducting qubit design, and `rational_impedance/` covers a frequency-dependent surface impedance boundary condition, which is the physically correct way to model a superconductor's surface rather than a fixed impedance.

The `examples/Project.toml` file at the top of the directory is worth noting because it is not a Julia project file for the solver, it is there for the documentation pipeline that references these example directories, so the configuration files and meshes get rendered into the tutorials.

The documentation says complete tutorials for each example are available in the docs, and the repository's `test/` directory with its regression suite is how the code is checked.

The Makefile test target is a single ctest invocation against an existing CMake build tree.

BUILD_DIR ?= build
tests:
	cd $(BUILD_DIR)/palace-build/test/unit && ctest -L "^regression$$" --output-on-failure

The label filters the suite to the regression cases only, and the override for BUILD_DIR lets you point at a build tree that lives somewhere else, which is the situation on a shared cluster where the build is staged rather than in the source tree.

The GPU path and the linear algebra you inherit

Two features deserve a closer reading because they determine whether a simulation is feasible for you.

The first is the GPU support. The project supports hardware acceleration using NVIDIA or AMD GPUs, including multi-GPU parallelism, using pure CUDA and HIP code as well as MAGMA and other libraries. The MPI distribution in the system requirements is what makes the multi-GPU part work, since the parallel decomposition and the device placement have to agree. The optional CUDA Toolkit or ROCm installation in the requirements list is what makes it optional, in the sense that a CPU build works, just without the acceleration.

The second is the choice of linear solver, and it is the one that most often decides whether a run is possible. A 3D high-order finite element problem produces a system whose size grows quickly, and how the system is solved changes the memory and time budget by orders of magnitude. Palace offers matrix-free p-multigrid with partial assembly for the scalable case, parallel sparse direct solvers for reliability, and AMG preconditioners for the general case.

The practical advice is to start with the AMG-preconditioned iterative approach, because it is the most forgiving, and move to p-multigrid once you know the problem behaves. Sparse direct solvers are attractive because they are definitive, and they are the option that will exhaust memory first on a large 3D problem.

There is also the AMR angle, and it changes the arithmetic. Solution-based adaptive mesh refinement refines where the field needs it rather than where the geometry is complicated, which for an eigenmode calculation typically means the region around the iris or the dielectric interface. Nonconformal refinement is supported for all mesh types, and conformal refinement for simplex meshes, so a tet mesh can use a finer tet mesh next to it without hanging nodes. That is what makes AMR practical in three dimensions, and it is why the code can produce an accurate result on a mesh that is fine only where it needs to be.

One caveat about the whole performance story: everything above depends on your MPI, your BLAS and LAPACK, your GPU and your interconnect. The library claims a range from laptops to HPC, but a laptop build and a cluster build differ in which solver and which assembly path you would sensibly choose.

Where Palace is the wrong tool

The scope is narrow enough that the wrong-tool cases are easy to state.

If you need a circuit-level answer, a lumped element model, a filter with a known analytic response, this is the wrong tool. A 3D finite element solve with mesh generation and a parallel linear solve is a substantial machine to run, and there are far cheaper ways to get a filter response. Palace earns its cost when the geometry is the thing you do not understand, and that is the case the participation ratio workflow is built for.

If you are on a laptop with no MPI and no interest in clusters, the effort is steep. The system requirements are a CMake of 3.27 or later, a C++20 compiler, C and Fortran compilers for the dependency builds, an MPI distribution, and BLAS and LAPACK. You can build it, and the project says the range runs from laptops to HPC, but the experience is a build that downloads and compiles a stack before it solves anything.

The third wrong-tool case is time-domain transient work that needs adaptive refinement. The feature list excludes transient from solution-based AMR, so if your problem is a transient with a moving field structure that you expect to need refinement, that capability is not there in this version.

The fourth is a mesh you cannot get in. Palace supports a wide range of mesh file formats for structured and unstructured meshes, but the mesh still has to exist and has to be good enough for a high-order space. A high-order element on a bad mesh is worse than a low-order element on a good one, and the tool will not fix your geometry.

For all of these, the alternative is not a different solver but a different level of model. A lumped element or circuit model answers a different question much more cheaply. And within the full-wave world, Palace's own dependency set, MFEM for discretisation and libCEED for exascale operator application, is the alternative for anyone who wants to build a different electromagnetic application on the same foundations.

Editorial conclusion

Palace suits a research team designing superconducting cavities, waveguides or filters who needs a full-wave 3D answer rather than a circuit model, and who can afford an MPI cluster and a nightly build of the dependencies. It does not suit a front-end or embedded designer who needs an answer in seconds, since this is a finite element code with mesh generation and linear algebra in the loop. Verify first that the operating system and MPI setup match what the Spack package expects, that your mesh format is one Palace reads, and that the solver configuration you need, eigenmode, frequency domain or transient, is covered by the version you take.

Frequently asked questions

Official sources

1. awslabs/palace on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases