task: investigate where chil file format can be used in the existing codebase

[domattioli]

Background

#154

do we have I/O built out? what else might we need (eg converting to/ from other file formats?)

Scope

saving .chil files, beyond examples, in the repo is not in scope

Tasks / checklist

brainstorm this

Acceptance criteria

brainstorm this

Priority

priority:medium

Routine session eligibility

• This task is suitable for autonomous Claude Code routine sessions

Related issues, docs, or external references

#154

[domattioli]

Investigation: .chil integration surface

Brainstorm done → docs/CHIL_FORMAT_INVESTIGATION.md (commit 4ef7952, on development/PR #195). Summary:

I/O already built (the "do we have I/O?" question): fort.14 read+write, .2dm read+write (write is private _write_2dm), gmsh .msh v2.2+v4.1 read+write, plus from_admesh_domain(record) registry bridge. CHILmesh.save/load already dispatch by file suffix → that dispatch is the natural seam. .chil exists nowhere in src/.

Integration is localized — slots in as one more adapter (gmsh_io.py precedent), not a new API shape:

1. new src/chilmesh/chil_io.py (read_chil/write_chil)
2. two suffix branches in save/load (CHILmesh.py:2346/2354)
3. from_admesh_domain as primary producer (per .chil file format design — session byproduct, decisions, and adversarial review #154 Q14, .chil = registry-canonical)
4. existing fort.14/2dm/msh writers become the "export OUT of .chil" adapters — no new code

Gaps the object model lacks for .chil v1 (the "what else do we need?"):

• No CRS field → conflicts with constitution Principle V (coords opaque) — the .chil file format design — session byproduct, decisions, and adversarial review #154 D9 HIGH blocker
• No fort.13 nodal-attribute I/O → "lossless fort.14+fort.13 round-trip" unmet
• No Domain Boundary concept (only mesh boundary_segments)
• No content hash / content_uid (lives in ADMESH-Domains, not here)
• No coordinate quantization / canonical winding

Recommendation: geometry payload is ~90% there (points + connectivity + boundary already serialized by the fort.14 path). Smallest constitution-safe step = an export-only write_chil for kind="mesh" with CRS passthrough (native="unknown", no WGS84 transform, no Identity hash). Defer the Identity/CRS/hash half upstream to ADMESH-Domains where the heavy deps (shapely/pyproj) + curation already live — keeps CHILmesh's minimal base install intact and respects Principle VI (don't privilege one format). fort.13 reader/writer is the highest-value standalone prerequisite.

Also flagged: Principle VI text says 2dm "write support future" but _write_2dm already ships — doc drift, separate cleanup.

Leaving open (status: brainstorming) — this is design input for a future .chil v1 spec, gated on the #154 RESHAPE blockers (constitution reconciliation) which are operator/cross-repo decisions.

[model: claude-opus-4-8, repo: CHILmesh, session: 2026-06-09T16Z-routine]

---

Generated by Claude Code

[domattioli]

Fable review — .chil format vs global (spec-048) + local plans (operator ask on MADMESHing#48)

Inputs: #154 design record + adversarial RESHAPE · docs/CHIL_FORMAT_INVESTIGATION.md · MADMESHing specs/048-ecosystem-reorg/spec.md · Valence/CHILmesh constitutions.

Verdict

.chil and spec-048 are compatible but currently disconnected — spec-048 never mentions .chil, yet they collide on three exact points. Format needs refinement (RESHAPE stands), but the refinements are enumerable + none block spec-048 P1–P3.

Global-plan impact (spec-048)

1. No blocking coupling with P1–P4. Contract tests, quality dedup, _topology.py shims, distribution — all orthogonal to .chil. .chil runs as a parallel M2 track. One cheap hedge: T1's contract test should pin CHILmesh.save/load suffix dispatch (CHILmesh.py:2346/2354) — that's the seam .chil extends; pin it before anything migrates onto it.
2. .chil ↔ D5/P6 are coupled decisions. .chil file format design — session byproduct, decisions, and adversarial review #154 Q14 makes fort.14/2dm/msh "export adapters writing OUT of .chil" — that's P6-T20 (single parser) + T21 (single mesh type) in different words, and it makes CHILmesh the conversion hub exactly as spec-048's greenfield charter proposes ("CHILmesh owns all fort.14/.2dm I/O"). Operator should decide D5 (ADR-001 keep/supersede) and Q14 scope together, not separately: keeping ADR-001 (ADMESH keeps its own fort.14 parser) is fine for the registry storing .chil, but kills "one parser" purity. Compatible either way — just don't let two threads decide it twice.
3. Dep-graph conflict (the real one). Spec-048 target graph: Valence depends on nothing, base install light (FR-013, Valence constitution Principle II). .chil file format design — session byproduct, decisions, and adversarial review #154 D6/D9/D15 HIGHs: .chil Identity needs shapely+pyproj, container needs numpy. Resolution = ownership split: CHILmesh owns geometry-payload read/write (numpy already a hard dep there); Valence owns canonicalization+hash behind a [chil] extra; the registry query path stays stdlib-only — achievable because manifest.toml inside the zip is readable via zipfile+tomllib with zero deps, IF all query-relevant metadata lives in the manifest (next point).

Format refinements required before a v1 spec (priority order)

1. Multi-ring at v1 — WNAT_Hagen (Bermuda ring) is the flagship; a canonical format that can't hash the canonical Domain is dead on arrival (.chil file format design — session byproduct, decisions, and adversarial review #154 unresolved Q4).
2. Synthetic / no-CRS mode — crs.native = "synthetic", no WGS84 transform, Identity = hash over canonical bytes. 21/41 meshes + 5/13 Domains are non-geographic; without this the format excludes half the registry (.chil file format design — session byproduct, decisions, and adversarial review #154 D1/D9).
3. Stdlib-queryable manifest — mandate manifest.toml as first archive entry (or sidecar) carrying every browse/query field (bbox, counts, kind, provenance, lineage). Resolves the numpy-to-read HIGH (D15) + preserves Valence Principle II + keeps HF partial-fetch viable.
4. Identity ownership split (above) — also resolves CHILmesh Principle V conflict (D9): CHILmesh never transforms coords; export-only write_chil with CRS passthrough per the existing task: investigate where chil file format can be used in the existing codebase #201 investigation recommendation, which I endorse.
5. Keep kind ∈ {"mesh","boundary"} — map .chil file format design — session byproduct, decisions, and adversarial review #154's "domain_only" onto already-shipped "boundary" instead of renaming; avoids SCHEMA_VERSION bump + the third overload of kind (D12).
6. Design the sha256-v2 upgrade lever in the same patch as v1 — quantization is a one-way door (.chil file format design — session byproduct, decisions, and adversarial review #154 unresolved Q5); ship the alias-bridge story now, even unimplemented.
7. Drop D19 confidence tiers — contradicts D4 deterministic-Identity; Curator-always-approves + browse-only Relatedness already covers the need.
8. Ingest shipped provenance/lineage strings at v1 (D13) — the data exists on 4 WNAT meshes; deferral drops live curatorial info.

Local-plan impact (CHILmesh)

• Prior task: investigate where chil file format can be used in the existing codebase #201 recommendation (export-only write_chil, kind="mesh", CRS passthrough, defer Identity upstream) is the right smallest step — unchanged by this review.
• fort.13 reader/writer is the highest-value standalone prereq (needed for "lossless fort.14+fort.13" Q11; useful to ADCIRC users with or without .chil). Candidate next CHILmesh slice after MutableMesh.merge_elements is stub — needed for aggressive tri routing in quadmesh #132/Expose public ccw_edges_around_vert helper to avoid duplication in downstream consumers #133.
• Sequencing: .chil work stays gated on .chil file format design — session byproduct, decisions, and adversarial review #154 constitution reconciliation (operator); nothing in spec-048 P1–P3 waits on it, nothing in .chil waits on P1–P3.

Cross-ref: MADMESHing#48 (overhaul map). Routing: this is design input for the future .chil v1 spec — leaving status: brainstorming.

[model: claude-fable-5, repo: DomI-hub-session, session: 2026-06-11T12Z-overhaul]

---

Generated by Claude Code

[domattioli]

fort.13 reader/writer shipped — the "highest-value standalone prereq" from this thread

Both prior comments here nominated fort.13 read/write as the highest-value standalone I/O prerequisite for .chil v1's lossless fort.14+fort.13 round-trip (Q11) and as the candidate next CHILmesh slice after #132/#133 (both done). Shipped this slot:

• New standalone module chilmesh.fort13_io: read_fort13 / write_fort13 + Fort13 / NodalAttribute dataclasses, exported from chilmesh. Handles 1-based↔0-based node-id conversion, multi-component (values_per_node > 1) attributes, default + sparse-nondefault overlay via Fort13.dense(), Fort13ParseError on malformed input.
• Purely additive — no touch to locked stage modules or save/load dispatch (gmsh_io.py precedent). Keeps the .chil Identity/CRS/hash half deferred upstream per this thread's standing recommendation.
• 5 round-trip/parse tests + tests/fixtures/fort13/sample.13; 0 regressions. 83f6229 → rolling PR #210.

This unblocks the fort.14+fort.13 lossless-round-trip line item whenever a .chil v1 spec lands (still gated on the #154 constitution-reconciliation decisions — operator/cross-repo, unchanged). Leaving #201 open (status: brainstorming) as the .chil-design thread.

Known v1 limitation for follow-up: an empty units string would desync the blank-line-skipping parser; ADCIRC units are never empty, so out of scope for v1.

[model: claude-opus-4-8, repo: CHILmesh, session: 2026-06-13T20Z-rotation]

---

Generated by Claude Code