Block Formulation Variants

Purpose

This spec defines the two block formulations supported by Cobre — parallel and chronological — which determine how intra-stage time periods (e.g., peak, off-peak, or hourly resolution) are handled in the LP. The choice of block formulation affects water balance constraints, LP size, and the ability to model intra-stage storage dynamics.

For the variable and set definitions used here, see notation conventions. For how blocks integrate into the full LP, see LP formulation. For the system elements that participate in block constraints, see system elements.

1. Parallel Blocks (Default)

In parallel blocks mode, all blocks within a stage are independent — there is no intra-stage storage dynamics.

1.1 Water Balance (Parallel)

A single water balance constraint spans all blocks:

$$v_h={\hat{v}}_h+\zeta \left[a_h+\sum _{k\in \mathcal{K}}{w}_k\cdot {\text{net\_flows}}_{h,k}\right]$$

where:

• $w_k={\tau }_k/{\sum }_j{\tau }_j$ is the block weight
• ${\text{net\_flows}}_{h,k}$ = inflows from upstream − outflows − evaporation − withdrawal

This formulation assumes the reservoir can freely redistribute water across blocks within the stage.

1.2 Characteristics

2. Chronological Blocks

In chronological blocks mode, blocks are sequential within each stage, enabling modeling of intra-stage storage dynamics (e.g., daily cycling patterns within a monthly stage).

2.1 Additional Variables

The end-of-stage storage (state variable) is: $v_h=v_{h,|\mathcal{K}|}$

2.2 Block 1 Water Balance

$$v_{h,1}={\hat{v}}_h+{\zeta }_1\left[a_h\cdot w_1+{\text{net\_flows}}_{h,1}\right]$$

where ${\zeta }_1=0.0036\times {\tau }_1$ is the time conversion for block 1.

2.3 Subsequent Blocks Water Balance

For $k=2,\dots ,|\mathcal{K}|$:

$$v_{h,k}=v_{h,k-1}+{\zeta }_k\left[a_h\cdot w_k+{\text{net\_flows}}_{h,k}\right]$$

2.4 State Variable Definition

Only end-of-stage storage is a state variable:

$$v_h=v_{h,|\mathcal{K}|}$$

Inter-block storages $v_{h,k}$ for $k<|\mathcal{K}|$ are internal LP variables — not state variables. This ensures:

1. Cuts are computed with respect to end-of-stage storage only
2. State dimension does not increase with number of blocks

2.5 Dual Extraction for Cuts

In chronological mode, the storage fixing constraint $v_h^{in}={\hat{v}}_h$ binds the incoming storage LP variable to its trial value (see LP Formulation §4a). The dual of this fixing constraint gives the storage cut coefficient directly:

$${\pi }_h^v={\pi }_h^{fix}$$

By the LP envelope theorem, this dual automatically captures all downstream effects through the chain of inter-block water balances ($v_h^{in}\to v_{h,1}\to \dots \to v_{h,|\mathcal{K}|}$), FPHA constraints, and generic constraints. No special handling or dual combination is required. See Cut Management §2.

2.6 Characteristics

3. Comparison Summary

4. Policy Compatibility Validation

When running in simulation-only, warm-start, or checkpoint resume modes, the block configuration in the current input data must be compatible with the policy (cuts) that was previously trained. Specifically:

1. block_mode must match per stage — cuts trained with parallel blocks encode a different LP structure (water balance, inter-block constraints) than cuts trained with chronological blocks. Using a policy with mismatched block mode produces incorrect future cost evaluations.

2. Block count and durations must match per stage — the number of blocks, their ordering, and their durations (τ_k) affect the LP structure from which cut coefficients were derived. Any change invalidates the existing cuts.

This is a hard validation error — the solver must reject the run if any mismatch is detected.

Scope note: Block configuration is one of many input properties that must be validated for policy compatibility. Other properties include the number of hydro plants, state variable dimensions, AR orders, and system topology. A comprehensive policy compatibility validation specification is planned — see Deferred Features §C.9. Requirements for what metadata the training phase must persist alongside the policy will be defined during the architecture review of Training Loop, Simulation Architecture, and Checkpointing.

5. Future Work: Fine-Grained Temporal Resolution

The current block formulations use a single level of temporal decomposition within each stage: the user defines blocks with durations τ_k, and the LP operates at that resolution in both training and simulation.

A more sophisticated approach — used in commercial tools like PSR’s SDDP (v17.3+) — decomposes each stage into representative typical days, each containing chronological hourly (or sub-hourly) blocks. This enables:

• Accurate modeling of daily cycling patterns (peak/off-peak storage arbitrage)
• Proper representation of intermittent renewable generation profiles
• Separate temporal resolutions for training (aggregated blocks) and simulation (full typical-day profiles)

This feature is deferred because it requires:

• New input data schemas (day-type definitions, weights, hourly profiles)
• Separation of the objective time-weighting (day weight × block duration) from the water balance conversion (block duration only)
• Research into how day types chain within a stage (sequential vs. independent with weighted-average storage)
• Validation against reference implementations

See Deferred Features §C.10 for the full description.

Cross-References

• Notation conventions — variable and set definitions ($v_h$, ${\hat{v}}_h$, $\mathcal{K}$, ${\tau }_k$, $w_k$)
• System elements — hydro plant element description and decision variables
• LP formulation — how block formulations integrate into the assembled LP
• Cut management — cut coefficient extraction from fixing constraint duals (§2)
• Hydro production models — production function constraints that operate within each block
• Input scenarios — per-stage block_mode field in stages.json (§1.5)
• Training loop — training phase that produces the policy (must persist block configuration metadata)
• Simulation architecture — simulation phase that must validate policy compatibility
• Checkpointing — checkpoint format that stores policy metadata for resume validation
• Deferred features — policy compatibility validation (§C.9), fine-grained temporal resolution (§C.10)