Three interactive tokamak modelling scenarios, ordered as a device is actually worked through: design a discharge, model the evolution of its profiles, and infer its configuration back from measurements. Every computation runs locally in the browser — nothing to install, no server involved. Most controls answer while being dragged (milliseconds for 0-D, one to two seconds for equilibria); only the self-consistent equilibrium–transport bar of the modelling scenario belongs to the offline tier (seconds) and must be started explicitly.
This is an alpha release. Capabilities and numerical conventions are still moving: interfaces, pages and result formats may change without a migration path. What each capability is judged by, and where its limits are, is on capabilities and limits.
Three scenarios
The demos are grouped by what they are for into three scenarios, in the order a machine is actually worked through: design to model to inference. One scenario is one page and one interface: one compute kernel, one toolbar; the page is a stack of function bars, and each bar has its own run key and its own fold — press the one you want; folding affects reading only. Bars are ordered by the dependencies they declare, and a bar whose upstream has not run yet says so in its strip.
Discharge design →
Which operating point, can the shape be solved for, and can the supplies deliver it. The 0-D bar fixes the point (Ip, loop voltage, fusion power, Q); the shape bar solves the coil currents for a target cross-section and checks them forward; the pulse bar gives the per-channel current and voltage.
Physics modelling / prediction →
How the profiles of a shot come out: 1.5-D core transport at fixed geometry, and the self-consistent loop that feeds the pressure back into a free-boundary equilibrium.
Experiment analysis / inversion →
Recover the equilibrium from flux loops, magnetic probes, POINT and Thomson, with a pressure profile as the kinetic constraint and error bars from a sampled posterior.
fylite and FyTok: one contract, two implementations
fylite is not a standalone program but the light implementation of the fyo semantic contract. The same contract has a heavy implementation — FyTok, a full integrated-modelling framework in Python. The contract sits on the semantics of the IMAS Data Dictionary (DD v4) and addresses physical quantities by semantic path, so the two speak the same language.
| fylite (the light end — this site) | FyTok (the heavy end) | |
|---|---|---|
| What it is | A self-contained equilibrium–transport–turbulence kernel: Grad-Shafranov forward and inverse, the 1.5-D core transport step, neoclassical (NEO) and gyro-Landau-fluid (TGLF) models, 0-D integration, magnetic reconstruction | A full integrated modelling and analysis framework: plugins, workflow scheduling, heterogeneous execution, provenance, and interoperation with existing codes |
| How it is assembled | No plugin machinery — the physics is built in; a Rust kernel with a thin Python assembly layer; numpy is the only dependency | Equilibrium / transport / sources register as plugins: native implementations, wrapped external codes and NN surrogates are interchangeable |
| Where it runs | One machine — or the browser itself: the same kernel compiled to WebAssembly, nothing to install, nothing leaves your computer | HPC clusters and the cloud |
| One run | Sub-second (a free-boundary forward solve is about 0.05 s) — answers while you drag the slider | Ten minutes to hours |
★The light end doubles as the heavy end's minimal functional verification. The two are coded independently against the same contract, so comparing them is a cross-check between implementations rather than a code confirming itself. Below that, each module is held to gold fixtures from its upstream reference (NEO end-to-end at the 10−10 level, TGLF-NN 51 fields within 0.5%), and above it the chain is compared against EAST shots, ITER scenarios and codes such as METIS and FUSE.
The two ends form a loop: the light end gets a capability working, the heavy end produces the high-accuracy reference solution, that solution calibrates reduced and surrogate models, and those go back into the light end as fast models.
Scope and disclaimer
- This distribution embeds the configuration and computational domain of a single device (the ITER machine description, without a reference discharge). Any other device is an input, imported through the device control in the toolbar.
- The reconstruction model carries no vessel-eddy degrees of freedom, and the profile parameters of the forward solve are not the like-named parameters of established reconstruction codes. Differences of a few per cent against published results arise from these simplifications rather than from solver accuracy.
- Configurations obtained from the free-boundary solve are usually classified as limiter-bounded; an X-point constraint changes the field structure and does not force the boundary to be reclassified as diverted.
- This site is a capability demonstration, not an engineering design tool. The configurations and profiles obtained here must not be used as a design basis for any device.
- The 0-D layer performs no transport solve: the analysis tier prescribes its profiles and the prediction tier closes only a zero-dimensional energy balance. Neither is a 1-D transport prediction.
Execution and data
All computation is executed in the visitor own browser. No data is submitted to any server: the parameters set and the results obtained never leave the machine, and are discarded when the page is closed. A single compute kernel (WebAssembly) is downloaded on the first visit; every solve thereafter is local.