I ran a performance experiment on the QPDK coupled-resonator notebooks (nbs/palace_qpdk_resonator for the driven/S-parameter solve and nbs/_palace_qpdk_eigenmode for the eigenmode solve), meshing locally with gmsh and solving on the GDSFactory+ cloud Palace (simulations/palace:latest, 16 CPU / 32 GB). The cloud image reports Palace v0.17.0 (Git changeset 12d8069).
Solver options tested on both solves:
- Default (GMRES) on the standard linear mesh (refined 5 um, ~19.6k nodes / ~107k order-1 tets): ran. Driven sweep (7.75-7.80 GHz, 300 points) ~137 s solve; eigenmode ~100 s.
- Default (GMRES) on a finer linear mesh (2 um, ~54k nodes / ~299k order-1 tets): ran. Driven ~411 s; eigenmode ~302 s.
- Default on a curved/high-order mesh (order-2 quadratic elements, ~181k nodes / ~132k second-order tets, refined 4 um): failed. Palace exits 1 within ~1 s of starting (mesh load). The identical mesh is read and solved fine by the palace-toolkit CPU build locally (
Mesh curvature order: 2) and passes quality checks (min SICN ~0.19, no inverted elements), so the mesh is valid.
- MUMPS direct solver (
Solver.Linear.Type = MUMPS) on the fine linear mesh: failed. Exit 134 (SIGABRT).
- STRUMPACK direct solver: failed. Exit 134 (SIGABRT).
Only the default GMRES path works on the cloud image. The MUMPS/STRUMPACK failures are consistent with the default Spack build of Palace (spack install palace), where the mumps, strumpack, arpack, and openmp variants default to OFF (only superlu-dist, slepc, sundials, libxsmm, and gslib are ON). Note that Palace's own CI uses the full spec +libxsmm+superlu-dist+mumps+sundials+strumpack+slepc+arpack.
The high-order-mesh crash is a separate, dependency-version problem: the Spack build links MFEM v4.9 plus a set of dev patches, while the palace-toolkit build links Palace's bundled MFEM (pinned master d9d6526). The differing MFEM gmsh mesh handling is the likely cause of the cloud-only quadratic-mesh failure.
Two alternative fixes:
- Install palace-toolkit on the cloud. The
palacetoolkit-palace-cpu v0.17.0 wheel ships a prebuilt Palace binary with MUMPS, STRUMPACK, OpenMP, and ARPACK enabled, built against Palace's bundled MFEM (high-order meshes work). gsim already integrates it via the palace-toolkit-cpu extra, so the cloud runner can use it as a drop-in palace.
- Change the default Spack compilation flags to match palace-toolkit. Enable
+mumps +strumpack +arpack +openmp in the Spack package defaults (or build with the official CI spec), and align the MFEM dependency with Palace's bundled MFEM so high-order/curved meshes load.
I ran a performance experiment on the QPDK coupled-resonator notebooks (
nbs/palace_qpdk_resonatorfor the driven/S-parameter solve andnbs/_palace_qpdk_eigenmodefor the eigenmode solve), meshing locally with gmsh and solving on the GDSFactory+ cloud Palace (simulations/palace:latest, 16 CPU / 32 GB). The cloud image reports Palace v0.17.0 (Git changeset12d8069).Solver options tested on both solves:
Mesh curvature order: 2) and passes quality checks (min SICN ~0.19, no inverted elements), so the mesh is valid.Solver.Linear.Type = MUMPS) on the fine linear mesh: failed. Exit 134 (SIGABRT).Only the default GMRES path works on the cloud image. The MUMPS/STRUMPACK failures are consistent with the default Spack build of Palace (
spack install palace), where themumps,strumpack,arpack, andopenmpvariants default to OFF (onlysuperlu-dist,slepc,sundials,libxsmm, andgslibare ON). Note that Palace's own CI uses the full spec+libxsmm+superlu-dist+mumps+sundials+strumpack+slepc+arpack.The high-order-mesh crash is a separate, dependency-version problem: the Spack build links MFEM v4.9 plus a set of dev patches, while the palace-toolkit build links Palace's bundled MFEM (pinned master
d9d6526). The differing MFEM gmsh mesh handling is the likely cause of the cloud-only quadratic-mesh failure.Two alternative fixes:
palacetoolkit-palace-cpuv0.17.0 wheel ships a prebuilt Palace binary with MUMPS, STRUMPACK, OpenMP, and ARPACK enabled, built against Palace's bundled MFEM (high-order meshes work). gsim already integrates it via thepalace-toolkit-cpuextra, so the cloud runner can use it as a drop-inpalace.+mumps +strumpack +arpack +openmpin the Spack package defaults (or build with the official CI spec), and align the MFEM dependency with Palace's bundled MFEM so high-order/curved meshes load.