wip

Signed-off-by: Davey Elder <iandavidelder@gmail.com>

Author: idelder

docs/source/extensions/unit_commitment.rst

@@ -5,9 +5,8 @@ Unit Commitment
 
 The **unit_commitment** extension adds commitment-level operational constraints
 to selected technologies: online/started/stopped unit accounting, minimum
-output floors, maximum output ceilings (replacing the default capacity
-constraint), and minimum up-time and down-time windows.  It also supports
-discounted startup costs and startup emissions and input flows.
+output floors, maximum output ceilings, and minimum up-time and down-time windows.
+It also supports discounted startup costs and startup emissions and input flows.
 
 It is disabled by default and enabled per run through configuration:
 
@@ -32,9 +31,33 @@ and :math:`\textbf{UCSP}` (stopped) — count whole units and are promoted to no
 integers by default (MIP).  In **linearized mode** (:code:`linearized = 1`), these
 variables are kept continuous.  This is equivalent to imagining that :math:`UC_{r,t}` is
 infinitesimally small: the commitment variables become fractional occupancy factors rather
-than discrete unit counts, and the min-output/max-output bounds act as simple lower and
-upper capacity-factor constraints without any integer requirements.  Linearized mode is
-useful for reducing solve time during early model development or sensitivity analysis.
+than discrete unit counts, and the min-output bound acts as a simple lower capacity-factor
+constraint without any integer requirements.  Linearized mode is useful for reducing solve
+time.
+
+Integration with Core Constraints
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For some existing core constraints, the extension overrides a utility function —
+:func:`~temoa.components.utils.get_available_output` — that computes
+the maximum available output for a process in a given time slice.  For UC technologies,
+this function returns a commitment-aware expression based on online units rather than total
+installed capacity.  Because this function is used throughout the core model, the following
+constraints automatically become UC-aware for registered technologies with no further changes:
+
+- :code:`capacity_constraint` — output bounded by online capacity
+- :code:`storage_charge_rate_constraint`, :code:`storage_discharge_rate_constraint`,
+  :code:`storage_throughput_constraint` — storage rates scale with online units
+- :code:`reserve_margin_constraint` (dynamic mode only) — reserve contribution from online units only
+
+Ramp constraints are the only exception: they require explicit knowledge of
+started/stopped units to compute the ramp envelope and are therefore fully replaced by
+UC-aware versions for technologies that appear in both :code:`unit_commitment` and the
+ramp tables.
+
+.. autofunction:: temoa.components.utils.available_output_base
+
+.. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_available_output
 
 .. warning::
 
@@ -51,13 +74,6 @@ useful for reducing solve time during early model development or sensitivity ana
    :code:`linearized = 1` in the :code:`unit_commitment` table for a
    particular technology to keep those variables continuous (LP relaxation).
 
-.. note::
-
-   The :code:`uc_max_output_constraint` **replaces** the default
-   :code:`capacity_constraint` for processes listed in the
-   :code:`unit_commitment` table.  Non-UC processes retain the standard
-   capacity constraint unchanged.
-
 Overview
 --------
 
@@ -70,7 +86,7 @@ Overview
      - Key interaction
    * - :code:`unit_commitment`
      - Core UC parameters (unit size, output fractions, up/down times).
-     - Enables UC constraints; replaces capacity constraint for UC techs.
+     - Enables UC constraints; overrides available output calculation for UC techs.
        Commitment results are written to :code:`output_unit_commitment`.
    * - :code:`unit_commitment_startup_cost`
      - Direct startup cost per unit of capacity started.
@@ -165,6 +181,11 @@ capacity started.  Startup inputs are summed into the
    ":code:`tech`", ":math:`t`", "technology name"
    ":code:`input_per_cap`", ":math:`UCSI_{r,i,t}`", "input commodity consumed per unit of capacity started"
 
+.. note::
+
+   These inputs are **not** considered in network checking. If no other process produces or consumes the
+   input commodity in this region and period, it may be removed from the model and lead to errors.
+
 Decision Variables
 ------------------
 
@@ -200,9 +221,14 @@ Commitment Transition
 Output Bounds
 ~~~~~~~~~~~~~
 
-.. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_min_output_constraint
+The minimum output constraint enforces a floor on generation per online unit.
+The maximum output (capacity) constraint is handled by the standard core-model
+:code:`capacity_constraint` — the extension overrides
+:func:`~temoa.components.utils.get_available_output` so that available output
+is based on online units rather than total installed capacity, requiring no
+separate replacement constraint.
 
-.. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_max_output_constraint
+.. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_min_output_constraint
 
 Minimum Up/Down Time
 ~~~~~~~~~~~~~~~~~~~~
@@ -224,16 +250,14 @@ The core ramp constraint bounds the change in hourly activity against a fraction
 total installed capacity.  The UC version replaces this with a commitment-aware
 expression: only online units contribute to the ramp envelope, and the operating
 point assumed for units that start or stop during the transition adds or removes
-headroom according to the effective minimum output fraction.  See
-:func:`~temoa.extensions.unit_commitment.components.commitment._ramp_constraint`
-for the full mathematical derivation.
+headroom according to the effective minimum output fraction.  Units are assumed to
+start and stop at their minimum viable output level, taken as the larger of their
+:code:`min_output_fraction` and :code:`ramp_up_fraction` / :code:`ramp_down_fraction`.
 
 .. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_ramp_up_constraint
 
 .. autofunction:: temoa.extensions.unit_commitment.components.commitment.uc_ramp_down_constraint
 
-.. autofunction:: temoa.extensions.unit_commitment.components.commitment._ramp_constraint
-
 Objective Contributions
 -----------------------
 

temoa/_internal/run_actions.py

@@ -251,7 +251,7 @@ def solve_instance(
                     dual_suffix.direction = Suffix.LOCAL
                 result = optimizer.solve(instance)
             else:
-                result = optimizer.solve(instance, suffixes=solver_suffixes_list)
+                result = optimizer.solve(instance, suffixes=solver_suffixes_list, tee=True)
         except RuntimeError as error:
             logger.exception('Solver failed to solve and returned an error: %s', error)
             logger.error(

temoa/components/capacity.py

@@ -20,7 +20,7 @@
 
 from temoa.components import geography, technology
 
-from .utils import get_adjusted_existing_capacity, get_capacity_factor
+from .utils import get_adjusted_existing_capacity, get_available_output
 
 if TYPE_CHECKING:
     from temoa.core.model import TemoaModel
@@ -463,21 +463,9 @@ def capacity_constraint(
             for S_i in model.process_inputs[r, p, t, v]
             for S_o in model.process_outputs_by_input[r, p, t, v, S_i]
         )
-        return (
-            get_capacity_factor(model, r, s, d, t, v)
-            * value(model.capacity_to_activity[r, t])
-            * value(model.segment_fraction[s, d])
-            * model.v_capacity[r, p, t, v]
-            == useful_activity + curtailment
-        )
+        return get_available_output(model, r, p, s, d, t, v) == useful_activity + curtailment
     else:
-        return (
-            get_capacity_factor(model, r, s, d, t, v)
-            * value(model.capacity_to_activity[r, t])
-            * value(model.segment_fraction[s, d])
-            * model.v_capacity[r, p, t, v]
-            >= useful_activity
-        )
+        return get_available_output(model, r, p, s, d, t, v) >= useful_activity
 
 
 def adjusted_capacity_constraint(

temoa/components/operations.py

@@ -265,13 +265,12 @@ def _ramp_constraint(
     p: Period,
     s: Season,
     d: TimeOfDay,
-    s_next: Season,
-    d_next: TimeOfDay,
     t: Technology,
     v: Vintage,
 ) -> ExprLike:
     """Helper that composes :func:`_ramp_activity_increase` and
     :func:`_rampable_activity` into the core-model ramp constraint."""
+    s_next, d_next = model.time_next[s, d]
     result = _ramp_activity_increase(model, ramp_up, r, p, s, d, s_next, d_next, t, v)
     if result is None:
         return Constraint.Skip
@@ -336,17 +335,13 @@ def ramp_up_constraint(
       i.e. :math:`(H_d + H_{d_{next}}) / 2`
     - :math:`CAP \cdot C2A / (24 \cdot DPP)` gives the maximum hourly capacity
     """
-
-    s_next, d_next = model.time_next[s, d]
     return _ramp_constraint(
         model=model,
         ramp_up=True,
         r=r,
         p=p,
         s=s,
         d=d,
-        s_next=s_next,
-        d_next=d_next,
         t=t,
         v=v,
     )
@@ -387,17 +382,13 @@ def ramp_down_constraint(
             \\
             \text{where: } \Delta H = \frac{H_d + H_{d_{next}}}{2}
     """
-
-    s_next, d_next = model.time_next[s, d]
     return _ramp_constraint(
         model=model,
         ramp_up=False,
         r=r,
         p=p,
         s=s,
         d=d,
-        s_next=s_next,
-        d_next=d_next,
         t=t,
         v=v,
     )