Open Energy Methods
Menu ☰
← Back to the workbench
Field note 001 · 27 October 2026 · Worked example

Why a passing energy balance is not proof.

A perfectly closed balance tells you something useful. The trouble starts when you ask it to tell you more than it knows.

Abhijith Sivaprasadan · Open Energy Methods

Start with a boring compressor.

In EnerLint's hand-constructed reference case, the compressor has 2 kg/s flowing in and out. The declared specific enthalpy rises from 300 to 420 kJ/kg. Heat input is zero; shaft work is supplied to the compressor.

Using the chosen convention—positive shaft work out of a control volume—the steady first-law residual is:

Declared check · kinetic/potential effects neglected
RE = Σṁhin − Σṁhout + Q̇in − Ẇout
= 2 × 300,000 − 2 × 420,000 − (−240,000) = 0 W

So far, so good. Both the mass balance and energy balance close.

Now change the answer without breaking the equation.

Suppose the intended reference operating point remains the original one. I alter the exported mass flows and compressor shaft work together, multiplying each by 1.1. The enthalpy values stay unchanged. The new values are 2.2 kg/s and −264 kW.

Compensating perturbation · known escape
2.2 × 300,000 − 2.2 × 420,000 − (−264,000) = 0 W

PASS_IN_SCOPE Both declared balances still close.

The checker is not broken. It is doing exactly the check I gave it. Conservation alone cannot distinguish these two internally consistent operating points. Whether the second is wrong requires another source of evidence—an independently specified operating point, a component map, a measurement, or another justified reference.

What this changes for EnerLint.

One test is deliberately designed to remain undetected. Keeping that case visible is more informative than presenting six flagged mutations as a detection percentage. The six were selected by the developer; they are not a representative sample of mistakes in real energy models.

This is why I want EnerLint reports to say PASS_IN_SCOPE, not just VALID. A check has a boundary, a tolerance, a set of assumptions, and a list of things it never examined.

The next question is harder.

Can an output-level tool catch errors that a properly configured native solver or diagnostics package would miss, when both are given equivalent information? That comparison is still open. If the answer is no for a particular workflow, improving the existing tool may make more sense than inventing another one.

For now this is a worked synthetic example, not evidence of industrial fault-detection performance or model validation. The point is to make the limitation inspectable.

← Back to Open Energy Methods