Found while auditing the cut-in-band configuration (a centre-line slit inside a place_thin_volume ribbon, the listric2-hybrid workflow).
What happens
cut_along_lines snaps the nearest vertex onto the line (snap_frac, measured along crossed edges). In a band whose half-width is inside the snap reach of the local cell size — a w = 0.02 band meshed at the 0.9w default has rails only 0.010 from the centre-line, with zone cells ~0.018 — a cut sample can land so that the nearest capturable vertex is a rail (zone/host boundary) vertex. Measured: one rail vertex dragged to n = 0 at the cut's midpoint, pinching the band to zero width on one side. Connectivity stays intact, the quality guard does not fire (the snapped mesh is acceptable), and every advertised invariant of the cut still holds — doubled pairs on the line to 1e-16, no-opening at 5.6e-17 — so nothing refuses. The band geometry is silently wrong at that point, and the label-boundary distortion is visible only in a render (@lmoresi spotted it in the shading).
Sampling the cut finer does not fix it: at the zone's own node spacing the same mesh trips the inversion guard instead (snapping inverted 3 cell(s)). There is no snap parameter that guarantees rail safety, because snap_frac is blind to a vertex's distance from the line and snap_quality trades refused snaps for split slivers.
Prevention that works (measured)
Give the cut a spine to consume: mesh the band transfinite with three nodes across (rails + an exact centre-line row, edge-connected, at rail spacing) and sample the cut polyline at those vertices. Then every crossing lands on an existing vertex, nothing snaps, nothing is inserted:
|
default band + cut |
3-across transfinite + cut |
| rail vertices moved |
1 (band pinched shut) |
0 |
| min angle |
32.2° → 13.0° |
28.8° → 28.8° |
| zone cells |
104 → 144 (re-triangulated) |
132 → 132 (untouched) |
| mid-fault slip (pairing) |
0.4290 |
0.4315 |
| no-opening leak |
5.6e-17 |
5.6e-17 |
Scripts: ~/+Simulations/ribbon_network_2d/ (cut_audit.py, cut_ladder.py).
Possible actions
- A guard:
cut_along_lines could refuse (or warn) when a snap would move a vertex that lies on a label boundary — the information is in the plex, and the failure is silent today. Cheap, catches the trap wherever it occurs.
- A cut-ready band:
place_thin_volume option for a structured (transfinite) band with a centre-line vertex row, valid for a straight isolated ribbon only (a fused union is not four-sided). This is the configuration that makes cut-in-band exact and quality-neutral, and it is also the natural home for the fault-node instrument (P0 properties mapped to spine nodes).
- Plumbing:
add_fault currently exposes none of cut_along_lines' snap knobs; whether or not 1/2 happen, passing them through costs nothing.
Underworld development team with AI support from Claude Code
Found while auditing the cut-in-band configuration (a centre-line slit inside a
place_thin_volumeribbon, the listric2-hybrid workflow).What happens
cut_along_linessnaps the nearest vertex onto the line (snap_frac, measured along crossed edges). In a band whose half-width is inside the snap reach of the local cell size — aw = 0.02band meshed at the 0.9w default has rails only 0.010 from the centre-line, with zone cells ~0.018 — a cut sample can land so that the nearest capturable vertex is a rail (zone/host boundary) vertex. Measured: one rail vertex dragged ton = 0at the cut's midpoint, pinching the band to zero width on one side. Connectivity stays intact, the quality guard does not fire (the snapped mesh is acceptable), and every advertised invariant of the cut still holds — doubled pairs on the line to 1e-16, no-opening at 5.6e-17 — so nothing refuses. The band geometry is silently wrong at that point, and the label-boundary distortion is visible only in a render (@lmoresi spotted it in the shading).Sampling the cut finer does not fix it: at the zone's own node spacing the same mesh trips the inversion guard instead (
snapping inverted 3 cell(s)). There is no snap parameter that guarantees rail safety, becausesnap_fracis blind to a vertex's distance from the line andsnap_qualitytrades refused snaps for split slivers.Prevention that works (measured)
Give the cut a spine to consume: mesh the band transfinite with three nodes across (rails + an exact centre-line row, edge-connected, at rail spacing) and sample the cut polyline at those vertices. Then every crossing lands on an existing vertex, nothing snaps, nothing is inserted:
Scripts:
~/+Simulations/ribbon_network_2d/(cut_audit.py,cut_ladder.py).Possible actions
cut_along_linescould refuse (or warn) when a snap would move a vertex that lies on a label boundary — the information is in the plex, and the failure is silent today. Cheap, catches the trap wherever it occurs.place_thin_volumeoption for a structured (transfinite) band with a centre-line vertex row, valid for a straight isolated ribbon only (a fused union is not four-sided). This is the configuration that makes cut-in-band exact and quality-neutral, and it is also the natural home for the fault-node instrument (P0 properties mapped to spine nodes).add_faultcurrently exposes none ofcut_along_lines' snap knobs; whether or not 1/2 happen, passing them through costs nothing.Underworld development team with AI support from Claude Code