Energy: cost-based solar feed-in tariff

A distributed solar project paid a cost-based feed-in tariff, with an abating payment in lieu of property tax and a revenue-linked royalty.

Every number below is checked against an independent reference implementation on every commit — period by period, and on each metric, inside a declared tolerance. See benchmark methodology.

The case

A 2 MW-dc distributed solar project paid a cost-based feed-in tariff. It generates 3,161,597 kWh in its first year — 2,000 kW at an 18.0456% net capacity factor over 8,760 hours — degrading 0.5% a year across a 25-year life, and is paid a flat 23.15 c/kWh.

Five operating expense lines run against it, and they do not share an escalator: fixed operations and maintenance, insurance and a land lease each inflate at 1.6%; a payment in lieu of property tax abates 10% a year on a stated schedule; and a royalty takes 3% of tariff revenue. $3.15m of level-pay debt runs 18 years at 7%, maturing seven years before the asset does.

The reference

A cost-based renewable energy tariff model published by a national laboratory as a spreadsheet, and independently ported to Python by a third party. Both were run; the comparison is three-way.

It publishes a complete annual cash flow, so every line is checkable period by period.

Not redistributable. The spreadsheet states no license and the port declares none, which means default copyright. Neither is vendored or wired into the test suite: the port was cloned outside the repository, run once, and only its output numbers carried across.

What it exercises

The four operating expense contracts are the same type at different escalators, which is why they are asserted as separate lines rather than as one total.

The result

Exact on every individual line. All seven stream columns agree with the reference across all 25 periods with zero disagreement.

Asserted: seven stream columns across 25 periods, plus domain.energy.opex, the reference's own published expense total. The reference publishes operating expenses as a single figure, so the four decomposed lines have to sum back to it in every period.

The delta

One non-zero figure: 5.0e-7, on the summed expense column at period 19.

It is not arithmetic. Results carry money to six decimal places, and the engine rounds a subtotal it computed from unrounded components — which is a different operation from summing five already-rounded components, and the two differ by up to half of the last published place. 5e-7 is exactly that half, and the floor any case here can assert to.

What the case asserts, and where it starts. The reference solves for the tariff that clears a target equity return, sweeping the rate until net present value crosses zero. That solved rate — 23.15 c/kWh — is the input here, stated as a constant, and the case asserts the cash flow it produces: every line, every year. The rate search is upstream of what this case checks: its result is the starting point, and the figures asserted are the cash flow that follows from it.

Run configuration

{
  "deterministic": {
    "annual_discount_rate": 0.12
  }
}

Verified results

Checked period by period: 8 series across 25 periods — 193 values in all, each within ±1e-6 of the reference.

• energy.ppa.revenue
• energy.om.expense.fixed
• energy.om.expense.insurance
• energy.om.expense.land_lease
• energy.om.expense.pilot
• energy.royalty.expense
• domain.energy.opex
• domain.energy.debt_service_periodic