fault_split: allow a slit that crosses the boundary transversally (the daylighting contact)

[lmoresi]

Split out of #549, which the ribbon representation resolves (PR #552). The contact (slit) representation still refuses any fault touching the boundary:

fault_split: the fault touches the domain boundary. Only strictly interior
             faults, with both tips ...

The refusal's argument is about tips — the slit would reach the boundary, where the tip-clamping argument fails. That argument is right for a tip and over-broad for a crossing:

• A tip lands on the boundary — keep refusing. The clamping argument genuinely fails there.
• The slit crosses the boundary transversally — a daylighting fault's boundary end is not a tip. It is an edge where the boundary condition differs above and below the slit, which is exactly how Barr & Houseman (GRL 1992; GJI 1996) drive slip: velocity +u0/2 above the fault on the boundary, -u0/2 below.

The substantive work is the boundary labelling: the two sides of the slit at the wall must be separately addressable so a solver can set different conditions across it. That is a design decision about label identity (does the wall label split? does each side get a derived name, as fault_split already mints per-fault boundary values?), not carve plumbing.

The ribbon path went first because it was bounded and unblocks the science; this issue is the second half of the original ask, and the Barr & Houseman boundary-driven configuration is its acceptance test.

Underworld development team with AI support from Claude Code

[lmoresi]

The distinction, located in the code

The refusal in _fault_chain walks every vertex of the fault chain and refuses if any has a domain-boundary facet in its star. It makes no distinction between the two cases, which is why it is over-broad rather than wrong.

The tip-clamping it protects is not in that check at all — it is in _take_sides:

for i in range(1, len(chain) - 1):

The endpoints are skipped. A tip vertex is therefore never duplicated, both sides keep sharing it, and the slip is forced to zero there. That skip IS the clamping argument, expressed as three characters of a range.

So the three cases separate cleanly:

case	what it is	what to do
endpoint strictly interior	a real tip	skip it — clamp, as today
endpoint on the boundary	the fault leaves the domain	split it — no clamping
interior chain vertex on the boundary	the chain runs ALONG the wall	keep refusing; degenerate

What makes it work, and what makes it awkward

Splitting a boundary endpoint is not just "stop skipping it". _take_sides walks the incident cells as a closed fan — from the outgoing fault neighbour around to the incoming one — and refuses if the walk fails to close, on the correct grounds that a non-manifold fan means the orientations cannot be trusted.

At a boundary vertex the star is a half-disc. The walk cannot close, and today that is indistinguishable from the anomaly the refusal exists for. The boundary case needs its own walk: the fault facet and the wall bound each arc, so walking from the fault facet to the wall facet gives one side and the remainder gives the other. It is a genuinely different traversal, not a relaxed guard — and it must stay that way, or the real anomaly stops being caught.

The decision: how the two wall segments are addressed

A daylighting fault cuts the wall it meets into two segments. Barr & Houseman drive slip by putting +u0/2 on one and -u0/2 on the other, so they must be separately addressable — this is the substantive part, and it is an API choice rather than plumbing:

1. Derived labels — mint <wall><name>Plus / <wall><name>Minus (e.g. TopFaultPlus). Explicit, mirrors the existing <name>Plus/<name>Minus convention, costs two labels per outcrop.
2. Reuse the side labels — put the wall facets into the existing <name>Plus/<name>Minus. Fewer names, but those labels then hold both slit facets and wall facets, and the slit's own facets are what a later placement must hold clear of. Mixing the two is likely to bite.
3. Geometric selection — leave one Top label and let users select by coordinate. No new API, but every model re-derives the split point, and it does not survive mesh motion.

Recommending (1): it is the only one where the thing a boundary condition needs to name has a name.

Underworld development team with AI support from Claude Code

[lmoresi]

Ruling on the wall labelling: label the TRACE, not the partition

Maintainer decision, and it overrides the recommendation in my previous comment, which was wrong.

I proposed minting <wall><name>Plus / <wall><name>Minus for the two wall segments. That assumes the outcrop partitions the boundary into two named pieces. It does not generalise:

• On an annulus, the wall is curved and closed; which piece is "Plus" is arbitrary, and the partition depends on where you cut rather than on the physics.
• In 3-D, a fault meets a surface over a finite footprint, not a point. If that footprint is an arc ending inside the surface, it does not divide the surface at all. There are no two segments to name.

So a pre-baked partition is a 2-D-box special case dressed as an API.

What to provide instead: the trace. Label the fault's intersection with the boundary — its nodes and edges (faces in 3-D) — and let users form the intersections and unions their model needs. The trace is well-defined in every geometry and every dimension: it is just where the fault meets the boundary. Whether that trace happens to divide the wall into two, into several, or not at all is then the model's business, and the answer is allowed to differ between a box, an annulus, and a 3-D footprint.

For the Barr & Houseman configuration the user composes the selection they want from Top and the trace, and the same primitive still works when the same fault is run in an annulus, where "upper half of the wall" would have meant nothing.

Consequence for the implementation: the deliverable is a labelled outcrop trace plus the geometry that lets the boundary endpoint split at all (the half-disc fan walk described above). No <wall><name>Plus labels.

Underworld development team with AI support from Claude Code