Repository navigation
Boundary-condition aliases expand into the abstract forms; closure records the expansion - #26
Merged
Merged
Conversation
cekees's review note of 2026-11-04: Dirichlet, Neumann and Robin are the
abstract forms, each complete with its expression; slip, open, inflow and
characteristic, and a model's condition sets, are shorthand whose meaning
lived only in code (symbolic/split.py, units.py's _VALUE_KINDS, proteus's
dispatch). A closed spec that says `type: slip` does not say what was
solved, so two solvers could close it differently and the archive could
not show which.
ymf.conditions (stdlib, spec core) defines each alias as data, ALIASES:
- slip (a vector): Dirichlet on the normal component, the value (0 if none
is given); Neumann on the tangential component, 0 (no tangential
traction);
- open: Neumann 0, the natural condition, declared (C12);
- inflow: Dirichlet, the value, only where the flow enters;
- characteristic: Dirichlet, the value, only through the incoming
characteristics.
expand_condition turns one condition into those components, carrying its
region, variable, value (value, formula or series, with units) and
`expanded_from: {type: <alias>[, set: <set>]}`. expand(doc) expands every
alias and every applied condition set of a document, in order, removes
condition_sets and boundary_sets, keeps their names in expanded_from, and
writes each condition's keys in one order; it is idempotent, and a
document with no alias and no set comes back as the same object.
The schema takes the expanded form's keys on any condition: component
(normal | tangential), only (inflow | incoming_characteristics), imposed
(strong | weak: C12 makes how a condition is imposed a property of that
condition) and expanded_from. Nothing reads them yet; the next commits
make closure write the expansion and every reader consume only it.
Measured: the dam break (free_slip on walls, atmosphere on top) expands
to v Dirichlet normal 0 and Neumann tangential 0 on walls; p Dirichlet 0,
v Neumann 0 and χ Dirichlet 1 only on inflow on top; Torino to q slip's
two components on walls and q Neumann 0 on the open end; both idempotent.
ymf suite 821 passed, 2 skipped (was 809 on cekees/main a44cee1; 12 new
in tests/test_condition_expansion.py), macOS arm64, petsc-dev env.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The closure of a spec (its archive, ymf_state closed) now records what is solved: closure.write writes the realized spec with its boundary-condition aliases and condition sets expanded into Dirichlet, Neumann and Robin conditions (ymf.conditions.expand), each carrying expanded_from with the alias and set it came from, and without condition_sets/boundary_sets. Output keys follow the same rule: closure.input_slice takes the expanded document, so a spec and the archive it closes into key their outputs alike, and a spec whose conditions are written out by hand keys as its aliased twin would but for the provenance. expand returns a document without shorthand unchanged, so such specs keep their keys. Measured: of the 11 well-posed specs among ymf's examples and test fixtures, the 8 without aliases or sets plan exactly the keys they did on cekees/main a44cee1; the dam break, Torino and lake-at-rest fixtures, which use sets, plan new keys, over the expansion. Each of those three closed with closure.write reloads with the expanded conditions only, the same planned keys as its spec, and rewrites byte-identically. The dam break with its sets and the dam break with the five expanded conditions written by hand close to equal documents once expanded_from and the composition record are set aside. ymf suite 825 passed, 2 skipped (was 821; 4 new), macOS arm64, petsc-dev env. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ias is
adr_problem, split_problem and ymf.units now expand a document's aliases
and condition sets first (ymf.conditions.expand) and read only abstract
conditions, so what they see is what the closure records:
- split_problem's per-sub-problem conditions are Dirichlet/Neumann/Robin
/periodic entries carrying component, only, imposed and expanded_from
(no `set` key: the set is in expanded_from); the slip special cases in
split._conditions are gone (a projected value is one number, the default
0 comes from the alias table).
- adr_problem, one ADR system, runs Dirichlet, Neumann and Robin on whole
variables; a condition on a component, restricted with `only` or imposed
weakly is refused, naming what it expanded from ("a dirichlet condition
on the normal component (expanded from slip) runs in a split
discretization's solver").
- ymf.units checks the expanded conditions (a slip's normal Dirichlet as
[g] = [u]); _VALUE_KINDS, the code-only meaning of the aliases, is gone;
an issue's location names the alias and set it expanded from.
- Load-time checks: a `component` is a vector's, as slip already was.
Tests that asserted alias types in readers' output now assert the
expansion: test_split (the dam break's flow gets v Dirichlet normal and
Neumann tangential on the walls, p Dirichlet and v Neumann on the top; VOF
gets χ Dirichlet only on inflow, through χh), test_shallow_water (the
lake's walls and Torino's walls and open end), test_boundary_kinds (the
refusal message). The guide's table of kinds becomes the table of aliases
and their expansions, with the rule that the closure records the
expansion.
Measured: ymf suite 827 passed, 2 skipped (was 825; 2 new, 5 rewritten);
ymf[symbolic] alone passes too; macOS arm64, petsc-dev env.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Boundary-condition aliases expand into the abstract forms; closure records the expansion
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.
No description provided.