turing-surface-cache
Reaction-diffusion (Turing patterns) on curved surfaces, evaluated at a chosen end time. Every setting is a choice from a short list, so each combination names one exact solution. Solutions already in the shared cloud cache load by themselves as you browse the choices; a combination no one has computed shows empty surfaces until you press Compute solution, which runs it here (with WebGPU, via turing-surface's spectral solver). Drag to rotate. Or take one parameter through its whole range on the parameter sweep page.
if that command does not run on the other machine
Unexpected token {, or another syntax error, means that
machine's node is too old to read the program at all: node 18 or newer
is needed. nodejs.org has current builds, and nvm, fnm and asdf install
one per user without touching what the system depends on; where a
cluster uses environment modules, module load node may be
all it takes.
the webgpu package is installed but did not load … GLIBC_2.34
not found means the machine's distribution is older than the
prebuilt Dawn binary — ordinary on a long-lived Linux workstation, since
Rocky and RHEL 8 have glibc 2.28 and Dawn wants 2.34. Running the
command inside a container is the obvious answer and the wrong one:
there the NVIDIA driver declines to bring up its Vulkan driver, while
on the host it comes up fine. What does work is borrowing a newer
userland from a container image and running node through that
loader, still on the host, so the GPU, /dev and
/proc are exactly what they were:
# 1. borrow a userland — podman or docker unpacks it; nothing runs inside it mkdir -p ~/turing-userland podman create --name u docker.io/library/node:22-bookworm-slim true podman export u | tar -x -C ~/turing-userland podman rm u # 2. a node that uses it, running on the host rather than in a container U=~/turing-userland; mkdir -p ~/turing-bin printf '#!/bin/sh\nexec %s --library-path %s %s "$@"\n' \ $U/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 \ $U/usr/lib/x86_64-linux-gnu:$U/lib/x86_64-linux-gnu:/usr/lib64 \ $U/usr/local/bin/node > ~/turing-bin/node chmod +x ~/turing-bin/node # 3. and the borrowed npx, which is a script rather than part of node printf '#!/bin/sh\nexec ~/turing-bin/node %s "$@"\n' \ $U/usr/local/lib/node_modules/npm/bin/npx-cli.js > ~/turing-bin/npx chmod +x ~/turing-bin/npx # 4. run the command above, with those found first export PATH=~/turing-bin:$PATH
The host's own /usr/lib64 stays last on that library
path, and is where the NVIDIA libraries and the Vulkan loader come
from: those have to match the running kernel module, so they must be
the machine's own. If podman's storage lives on NFS it will fail to
unpack the image, which
--root /tmp/$USER/store --runroot /tmp/$USER/run on each
podman command works around.
Note that npx has to be borrowed as well as
node. It is not part of node but a script beside it,
so a machine whose own node is too old has an npx too
old to go with it, and putting only a node on the path leaves that
old one to be found. Its symptoms are its own rather than the
version error above, since it is a different program from the npx
of any current node.
WebGPU is not available, or no adapter at all, means
there is no GPU to reach: Dawn goes through Vulkan on Linux and Metal
on macOS, so a machine without a GPU, or with one whose driver is not
installed, has nothing to offer.
DAWN_FLAGS='backend=vulkan' makes it say more about why.
A rate of a few steps per second rather than a few hundred means a software rasterizer has stood in for the GPU. The command names its adapter on the first line and says so when it notices, but it does not refuse to run — a slow contribution is still a contribution, if that is what you meant.