The Divertor Problem
We added a divertor to FusionTwin, modeled it wrong, and learned something useful about what a digital twin actually needs to know.
Today we added a divertor to FusionTwin.
Then we immediately modeled it wrong.
That is probably worth writing about.
A divertor is the exhaust system of a tokamak. Plasma particles and heat that cross out of the confined core enter open magnetic field lines and are guided toward dedicated plasma-facing components rather than simply striking the main chamber wall. In conventional tokamak geometry, this magnetic topology includes a separatrix and an X-point; the open field lines form divertor legs that terminate at material targets.
For a future fusion reactor, this is one of the machine's most severe engineering environments. The divertor must help remove heat, helium ash, and impurities while surviving intense plasma-facing loads.
It also creates an interesting control problem.
FusionTwin is intended to explore whether the evolving state of a reactor can be observed as a trajectory rather than a collection of isolated measurements. The divertor may be an unusually good subsystem for testing that idea.
Our first model was wrong
The initial FusionTwin divertor definition was intentionally simple.
We defined two targets:
- an inner target
- an outer target
Each target had a major radius, vertical position, width, and depth.
The renderer then made an incorrect assumption.
It interpreted the target width as an angular distance around the torus. The result was two tiny partial torus segments — technically rendered, but almost invisible in the reactor view.
We called them the metal eyebrows.
The mistake was useful.
The target width was intended to describe the target in the poloidal cross-section of the reactor. It should not determine how far around the toroidal direction the component exists.
We replaced the partial arcs with continuous annular target structures.
The divertor became visible.
It also became obvious that the model is still incomplete.
A ring is not a divertor
Our current renderer places the inner and outer targets on the same horizontal plane.
Visually, they collapse into a broad dark ring beneath the plasma.
That is enough to prove the software architecture works:
reactor definition
↓
component metadata
↓
metadata validation
↓
DivertorRenderer
↓
visible geometry
But it is not yet a physically useful representation of divertor geometry.
A conventional diverted plasma has magnetic geometry that matters. The X-point separates closed and open magnetic field-line regions. Divertor legs extend from that region toward target surfaces, and the locations where the plasma exhaust reaches those surfaces are strike points. Research on lower single-null plasmas explicitly studies behavior above, at, and below the X-point and along the outer divertor leg.
Our current FusionTwin schema knows none of this.
It knows where two metal rings are.
That distinction matters.
What we may change next
The current target definition looks approximately like this:
target
├─ majorRadius
├─ height
├─ width
└─ depth
We are now considering whether a minimum useful divertor model needs to understand additional geometry:
divertor
├─ xPoint
├─ innerLeg
├─ outerLeg
├─ innerTarget
├─ outerTarget
├─ innerStrikePoint
└─ outerStrikePoint
The target surfaces may also need an orientation or angle.
This does not mean FusionTwin needs a full plasma-edge solver.
That would be the wrong goal.
The question is:
What is the smallest physically defensible representation that allows FusionTwin to describe the state and motion of a divertor?
That is the design problem we are working on now.
Why geometry matters to the digital twin
Eventually, we want FusionTwin to observe variables such as target heat flux, radiated power fraction, impurity concentration, neutral pressure, and the location of a detachment or radiation front.
But a value such as:
detachmentFrontPosition = 0.42
means almost nothing without a coordinate system.
0.42 meters from where?
Along which path?
Toward the target?
Toward the X-point?
Along the outer divertor leg?
The geometry gives the state variables physical context.
That is why we stopped before adding heat glow, warning colors, or synthetic sensor data.
The renderer could make the divertor look impressive very quickly.
That does not mean the model would mean anything.
Detachment is where this gets interesting
One long-term FusionTwin experiment may involve divertor detachment.
In a detached divertor, plasma energy and momentum are dissipated before the exhaust reaches the material target. The location and motion of the radiating or detached region can therefore become important state information.
Recent divertor research continues to treat this as a dynamic control problem. A 2026 study of the TCV X-Point Target divertor explicitly examined the dynamic response of detached states to deuterium fueling, nitrogen seeding, and heating perturbations, including the challenge of monitoring detached conditions near an X-point.
Other recent simulation work has reported rapid transitions involving radiation-front motion near and above the X-point before a sharp target-temperature drop and deep detachment.
That suggests a possible FusionTwin question:
Can a digital twin identify the trajectory of a divertor state before the system crosses into an undesirable operating region?
Not by declaring that a target is "hot."
By observing how several related measurements evolve together.
For example:
target heat flux falling
radiated power fraction rising
impurity fraction rising
radiation front moving upstream
core radiation beginning to increase
Any individual value may still be acceptable.
The trajectory may not be.
That is the kind of problem FusionTwin is being built to explore.
Current status
The divertor is now a first-class FusionTwin component.
Its geometry is defined in the reactor JSON.
Its metadata is validated before rendering.
It has a dedicated renderer.
And its first visual implementation exposed a weakness in our physical model almost immediately.
That is progress.
The next step is not to make the divertor prettier.
The next step is to determine the minimum geometry FusionTwin needs to represent the X-point, divertor legs, targets, and strike points without pretending to be a full plasma simulation.
Then we can begin giving the divertor a state.
And once it has a state, we can give it a history.
That is where the digital twin starts becoming interesting.