What is Intrinsic Hosting Capacity Mode and why is it useful?

What is Intrinsic Hosting Capacity Mode?

Standard hosting capacity modelling answers the question: given a specific DER deployment scenario, does the network have problems? Intrinsic Hosting Capacity Mode inverts that question: how much additional load or generation can the network actually support before hitting a limit?

It starts from a chosen network state and systematically adds synthetic load or generation - in configurable increments - to every relevant injection point simultaneously, re-solving the power flow after each step. The search continues until a configured voltage or thermal constraint is breached, at which point the last valid state defines the hosting capacity.

Two Sub-modes

LV Hosting Capacity

This sub-mode answers: how much additional export or import capacity is there for customers under each distribution transformer?

The network is divided into capacity groups - one per distribution transformer. Load or generation is added to all customers within each capacity group simultaneously, and the search finds the maximum addition that keeps the whole group within limits.

The primary output is headroom_kw_per_customer in the lv_group_hosting_capacity table - a per-transformer figure representing how much additional capacity each customer under that transformer can absorb before the network is constrained.

HV Hosting Capacity

This sub-mode answers: how much additional capacity is there at specific HV connection points?

Rather than looking at the LV customers under a transformer, this tests the HV network itself. HCM finds all qualifying HV nodes in the selected feeders, then tests them one at a time: it adds generation or load at that node, increments until a constraint is found, resets back to zero, and moves to the next node.

The primary output is available_headroom_kw in the hv_node_headroom table - the available headroom at each HV node location.

Because each HV node is tested independently (not in parallel), run time scales with the number of nodes. A feeder with many qualifying HV nodes will take proportionally longer. The per-node iteration limit controls the maximum depth of the search at each location.

How the Search Works

Both sub-modes use the same core loop:

1. Load the network at a chosen initial state (a specific timestamp, peak import/export period, fixed load, or zero load).
2. Add a configurable increment of load or generation to all relevant injection points.
3. Solve the power flow.
4. Check all configured voltage and thermal constraints.
5. If no constraint is breached, repeat from step 2. If a constraint is breached, record the last valid state as the hosting capacity for that location.

The step size (step_kw_per_customer for LV, step_kw_per_node for HV) directly controls the precision of results. Smaller steps give finer resolution but require more iterations.

The maximum iterations (max_steps / max_steps_per_node) acts as a safety limit. If the configured number of steps completes without hitting a constraint, the result is recorded as unconstrained up to that point.

Choosing the Initial State

The initial state determines the baseline load and generation conditions from which the search begins.

Selector Mode	When to use it
PEAK_FEEDER_EXPORT	Find headroom at the most constrained export (e.g., high solar) moment. This is typically the most conservative and relevant for solar hosting capacity assessments.
PEAK_FEEDER_IMPORT	Find headroom at the most constrained import moment. Relevant for EV charging or load growth assessments.
FIXED_TIME	Start from a specific known timestamp. Useful for reproducing or comparing results at a defined network state.
FIXED_LOAD	Apply a uniform per-customer load/generation as the baseline. Useful for standardised comparisons across feeders.
ZERO_LOAD	Start from an empty network (no existing load or DER).

What Can Constrain the Search?

Any of the configured voltage or thermal limits can stop the search:

• LV voltage limits - minimum and maximum voltage in volts at LV nodes (e.g., 216 V to 253 V).
• HV voltage limits - minimum and maximum voltage in per unit at HV nodes (e.g., 0.95 pu to 1.05 pu).
• LV thermal limits - loading as a percentage of the normal or emergency rating on LV assets.
• HV thermal limits - loading as a percentage of the normal or emergency rating on HV assets.

When a constraint is first breached, the details are recorded in the constraint_violations table and linked to the corresponding capacity group or HV node result via binding_id. This lets you trace which specific asset or voltage limit stopped the search.

Key Outputs at a Glance

Table	What it answers
lv_group_hosting_capacity	How much additional capacity (kW per customer) is available under each distribution transformer?
hv_node_headroom	How much headroom (kW) is available at each HV node location?
constraint_violations	Which specific asset or voltage limit stopped the search, and at which iteration?
binding_constraints	Links each capacity result to its binding constraint violation.
customer_allocations	How many kilowatts were allocated to each individual customer at the point the constraint was hit?