Figure: where the rotation lives under rotated boundary conditions - #599
Open
lmoresi wants to merge 1 commit into
Open
Figure: where the rotation lives under rotated boundary conditions#599lmoresi wants to merge 1 commit into
lmoresi wants to merge 1 commit into
Conversation
Drawn for the boundary-conditions note (R1 in the technical-notes writing plan), which is not yet written. Parked here rather than left in a scratch directory: it follows the per-figure layout the cetz skill documents, and it moves to the note's own examples/ and figures/ when that article is created. Two panels. The left is a free surface with an inflection -- rising on the left, falling on the right -- so the outward normal swings through a wide range and the curvature changes sign. That is the case no global coordinate system straightens out, which is why rotating each node's frame is the general answer and solving in spherical components is not. The right is where the rotation actually lives, and the point is that it is contained. The velocity solve is rotated and carries its multigrid with it; the fieldsplit / Schur solve abuts it and never handles a rotated vector, because the pressure block carries no boundary condition of this kind. One un-rotation sits on the boundary between them and feeds both the Schur solve and everything downstream. Geometry is generated in Python and handed to Typst as JSON, per the skill: a real Delaunay triangulation, culled by centroid against the non-convex surface, with alternate rows staggered so the triangles are not degenerate. Underworld development team with AI support from Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Drawn for R1 in the technical-notes writing plan (Boundary conditions on non-planar boundaries), which is not yet written. Parked here rather than left in a scratch directory that would not survive the session — it follows the per-figure layout the cetz skill documents, and moves to the note's own
examples/andfigures/when that article is created.What it argues
Left: a free surface with an inflection — rising on the left, falling on the right — so the outward normal swings through a wide range and the curvature changes sign. That is precisely the case no global coordinate system straightens out, which is why a per-node rotation is the general answer and solving in spherical components is not.
Right: where the rotation lives, and the point is that it is contained. The velocity solve is rotated and carries its multigrid with it. The fieldsplit / Schur solve abuts it and never handles a rotated vector, because the pressure block carries no boundary condition of this kind. A single un-rotation sits on the boundary between them and branches — into the Schur solve, and out to output, advection and the surface update.
Four operations genuinely carry
Q: the operator, the right-hand side, the solution, and the prolongation. The Galerkin coarse operators inherit it viaRAPand the SVD coarse solve follows from what they inherit, so those are drawn as consequences rather than as further obligations.Reproducibility
generate-rotated-basis.py→rotated-basis-data.json→rotated-basis.typ→ PNG and SVG. Geometry is computed in Python and handed to Typst as JSON, per the skill's rule: a real Delaunay triangulation, culled by centroid against the non-convex surface, with alternate rows staggered so the triangles are not degenerate. Verified to rebuild from the committed sources.Companion to #598, which corrects the cetz gotchas this figure turned up.
Underworld development team with AI support from Claude Code