Four pages: three interactive tokamak modelling scenarios, ordered as a device is actually worked through — design a discharge, model the evolution of its profiles, infer its configuration back from measurements — and one device data page, which computes nothing and brings you what the machine itself recorded (the one of the four that needs a server). ★Every computation of the three scenarios 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.
Four pages
The demo is four pages. The first three are grouped by what they are for, 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. ★The fourth page, device data, is not a scenario and computes nothing: no kernel, no run key — it brings you what the machine itself recorded, and it is therefore the one of the four that needs an mdsip server it can reach.
Pulse design →
One script, three readings of time: configure (one instant, one solve — operating point, inverse shape solve, breakdown), design (the whole pulse → per-channel current and voltage waveforms, a play-head, solved slices told apart from interpolated ones) and simulate (close the switch and the discharge starts; surfaces and profiles evolve, a slider edits the future).
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.
Device data →
Look straight at the machine’s own archive: browse an MDSplus tree, name a shot, pull the signals you pick. ★This page computes nothing — what it shows is what the device recorded, not a result of ours — and it therefore needs an mdsip server it can reach: open it in the single-file viewer (fy --mdsip host:port), or fill one in on the page.
Case report →
Render the record of one case (a fyo plan + an spo record with its outputs inline on the ports) as a report: parameters, ports, readings, line charts against each quantity’s own coordinate, and the poloidal section when a boundary outline is on the record. ★This page computes nothing — what is drawn is decided by a presentation specification; without one it derives the same spec fylite cases --report writes beside its report.
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. 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: one self-contained compute kernel under a very thin assembly layer, with next to nothing pulled in from outside | 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: one and the same kernel serves both, 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 is downloaded on the first visit; every solve thereafter is local.