System requirements

Which browsers and devices run Elementarium, how threading affects solve speed, and where the practical ceiling on model size comes from.

Getting started 4 min read

Elementarium is a web application, so the requirements are about the browser, not the operating system. There is nothing to install, no graphics driver to update and no licence server to reach.

Browsers

Browser	Support
Chrome, Edge and other Chromium browsers	Current versions
Firefox	Current versions
Safari	Current versions, on macOS and on iPadOS / iOS

"Current" means the release channel the vendor is shipping now.

The finite element core is C++ compiled to WebAssembly. It runs on x86 and ARM alike: an Apple-silicon laptop, a Windows workstation and an Android tablet all run the same binary at native-code speed.

Two solver builds, and why one is faster

Two WebAssembly builds ship, and the app chooses between them at load time. You do not choose.

Build	What it does	When it runs
Threaded	Spreads assembly and solution across the machine's cores — by default half its logical processors, at most eight	The browser grants the page cross-origin isolation (a security condition that lets a page share memory between threads) and can create the nested workers a thread pool is made of
Single-threaded	The same solver on one thread	Fallback wherever either condition is missing, so the solve still runs instead of failing

The result is identical; only the time differs. If a solve seems slower than the machine should manage, check first that the browser is current and that nothing else is saturating the CPU.

Why half? Browsers report logical processors, and on most desktops that is two hyperthreads per physical core. An iterative solve is limited by memory bandwidth, so a second thread on the same core adds a participant to every synchronisation without adding bandwidth. Eight is the ceiling because past it the cost of coordinating that many browser workers overtakes the shared work. Settings → Threads overrides the automatic choice for this device — see Solver threads — and the solve monitor shows the count a solve actually ran with.

Hardware

	Practical guidance
Processor	Any current desktop, laptop or tablet. More physical cores help the threaded build directly, up to eight solver threads
Memory	The one real ceiling on model size — see below
Graphics	Anything that runs WebGL, which every current device does
Screen	The workspace lays itself out for a desk monitor, a laptop, a tablet and a phone

Memory is the limit

Because solving happens on your machine, the practical ceiling on model size is the memory the browser can allocate, not a licence tier. A model that fails on a large mesh and succeeds on a coarser one has hit that ceiling. To get under it:

coarsen the mesh where it is not earning its elements (Local refinement);
close other tabs;
use a 64-bit desktop browser, not a mobile one, for the largest models.

Tablets and phones

The whole application runs on a tablet and on a phone, with the same solver. The desk layout — ribbon, properties panel, viewports and table dock — stacks into panels a thumb can drive, and touch targets are sized for a finger. A tablet on site can open the model, solve it and read a reaction; whether you build a large model that way is a matter of taste. See Working across devices.

Connection

Needs the network	Works offline (on a project already opened on that device)
Sign-in, sync, sharing, billing	Modeling, meshing, solving, design checks, report generation

Details, including what to do before a known outage, are in Working offline.

What is not required

No installer or administrator rights. A locked-down corporate laptop or a university lab machine runs it from the browser.
No GPU compute. The solver runs on the CPU; the graphics card only draws the viewport.
No plug-ins or extensions. Import and export — IFC, SAF, DXF, CSV, xlsx, PDF — are all built in.
No licence server, dongle or activation. Sign in and work.

If it will not run

Symptom	Likely cause
The app loads but a solve never starts	Browser too old for the WebAssembly features the solver needs — update it
Solves are much slower than on another machine	Single-threaded fallback, a lowered Threads setting, or a busy CPU — the solve monitor's statistics show the thread count
A large model fails, a small one works	Browser memory — coarsen the mesh or move to a desktop browser
Projects do not sync	No connection, or not signed in — the work is safe locally and merges on reconnect