RFC-NNNN: #
Field |
Value |
|---|---|
Author(s) |
|
Status |
Draft | Accepted | Accepted-with-changes | Rejected | Deferred | Superseded |
Created |
YYYY-MM-DD |
Decided |
YYYY-MM-DD |
Reviewers |
|
Supersedes |
RFC-____ (if any) |
Superseded by |
RFC-____ (if any) |
Summary#
One paragraph. What is changing and why, in language a new postdoc could follow.
Motivation / Problem#
What is wrong or missing today? What forces this change now? What breaks or stays painful if we do nothing? Be concrete — name the configuration, the user, the failure.
Context & constraints ← (theory transfer: assume the reader does NOT have it in their head)#
What must a reader hold in mind to evaluate this fairly? The relevant parts of the current architecture, the data flow through the affected components, external constraints (HPC memory budget, cluster environment, WMO/Copernicus/UNFCCC obligations, backward-compat promises to existing CIF users). This is the section that lets someone reason about the change instead of just trusting you.
Proposed design#
How it works. Interfaces, data structures, control flow. Diagrams welcome. Enough detail that a reviewer can find the holes — but this is NOT the most important section; the ones around it are.
Alternatives considered ← (this is the theory: the road not taken and WHY)#
For each serious alternative: what it was, and the specific reason it was rejected. “Wrap vs rewrite,” “GP vs NN surrogate,” “DART as subprocess vs reimplementing the analysis step” — the kind of decision where the reasoning is the real asset. Include the option of doing nothing.
Invariants & assumptions affected ← (the tacit “never do X because Y”)#
What currently-true properties could this touch? Check the ones relevant to CIF:
[ ] Adjoint / tangent-linear consistency — does the gradient still match the forward? How verified?
[ ] Numerical reproducibility — do reference results change? Bit-for-bit, or within tolerance?
[ ] Mass conservation / physical invariants in the transport or transform operators.
[ ] Plugin interface contract — are existing plugins (LMDz, FLEXPART, TM5mp, CHIMERE, …) still valid?
[ ] Config / YAML backward compatibility — do existing user setups still run? Migration needed?
[ ] On-disk / output format compatibility.
[ ] Ordering dependencies, global state, or other “obvious to me, invisible to everyone” traps.
Impact#
Affected components / plugins / instruments:
Performance & memory (esp. the host-RAM + GPU-HBM budget):
User-facing changes (config, CLI, outputs):
Documentation that must change:
Validation plan ← (how do we KNOW it’s correct — not just that it runs)#
Which regression/characterization configs cover this? New gradient checks? A benchmark configuration to compare before/after? What tolerance, and why that tolerance? Correctness in a variational inversion framework is numerical, not obvious — make the evidence explicit.
Risks & open questions#
What might go wrong, what you’re unsure about, what you’re explicitly asking reviewers to weigh in on. Honesty here is what makes the review useful.
Rollout / migration#
Phased or big-bang? Deprecation path for anything removed? What existing users must do, and how they’ll be told.
Decision ← (filled in by the decider; this is what turns the RFC into an ADR)#
Outcome: Date / decider: Rationale (esp. if rejected or changed): Follow-up issues / MRs: