Computing Steam Properties in TypeScript

Ask a plant engineer for the saturation temperature of steam at 10 bar absolute and they will reach for a table. Steam tables have been the working tool of process engineering for a century, and they are excellent: compact, trusted, and readable without a computer. They are also awkward the moment you want a number that falls between two rows, and impossible to audit once a figure has been copied out of one and into a quotation.

I build the steam calculators and write the engineering notes published at GyanTosh Fabricators. That work turns on a single decision made early: rather than encode a lookup table, compute the properties directly from the standard.

What IAPWS-IF97 actually is

The International Association for the Properties of Water and Steam publishes the industrial formulation the whole field agrees on: IAPWS-IF97. It is not a dataset. It is a set of equations that return thermodynamic properties of water and steam as functions of pressure and temperature, and it divides the operating envelope into regions:

• Region 1 — compressed liquid water
• Region 2 — superheated steam
• Region 3 — the dense region near the critical point
• Region 4 — the saturation line, where liquid and vapour coexist
• Region 5 — high-temperature steam above 800 °C

Industrial boiler and condensate work lives almost entirely in regions 1, 2 and 4. A rice husk fired boiler at 10.5 bar, a thermic fluid loop, a condensate return line at 1.5 bar — all of it sits inside that envelope. Regions 3 and 5 matter for power generation at supercritical conditions, not for the process heating equipment most plants actually run.

So the engine behind the calculators implements regions 1, 2 and 4. That is a deliberate scope decision, not an omission: implementing the region 3 backward equations to serve plants that will never operate there would add surface area without adding a single correct answer to a real enquiry.

Why compute rather than look up

Three reasons, in increasing order of how much they matter commercially.

Interpolation stops being a judgement call. A table gives you 10 bar and 11 bar. A boiler running at 10.4 bar requires interpolating between them, and the properties of steam are not linear. The error is usually small. "Usually small" is not a phrase that belongs in a sizing calculation a customer will buy equipment against.

The arithmetic becomes reproducible. When a figure is computed from a published standard rather than transcribed, anyone holding that standard can reproduce it. That is a meaningfully different claim from "trust our spreadsheet".

Every published number can be recomputed. This is the part that changed how the writing works. Every figure quoted in the engineering notes on the GyanTosh site is recomputed from the same engine that powers the public calculators, rather than copied from a reference table. If the engine is right, the articles are right, and both can be checked independently.

Verification is the whole point

An implementation of a standard that has not been checked against the standard is just an opinion with decimal places.

IAPWS publishes R7-97, which includes verification tables: specific input conditions with the exact property values a correct implementation must return. They exist precisely so implementers can prove their code, and they are the difference between "I wrote the equations out of the paper" and "the equations demonstrably behave".

The engine's unit tests assert agreement with those verification tables to nine significant figures. Not "close enough for engineering" — agreement at the precision the standard itself specifies. That test suite is the artefact I would point at if someone asked why a number on the site should be believed.

Nine significant figures is far beyond what any real plant needs. A trap sizing calculation does not care about the ninth digit. The precision is not for the plant; it is evidence that the implementation is faithful rather than approximately right in the range someone happened to test.

Why this sits between two jobs

I did not come to steam through mechanical engineering. My degree is a BE in Information Technology, and the steam side came from formal training — including a sixteen-hour masterclass on steam boilers, steam and condensate systems — alongside hands-on exposure to the boilers, thermic fluid heaters and balance-of-plant equipment GyanTosh designs, fabricates, installs and commissions.

That combination is unusual, and it is exactly why the calculators exist. Someone with only the software background would not know which regions matter or which questions plant engineers actually ask. Someone with only the process background would reach for a spreadsheet and a table, because that is the tool the field already trusts.

The interesting work is in the overlap: knowing that region 3 is not worth implementing for this equipment, and also knowing what a nine-significant-figure assertion in a test suite buys you.

What I would tell someone building the same thing

Implement the standard, not a table. Scope the regions to the equipment you actually serve. Test against the published verification data before you ship a single number to a customer. And where a value cannot be computed or sourced, say so plainly rather than estimating — published capacities and efficiencies are worth more when the omissions are honest.