Give the AEMO case study an expansion path, and the gap analysis the portfolio's gaps - #12
Closed
thomaschristopherking wants to merge 10 commits into
Closed
Conversation
The case study translated the ISP model to PyPSA and to a Sienna system, and said nothing about the portfolio the third pipeline writes. It now has an expansion section beside the Sienna one: the mappings rows the candidate categories need, the prompts the chain asks in the order it asks them, and the four files the run writes. The run states no measured number. The AEMO model is not in this repository and nobody has counted a portfolio written from it, so the section says as much and points the reader at the decisions.md of their own run. It also says what the chain cannot ask: a chained pipeline prompts for its first leg's source and its last leg's sinks only, so the base year is 2020 unless the two legs are run separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas C. King <thomas.k@transitionzero.org>
The gap analysis covered dispatch fidelity alone. It now carries seven more entries for the portfolio: a constraint over part of the model, a candidate whose build nothing prices, the transmission no technology can build, the requirements a technology names, the target year and the intensity limit a carbon cap has no source for, a storage build priced by its discharge alone, and the periods and representative days that belong to whoever solves the portfolio. Where the subject is an expansion the fourth heading reads "The effect on the expansion", and the header table says so. Three documents claimed a scope the repository has outgrown. The PLEXOS to Sienna page said the translator does not translate capacity expansion, the PLEXOS to PyPSA page called line expansion out of scope because version 1 was dispatch only, and the PyPSA to Sienna page put a genuine expansion problem in the future. Each now points at the investments document, which the README's documentation list also names. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas C. King <thomas.k@transitionzero.org>
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
thomaschristopherking
left a comment
thomaschristopherking
left a comment
Contributor
Author
There was a problem hiding this comment.
Review by /review-fix-cycle.
Labels follow Conventional Comments. (blocking) means the reviewer would not merge without it settled. (non-blocking) means it can land after.
The gap analysis now splits its entries into a section per run, so an entry carries the run it covers in the heading above it rather than in its position in the file. The pointer sentence that named the first expansion entry is gone, and every entry heading drops one level under its section. The constraint entry named one of the three rules that keep a constraint out of the portfolio. It now names all three, and its heading covers the wider subject. Two causes stated something the code does not do: PyPSA refuses a network that prices a build with no discount rate, prices one with no lifetime as a perpetuity, and takes one with no overnight cost for free, and interop's solve command reads no portfolio rather than dispatching a fixed fleet in both directions. The case study now names the fourth Sienna type a generator candidate can take, and the carrier mappings file in PyPSA words that a lone pypsa-to-sienna- investments run asks for and no chain derives for it. The paragraphs stating that nobody measured the expansion path, that the expansion run costs no extra compute, and that a candidate category is what the run is about are gone, as is the second copy of what the portfolio leaves out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas C. King <thomas.k@transitionzero.org>
thomaschristopherking
left a comment
thomaschristopherking
left a comment
Contributor
Author
There was a problem hiding this comment.
Review by /review-fix-cycle.
Labels follow Conventional Comments. (blocking) means the reviewer would not merge without it settled. (non-blocking) means it can land after.
The PyPSA to Sienna implication paragraph said the Investments target was out of scope and then named the pipeline that writes it. It now states the one thing this document does: it is the Operations translation, so it takes the post-solve capacity and drops the expansion parameters, and the investments pipeline translates the expansion problem beside it. The requirements entry in the gap analysis said every technology leaves the list empty. The sink keeps only the fields a table wrote, and no table writes requirements, so the field is absent from the document rather than written as an empty list. The carbon cap entry quoted the schema default for max_tons_mwh and argued that no plan can reach it; the sentence now says only what the reader can check, that nothing limits the carbon intensity of what a plan builds. The unpriced-candidate entry named a Generator and a Battery, and the same rule drops a pumped-storage turbine, so it names the turbine too. The four table headings were defined once in the table and again in the paragraph under it. One row now covers a dispatch and an expansion together. The AEMO case study asked for the user mappings file fourth, before the source and sink prompts. The REPL asks for it after every source, step and sink parameter, so the dispatch table now matches the expansion table below it and the run itself. The pointer to the gap analysis in the headline-number section was the same sentence the expansion section already carries, so it is gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas C. King <thomas.k@transitionzero.org>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas C. King <thomas.k@transitionzero.org>
thomaschristopherking
added this pull request to stack #13
September 9, 2026 09:58
thomaschristopherking
added
review-fix-running
Contributor
Author
|
review-fix-cycle heartbeat: 2026-09-10T14:33:52Z |
…icate This commit answers the round 3 review comments r3-01, r3-02, r3-03, r3-04, r3-05, r3-07, r3-08, r3-09, r3-10, r3-11, r3-12, r3-13 and r3-14. The gap analysis stated one cause three times, that a `CarbonCaps` holds the whole portfolio. The first entry states it, and the other two refer to it. The case study held a table whose cells stated rules, not values. A list of the categories replaces it, and each item names the types and the prime movers that category takes. `translation-from-pypsa-to-sienna.md` said the `pypsa-to-sienna-investments` pipeline translates the expansion problem, and four bullets below it called the same translation unfunded and open. The bullets go. r3-01 asked for a new `translation-from-pypsa-to-sienna-investments.md`. This commit does not write one. It says instead what a PyPSA reader finds in the PLEXOS document, and what that document's source column does not give them. r3-02 asked to replace two paragraphs with a pointer to `#across-all-components`. That section states one of the two rules. This commit points at it for that rule, and keeps the type list and the `storage_kind` rule, which no other document holds. r3-06 and r3-15 are deferred. An automated run acts only on a blocking comment or one that removes lines.
This commit answers the round 4 review comments r4-01 to r4-05, r4-07 to r4-10 and r4-12 to r4-22. Two rules held only by the AEMO case study now sit in `translation-from-plexos-to-sienna-investments.md`, where a reader of another model finds them: the four base system types a generator candidate may name, and how to state a base year other than the default. The case study points at each. Round 3 of this cycle wrote four wrong statements. This commit repairs them: - "the cap above" named the entry above, which is the transmission entry. Deleting the `requirements` entry under r4-04 removes the reference. - "The cap applies to every year of the run" contradicted the cap entry, which states one ceiling for the whole run. - The PLEXOS investments document does not state every field the portfolio holds. Three financial fields appear in no table there. - That document heads its column `From`, not "source". r4-01 asked for a second gap analysis file. This commit does not write one. It gives the entry table one row per run, which answers the part of the comment about a cell that states two cases. A second file reverses r1-01 and r1-20, which round 1 accepted. r4-11 is superseded by r4-19: both delete the same fact, and one copy stays. r4-06, r4-17 and r4-18 are deferred. An automated run acts only on a blocking comment or one that removes lines.
The user asked for each of these, so this commit answers r3-06, r4-17, r4-18, r4-06 and r1-10. The AEMO case study stated that a generator takes the name of its `Fuel` where it burns one. The translator reads the `Fuel` only where the generator also states a `Heat Rate`. The sentence now says so, and it counts the sibling categories of each named category. The `s_nom_extendable` row of the PLEXOS to PyPSA document gave "Version 1 dispatches only" as the reason for `False`. The same document states that a `Generator`, a `Battery` and a pumped-storage turbine do become extendable. The row now gives the reason that holds: the translator writes no expandable line. The SEM and CAISO case studies put the User mappings file prompt after the pipeline prompt. `_prompt_translate` collects the source, step and sink parameters first and asks for the mappings file last, so both tables now put that row at the end. The README named no document for what an expansion loses. The investments bullet now names the gap analysis.
thomaschristopherking
removed
the
review-fix-running
…aemo-expansion-case-study Two files conflicted. `code-review/ledger.jsonl` is an append-only log. The two sides are disjoint: PR 12 appended 74 entries for its rounds 1 to 5, and PR 11 appended 84 entries for its rounds 5 to 18. Both sides are kept in full, with each pull request's rounds contiguous. `docs/translation_mappings/translation-from-plexos-to-sienna-investments.md` merged without a conflict. The parent added skip rules that the gap analysis did not state, so `plexos-to-sienna-gap-analysis.md` now states them: - a constraint must meet five conditions to become a cap, not three. The two new ones are a finite right-hand side and an `Include in LT Plan` of true. - the second leg also drops a candidate whose capacity floor sits above its ceiling, and one whose lifetime is below one year. - it drops a storage candidate that holds no energy, or that puts no upper bound on the energy a build may add.
CARBON_CAP_SKIPS fills a null `applies_to_expansion_plan` as true, so only a constraint that states false is left out.
Contributor
Author
|
Superseded by #14, which squashes this whole stack into one branch off |
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
1 participant
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.
TL;DR
The three branches below this one added a capacity-expansion destination, and no document
told a user how to run it or what it leaves behind: the AEMO case study still had only a
dispatch path and a Sienna path, and the gap analysis covered dispatch fidelity alone. This
adds the expansion path to the case study and seven portfolio entries to the gap analysis.
Fourth and last for transition-zero/tz-infra-interop#116,
stacked on #11. Documentation only — no code changes.
Files to review (7, +265 / -10):
docs/case_studies/aemo-isp-2024.md(start here)### The expansion path, beside the dispatch and Sienna paths.docs/translation_mappings/plexos-to-sienna-gap-analysis.mddocs/translation_mappings/translation-from-plexos-to-sienna.mdImportant
The expansion path states no counts, and the other two paths do. They quote numbers
measured from a real run; the AEMO model is not in this workspace, since
case_study_inputs/holds only its README and the repository commits no model data. Ratherthan write a paragraph explaining the absence, the section simply states no number.
Somebody with the model downloaded should run the path and fill the counts in.
Why
A case study is how a user finds out that a path exists. The expansion path had a pipeline, a
sink and a mapping document but no entry point, so nobody would have found it. The gap
analysis had the opposite problem: it told a reader what a dispatch translation loses, while
saying nothing about a portfolio, which loses different things for different reasons.
How
The expansion path follows the shape the two paths beside it already use: prose, then the
prompt/answer table quoting the CLI's own wording, then the files the run writes. Every prompt
was read out of the
Field(description=...)on each plugin's params rather than guessed.The expansion run needs a mappings file the dispatch run does not. The dispatch section tells
the user to leave the candidate categories out so 170 generators drop; those categories are
exactly what an expansion run is about, so the new section names them and says what each one
takes. Which technology each holds depends on the reader's own copy of the model, and the
section says so rather than asserting it.
The gap analysis keeps its four-part template. Its fourth heading reads "The effect on the
dispatch", which is the wrong question for an expansion, so the header table now says the
heading reads "The effect on the expansion" where the subject is one.
Reviewer notes
base_year. A chained pipeline prompts for its source and itssinks but not for a step, and
base_yearis a step parameter, so a composedplexos-to-sienna-investmentsrun fixes it at 2020. Running the two legs separately setsit. This is a real limitation of the composer, not of this documentation, and it is worth a
follow-up.
user-mappings prompt fourth;
_run_translatecollects the source, step and sink params andonly then asks for the mappings file. The same error is still in
caiso-sa26.mdandsem-2024-2032.md, which this change does not touch.Tests
Documentation only. The suite (624), ruff, mypy and the committed-data lint are green.
CI does not run on this pull request: the workflows trigger on a pull request into
main,and this one targets the branch below it in the stack.
Open workspace in Conductor