Migrating from Gas Decompression to NIST REFPROP: What We Learned

Why We Needed to Move

The application in question is a pipe ductile fracture analysis (PDFA) tool used by pipeline engineers to model how fractures propagate through pressurized gas pipelines. The original version was built in Visual Basic and relied on a legacy gas decompression library that had been around for decades.

For simple, single-component gas calculations, the old library was adequate. It computed decompression wave speeds and pressure-temperature relationships well enough for textbook scenarios. But real-world pipeline engineering involves multi-component gas mixtures at extreme pressures and temperatures, and that is where the old library started to fall apart.

The limitations were concrete:

• No support for arbitrary multi-component mixtures — the library only handled a fixed set of predefined compositions
• Hardcoded thermodynamic assumptions that broke down at high pressures (above ~15 MPa)
• No way to select or swap the equation of state (EOS) used for calculations
• Numerical instability near phase boundaries that caused the solver to diverge or return physically meaningless results

When clients started bringing us mixtures with CO2, H2S, and nitrogen at supercritical conditions, the old library simply could not produce trustworthy results. We needed a replacement.

Why REFPROP

NIST REFPROP (Reference Fluid Thermodynamic and Transport Properties Database) is the gold standard for thermodynamic property calculations. It is maintained by the National Institute of Standards and Technology and covers over 150 pure fluids and supports arbitrary mixtures.

The key advantages for our use case:

Equation of state flexibility. REFPROP supports multiple EOS models, including GERG-2008 (the international standard for natural gas mixtures), Peng-Robinson, and others. This matters because different EOS models have different accuracy ranges, and pipeline engineers need the ability to select the right one for their specific conditions.

Mixture handling. REFPROP natively supports multi-component mixtures with no predefined limit on the number of components. You define the mixture composition, and REFPROP handles the mixing rules and interaction parameters automatically.

Validated accuracy. Every fluid model in REFPROP is validated against experimental data published in peer-reviewed literature. The uncertainty bounds are documented and known. This is critical for engineering applications where the numbers inform real-world safety decisions.

Active maintenance. REFPROP is actively maintained and updated with new fluids, improved models, and bug fixes. The legacy library we were replacing had not been updated in over a decade.

The Migration

Swapping a thermodynamic computation engine is not a drop-in library replacement. The old library had its own calling conventions, unit systems, and data formats. REFPROP uses a completely different API with different input/output conventions.

Interface Abstraction

The first thing we did was define a clean interface layer between the application logic and the thermodynamic engine. This way, the PDFA calculations did not need to know which engine was running underneath. They just called functions like GetDecompressionWaveSpeed(pressure, temperature, composition) and got results back in consistent units.

This abstraction also made it possible to run both engines side-by-side during validation, which was essential for building confidence in the migration.

Unit Handling

The legacy library worked in a mix of imperial and metric units with some internal conversions that were poorly documented. REFPROP works primarily in SI units (Pa, K, mol/L). We built a unit conversion layer that handled all translations at the boundary, keeping the internal calculations strictly in SI.

This alone eliminated several classes of bugs that had accumulated in the old codebase over the years.

Solver Integration

The PDFA application uses an iterative solver to find the decompression wave speed as a function of pressure. At each iteration, it needs thermodynamic properties (density, speed of sound, enthalpy) at a given pressure and temperature. Replacing the property calculations meant re-tuning the solver tolerances and step sizes, because REFPROP returns different (more accurate) values than the old library, and the solver convergence behavior changed.

We spent meaningful time here. Some edge cases that converged quickly with the old library required more iterations with REFPROP, and vice versa. The fix was to implement adaptive step sizing rather than relying on fixed iteration parameters.

Validation

We validated the migration in three stages:

Stage 1: Pure fluid benchmarks. We ran both engines against published NIST property tables for methane, ethane, propane, and CO2 across a range of pressures and temperatures. REFPROP matched the published data within documented uncertainty bounds. The old library showed deviations of 2-5% at high pressures.

Stage 2: Mixture comparisons. We defined a set of representative natural gas compositions and ran decompression calculations through both engines. Results were compared against published experimental data from burst tests. REFPROP consistently produced results closer to the experimental measurements.

Stage 3: Field validation. We ran the updated application against a set of real pipeline analysis cases provided by clients, where the results from the old tool were known. The new results were reviewed by domain experts and confirmed to be more physically reasonable, especially for high-pressure, high-CO2 cases that the old engine struggled with.

Results

The migration took approximately three months from start to production deployment. The key outcomes:

• Accuracy improved across the board, with the largest gains in multi-component mixture calculations at high pressures
• EOS selection is now user-configurable per calculation, allowing engineers to choose the model best suited to their conditions
• Numerical stability improved significantly — the solver no longer diverges near phase boundaries
• Performance was roughly equivalent for simple cases and faster for complex mixtures, because REFPROP’s optimized routines handle multi-component flash calculations more efficiently than the old library’s iterative approach

The abstraction layer we built during the migration also made the codebase significantly easier to maintain and test. Future engine swaps — if they ever become necessary — will be a fraction of the effort.

Takeaways

If you are maintaining software that depends on a legacy computation engine, the migration is worth doing — but it is not trivial. The engine swap itself is the easy part. The real work is in validation, solver integration, and unit handling.

Build the abstraction layer first. Run both engines in parallel during validation. And invest the time in proper benchmarking against published data, not just against the old tool’s output. The old tool’s output might be wrong — that might be why you are replacing it.