Guide

Before you trust an energy model: five checks

Whether your model was written by an AI assistant, built in a spreadsheet, developed in-house or bought, it can produce a clean, plausible and wrong answer. These five checks catch most of the errors that don't announce themselves. Each takes minutes to run.

Go to the checks ↓

Why these errors are hard to spot

A wrong optimisation model doesn't crash. It optimises the mistake.

An optimisation model does exactly what it was told: find the cheapest system that meets the constraints. If a constraint is missing or a unit is off, the cheapest system often uses the mistake. Free energy from a battery, or a technology that looks cheaper than it is, ends up at the centre of the "optimal" design.

So the problem is rarely spotting an obviously broken result. It is spotting a convincing one. None of the checks below need you to read the code. You change the inputs in a way where you already know what should happen, then see whether the model agrees.

The five checks

Run these before a number leaves the building

Energy balances in every hour

Do this

For every timestep and every energy carrier, add up what comes in (generation, imports, storage discharge) and what goes out (demand, exports, storage charging, losses).

You should see

The difference is zero, within solver tolerance, in every hour. Not just on average over the year.

If not

Energy is appearing or vanishing somewhere. Common causes: a carrier with no balance constraint, a missing loss term, or a conversion efficiency applied in the wrong direction.
Storage can't create energy

Do this

Compare each storage's state of charge at the start and end of the modelled period. Then make storage almost free and run the model again.

You should see

The end state is at least the start state. Cheaper storage changes when energy is used, not how much of it is available.

If not

The model is probably emptying a storage that starts full, for free. This is especially common when a year is compressed into typical days and storage isn't linked across them.
Making something more expensive never means more of it gets built

Do this

Double the investment cost of one technology and run the model again.

You should see

The same installed capacity of that technology, or less.

If not

Look for a sign error, a wrong annuity factor, or costs entered in the wrong place in the objective. With a true optimum this holds mathematically; small deviations can come from the solver's optimality gap, so check that setting first.
Changing units doesn't change the design

Do this

Convert all inputs to different units, for example kWh to MWh, with prices and costs converted to match.

You should see

The same system, with every capacity scaled by exactly the conversion factor.

If not

Somewhere a number has the wrong unit. Typical cases: costs per kW applied to capacities in MW, tariffs in ct/kWh read as CHF/kWh, efficiencies entered in percent, or annual demand treated as hourly.
Removing an option can't make the system cheaper

Do this

Remove one technology from the list of candidates and run the model again.

You should see

A total cost that is the same or higher. Fewer options can never produce a cheaper optimum.

If not

Either the model wasn't finding the true optimum in the first place (check solver settings and gap), or that technology was being forced into the design by a faulty constraint.

What the checks don't tell you

Consistent is not the same as right

Passing all five means the model is internally consistent. It doesn't mean the model is right. The checks can't catch:

Unrealistic demand profiles or weather data
Outdated technology costs or tariffs
Missing physics, such as part-load behaviour, temperature levels or network losses
A model that answers a different question from the one your client asked

That takes validation against real projects, maintained data, and experience with the kind of system you are modelling.

Where to go from here

Three honest ways forward

Keep building

If your model passes the checks, you have a solid foundation. Next, validate it against a project with known results, and decide who will keep the input data current.

Keep your AI, swap the engine

Let your assistant do the setup and the analysis through Sympheny's REST API or Python SDK, and let a validated MILP engine do the maths.

See how it works with AI assistants →

Work with Sympheny

Over ten years of Empa and ETH Domain research behind the optimisation, maintained technology and cost data, and a team of PhDs in multi-energy systems to support you when a result needs explaining.

Read the published research →

FAQ

Questions about checking energy models

Do these checks only apply to AI-written models?

No. They apply to any optimisation model: one an AI assistant wrote, a spreadsheet with a solver add-in, an in-house tool or a commercial platform. AI-written code makes them more relevant because it is produced faster than anyone can review it line by line.

If my model passes all five checks, is it correct?

It is internally consistent, which rules out a large class of silent errors. It can still rest on wrong inputs, missing physics or the wrong question. That part takes validation against real projects and maintained data.

How long do the checks take?

Each one is a single extra model run plus a comparison, so minutes for a small model. For a large model, run them on a reduced version first, such as a few typical days, then confirm on the full model.

Can I run the checks in Sympheny?

Checks 3 and 5 map directly onto Sympheny scenario variants: change one technology's cost or remove it, and compare the results side by side. Hourly energy flows and storage states can be exported to Excel for checks 1 and 2.

Next step

Want to see a validated engine on your own project?

Start a free trial, or book a demo and walk through a project that mirrors yours with one of our engineers.

Book a demo Start a free trial