Stochasm

User Guide Open the app ↗

Building systems — designing each model in the Builder

The middle stage of the workflow. Once the Launcher has picked a model, the Builder is where you shape what the system is — its palette, its rules, its particles. Each model has its own design surface, and the sections below are the in-depth reference for each. How a system behaves once it runs is the next chapter, Simulating systems.

The Builder

Press Next in the Launcher and the Builder card arrives. It holds three kinds of control, top to bottom: the System seed knobs (lattice size or disc count, and — in ensemble mode — the number of systems), the model’s structure editors (detailed per model below), and the shared Compute card (engine, workers, cell lists). Every edit re-seeds the live preview on the stage, so you always see exactly what will launch. Press Initialize and the previewed system becomes the running one; its structure is then fixed, and the header’s Back to Builder returns you here to change it (the run is discarded, the design kept). The seed knobs and the setup flow are covered in Setting up → The Builder.

Multi-Component Lattice

The lattice model’s structure is its site types — the palette — and its rules — how those sites transform, move, and interact. Both are edited here in the Builder and shown read-only while a system runs (colours stay live everywhere; they’re display, not physics).

Site types

Sites are the coloured squares your lattice is made of — up to ten types per system (minimum two). The type count itself is a Builder decision: add or remove types here (removing one re-indexes the rules and repaints its sites), then Initialize. Each type carries:

PropertyMeaning
NameA label for your convenience — no effect on the physics.
ColourHow the type is drawn, everywhere: lattice, statistics, plots, matrices. (The one property you can still retune during a run.)
Default initial occupancyThe type's relative share when the lattice is seeded randomly (the default seed — it does not apply when a system starts from an imported snapshot). Edits re-seed the preview live.
ImmobileThe type never moves: swap rules cannot displace it.
Masquerade as…For facilitation counting only, this type "pretends" to be another — a way to let several species jointly satisfy a kinetic constraint.
Site H-fieldThe type's energetic bias (in units of kBT). Its value is tuned live in the Simulation stage; transformations run "downhill" — from high-field types toward low-field ones — see the science.
The Site Types editor beside a four-type lattice — names, colours, occupancy, immobility, masquerade.
The Site Types editor beside a four-type lattice — names, colours, occupancy, immobility, masquerade.

Rules

Rules are the verbs of your system. There are four kinds, each with its own glyph (drawn between the two endpoint swatches) and matrix code:

FI Irreversible Flip — a site of type A becomes type B, one way only.
FR Reversible Flip — A becomes B and B becomes A, both governed by the same parameter.
SW Swap — adjacent A and B sites exchange places. This is how things move. Immobile types refuse.
SS Site-Site Interaction — not a move at all, but an energy: attraction or repulsion between neighbouring A and B sites that biases every other rule.

A rule’s structure — its name, kind, and two endpoints — is fixed here in the Builder (endpoints and kind can’t change once created; delete and re-create to change them). Each rule names a specific type on each end, or the any-site wildcard. Its parameter — the raw attempt-weight for flips and swaps (0–1), or the interaction energy for a Site-Site rule (−10 to +10 kBT, negative = attraction) — is tuned live once the system runs, under Simulation → Rule Controls.

Facilitation. A flip rule can be made conditional on the neighbourhood: set Requires Neighbour Site to some type and a # of Neighbours Required (1–8), and the flip only fires at sites with at least that many neighbours of that type. This is the ingredient of kinetically-constrained models — the FA preset is exactly one facilitated flip. Masquerading types count toward the requirement of the type they imitate.

The interaction matrix. The Builder shows a type-by-type matrix of your Site-Site Interactions and facilitation gates as symbolic dots; once running, the same matrix under Simulation carries the live SS energies and f(●)×n facilitation chips. If two enabled SS rules address the same pair, the later one wins and the matrix flags the duplication with an amber warning.

2D Ising

The Ising model has no palette to build — every site is one of two spins. Its Builder is minimal: the lattice size and, in ensemble mode, the number of systems, plus a starting condition (hot, cold, or aligned up/down) chosen in the Launcher. Everything that shapes its behaviour — temperature, coupling, field — is a live control in the Simulation stage.

Single Particle

The single particle’s “structure” is the potential it lives in. You choose a single well (a harmonic trap set by its frequency) or a double well (set by a separation/depth and a left/right bias); the Builder itself only sets the ensemble size. The potential shape and the rest of the Langevin dynamics — temperature and friction — are tuned in the Simulation stage.

Patchy Discs

Patchy Discs is the off-lattice member of the family, so its structure is a particle design rather than a palette. The moving parts: disc species (size, colour, abundance), patch types (the coloured triangles riding on disc rims — each triangle’s tip points along its bonding direction), and rules — either patch–patch bonds or disc–disc attractions.

Designing particles

The Particle design editor has three levels. Patch types are the bonding species — a name and a colour, drawn as triangles everywhere they appear. Below them, each disc species carries a name, colour, radius, abundance (its share of the box population), and its list of patches — each one a patch type placed at a rim angle in degrees. Add and remove freely; every edit re-seeds the box preview live, so it always shows what will launch. Patches are optional — strip them all (and even remove every patch type) for bare discs that interact only through their soft core plus any disc–disc attractions; the patch-bond matrix and the patch–patch rule kind simply disappear when no disc carries a patch. During a run the design is read-only (colours stay tunable — display only); to change anything structural, press Back to Builder.

Interaction rules

Every rule has a kind, chosen when you create it. A Patch–Patch rule makes one pair of patch types bindable — a directional Kern–Frenkel bond, formed and broken by Monte Carlo. A Disc–Disc rule adds an isotropic Lennard-Jones attraction between two disc species — a soft well of tunable depth that the molecular dynamics handles directly, no bonds involved (so it can drive condensation and demixing). Both live in the same list, tagged BOND or LJ; with no rules at all, discs feel only their hard core.

Rule structure — a name, the kind, and the two endpoints (patch types for a bond, species for an attraction) — is fixed at creation, so delete and re-create to change it. The dynamics are tuned live under Simulation: the strength ε (bond well depth, or LJ well depth) for either kind, plus the bind/unbind attempt rate for patch–patch bonds only. Toggle a rule off there to remove its interaction mid-run. Two matrices summarise it all — a patch-bond matrix and a separate disc–disc matrix — symbolic dots here in the Builder, live ε values under Simulation; only the lower triangle is shown, since both interactions are symmetric.

© Nicholas B. Tito · Stochasm — explore statistical thermodynamics, machine learning, and create digital art.