ElmerGrid 26.2, standalone

ElmerGrid, the mesh generation, conversion and partitioning utility of Elmer, built and released on its own. Corresponds to ElmerCSC/elmerfem@devel shortly after the 26.2 release.

One self-contained binary per platform. Unpack and run — nothing to install, no Metis on the machine, no Elmer.

Linux	x86_64, arm64 — fully static
macOS	arm64, x86_64 — nothing outside /usr/lib and /System
Windows	x86_64, arm64 — only system DLLs

Every archive is checked before it is published: the binary must run, must produce a mesh, and must not depend on anything that is not part of the operating system. A dynamically linked binary that happens to work on the build machine is exactly the artifact that fails on somebody else's, so that is a gate rather than a note.

Two things are different from upstream's elmergrid/

The bundled METIS is gone. Upstream carries 137 files of METIS 5.1.0 from 2013 under elmergrid/src/metis-5.1.0. This repository carries none of it and links a Metis from the system: 303 tracked files down to 166. EXTERNAL_METIS defaults to ON here where upstream defaults it OFF, and -DEXTERNAL_METIS=OFF fails with the package name for each platform rather than silently building a vendored copy. Verified past the point where linking proves anything — ElmerGrid 1 2 angle_metis.grd -metis 5 still produces five partitions. This closes #1, opened here in March 2020, where @raback wrote "This is indeed the way to go. Sometimes built-in Metis causes conflicts."

The history now starts in 2005, not 2014. ElmerCSC/elmerfem begins in February 2014; ElmerGrid does not. 314 commits from 2005-06-06 to 2014-01-14 have been recovered from Elmer's pre-GitHub Subversion repository on SourceForge and joined to the front, so git log runs from ElmerGrid's first commit to today: 678 commits, 34 contributors, twenty years. The join is provable rather than plausible — the last Subversion commit before the GitHub era and the first GitHub commit have the same tree, 35f77aff….

What CI checks

Eleven platform and compiler combinations, then a job comparing the meshes they all produced. ElmerGrid has no threads, no random seeds and no dependence on timing, so the same .grd should give the same mesh everywhere. Whether it does is a measurement rather than an assumption, and the job is the instrument.

Of the twelve test cases, eleven come out byte-identical on every build in the matrix. barrel does not: under each compiler's defaults its connectivity differs on arm64 and Intel icx — a different mesh, not a rounding difference. Under strict IEEE semantics (-ffp-contract=off on arm64, -fp-model=precise for icx) every build agrees exactly, at 0.000e+00. Details and numbers in tests/README.md.

Not a fork

ElmerGrid is maintained at ElmerCSC/elmerfem and nothing here proposes moving it out. This repository exists to answer one question from ElmerCSC/elmerfem#202: what does a component of Elmer look like once it stands on its own. The work that made it possible was done upstream and merged — #890, #892, #902. Discussion belongs there.

GPL-2, as upstream. ElmerGrid is by Peter Råback at CSC – IT Center for Science.