marp: false

This document maps contractual obligations to modelling work; it does not assume the team's final task allocation.

CLEWs-C2070 — Modelling Workplan (CLEWs Core + FABLE/WS3 Linking)

Author: EL Project: CLEWs-C2070 — Innovative Integration of Climate, Land, and Water into Energy Models for Canada's Net-Zero Commitments (EIP-NES-147, NRCan) Scope of this document: Modelling-side obligations only — the CLEWs energy-system model and the linking layer that exchanges data with FABLE (agriculture) and WS3 (forestry). Stakeholder engagement, Indigenous consultation, web-portal, and dissemination tasks are noted only where they constrain modelling outputs. Source: Deliverables in Contract.pdf (Schedule A, Tasks 1–6) cross-referenced with the project kickoff and framework decks.

1. What the contract obliges on the modelling side

The contract structures the work as six tasks over three fiscal years. Extracting only the modelling content:

The contractual arc on the modelling side is therefore: gap analysis → data structures & soft-linking → validated soft-link → hard-linking & first runs → scenario production runs → final cross-sectoral analysis.

2. CLEWs core modelling tasks

CLEWs is the central optimization hub — an OSeMOSYS extension solving a least-cost capacity-expansion problem to 2070, with land and water accounting layered onto the energy system. The modelling work breaks into the following workstreams.

2.1 Define required model outputs (drives everything else)

Before building inputs, specify what CLEWs must produce: sector coverage, nexus dimensions (energy/land/water), scenario set, and the temporal horizon to 2070. The deliverable results expected — energy, forestry, agricultural, and cross-sectoral outcomes — should be back-cast into a concrete output list. Only then derive the implied input-parameter list (technologies, commodities, resource constraints, emission factors). Specifying outputs first prevents over- or under-building the data layer.

2.2 Inventory review and gap analysis (Task 1)

Audit the two existing inventories — CLEWs-Canada and BC-Nexus (CLEWs-BC) — against the C2070 requirement set:

• What exists, what is missing, what is stale.
• Hard-to-abate sectors not yet represented: heavy industry, aviation, marine shipping, long-haul freight, chemical processes.
• Land and water accounting gaps in the current CLEWs structure (e.g. land-use footprint per technology, freshwater withdrawal/consumption tracking, runoff-based water bounds).

This audit is the substantive content of the Task 1 "structures and workflows document."

2.3 Build the C2070 input dataset

Assemble and document the data layer across the four CLEWs domains. Each parameter needs a source, unit, and temporal/spatial resolution:

• Energy system: technology cost curves (CAPEX/O&M/fuel), demand projections (electricity, heat, transport, industry), availability factors by region/timeslice, emission factors, interconnection/grid topology, storage parameters.
• Climate & hydrology: temperature/precipitation projections (CMIP6), runoff and reservoir inflow series, hydro capacity-factor corrections, cooling-water availability, baseline climatology for calibration.
• Land & agriculture: land-cover classification, yield projections under climate scenarios, land footprint per technology (km²/GW), bioenergy crop potential — food-demand trajectories arrive from FABLE (see §3).
• Forest & biomass: forest inventory (NFIS age/species/volume), growth-and-yield curves, biomass supply curves — harvest schedules and carbon-stock trajectories arrive from WS3 (see §3).

2.4 Represent hard-to-abate sectors and net-zero technologies

Extend CLEWs to model the solution space the project is built around: biomass with/without CCS, green/grey/biomass-derived hydrogen (with land-availability constraints on H₂), forest carbon sink under competing management priorities, and DAC/DACCS (electricity demand and land-use at scale). These are the technologies that answer the central research question — to what extent Canadian land can supply resources and negative emissions to decarbonize hard-to-electrify sectors.

2.5 Scenario design and production runs (Tasks 2, 5)

Translate the stakeholder/Indigenous scenario priorities into model-ready scenario definitions (parameter sets, constraint switches, policy caps). Run the scenarios in Task 5 and structure outputs so they feed the visualization portal.

2.6 Final cross-sectoral analysis (Task 6)

Analyse results across energy, forestry, and agriculture for the final report, drawing out nexus trade-offs that single-sector models miss.

3. Model-linking tasks (CLEWs ↔ FABLE and CLEWs ↔ WS3)

This is the project's core innovation: combining an agricultural model (FABLE) and a forestry model (WS3) into the CLEWs energy system. The contract phases this as soft-linking first (Tasks 2–3), then hard-linking (Task 4).

3.1 Resolve the architecture question first — soft vs. iterative

The single most consequential decision, and it should be settled in internal brainstorming before the workplan is locked: are the WS3 and FABLE linkages truly soft (one-directional, exogenous parameter hand-offs into CLEWs) or do any scenarios require iterative feedback between models (CLEWs results altering FABLE/WS3 assumptions, re-run to convergence)?

This is not a detail — it reshapes scope, interface design, and timeline. A one-directional hand-off is a data-formatting exercise; an iterative loop demands a convergence protocol, stopping criteria, and orchestration logic. Settling it early keeps the rest of the workplan clean.

Critical-thinking prompt for the team: the decks describe the integration as "soft-linked," but the kickoff also commits to "hard-linking via automated workflow tool" in Phase 3. Be precise about terminology — "hard-linking" here appears to mean automated, scripted soft-linkage (no manual file shuffling), not a single merged LP. Confirm this reading, because if any stakeholder expects genuine bidirectional coupling, the architecture changes materially.

3.2 Characterize each model's I/O schema

Document, for FABLE and WS3 independently:

• Input and output variables, formats, units, and temporal/spatial resolution.
• Which outputs need to flow into CLEWs:
• FABLE → CLEWs: food-demand trajectories, agricultural land allocation, diet scenarios, land-use-change GHG.
• WS3 → CLEWs: timber/biomass supply curves, forest carbon stocks, harvest schedules, land-use change.
• Resolution mismatches requiring aggregation or harmonization (e.g. FABLE's land-class scheme vs. CLEWs commodity definitions; WS3 stand-level vs. CLEWs regional zones).

3.3 Design the data supply-chain (soft-linkage) — Task 2

Sketch the linkage architecture: which parameters flow from WS3/FABLE into CLEWs, at what frequency, and through what interface (CSV, a shared data standard, etc.). Explicitly mark each coupling as one-directional or iterative (per §3.1). Build the data-ingestion scripts that pull each model's outputs into CLEWs input format — this code and its repository are the contractual Task 2 deliverable.

3.4 Test, validate, and document the soft-link — Task 3

Run the soft-linked workflow end-to-end. Test that hand-offs are consistent (units, totals, temporal alignment), validate against the existing inventories/literature, and document the linked-workflow concept including any updates discovered during testing. Output: model repository + results, plus an outline of updates to the linked-workflow concept.

Open dependency (from prior project memory): a BC Hydro validation follow-up is outstanding and gates validation claims. Confirm its status before asserting the linked model is validated in Task 3.

3.5 Build the hard-link and run — Task 4

Convert the validated soft-link into an automated workflow tool that runs the model chain without manual intervention. Perform initial hard-linked runs; create, test, and publish the results. Maintain both the separate-model repositories (CLEWs, FABLE, WS3) and a combined-workflow repository — the contract requires both, kept in sync.

4. Repository and reproducibility obligations

The contract and decks tie modelling work to specific open-source artifacts. Plan the repository structure up front:

• Separate GitHub repos for CLEWs, FABLE, and WS3, plus a combined-workflow repo.
• Workflow code and data-ingestion scripts (Task 2 deliverable).
• All input/output .csv data archived (decks reference Zenodo).
• Everything under MIT/Apache licence — every external data source must be audited for open-licensing compliance before ingestion.

5. Suggested critical-path ordering for the modelling team

1. Lock the linkage architecture (soft vs. iterative) — §3.1. Everything downstream depends on it.
2. Define required CLEWs outputs, then derive inputs — §2.1.
3. Gap analysis of CLEWs-Canada + BC-Nexus — §2.2 (Task 1).
4. Characterize FABLE/WS3 I/O schemas in parallel — §3.2.
5. Design and build the soft-linkage + ingestion scripts — §3.3 (Task 2).
6. Test, validate, document the soft-link — §3.4 (Task 3); resolve BC Hydro validation item.
7. Automate into a hard-link; first runs — §3.5 (Task 4).
8. Scenario production runs → portal → final analysis — §2.5–2.6 (Tasks 5–6).

A note on what is not yet pinned down

Two items are anticipations, not settled facts, and should be confirmed in the internal brainstorm before being treated as plan: (i) the soft-vs-iterative linkage decision (§3.1), and (ii) workload assignments, which the project lead (Taco) will set.