Generating deco plans - the art & science of gradient Factors

author: Eddie Yung

Over the years (if not decades), numerous articles have attempted to explain Gradient Factors to divers of varying mathematical backgrounds. Without exception, the core concept of Gradient Factors traces back to Erik C. Baker’s original article, Clearing Up the Confusion About “Deep Stops.”

Most dive computers today implement the Bühlmann algorithm with Gradient Factor adjustments. I have personally explored this approach for years - starting with creating tissue loading charts in MS Excel, then programming a tissue loading model in C++ and later Java, and ultimately packaging everything into a Python class. My project has evolved from simple chart plotting for educational purposes into a fully functional decompression planner, which I now call the Orange Planner. This tool incorporates Bühlmann’s ZHL-16C coefficients, Gradient Factor adjustments, decompression gases, dive plan generation, and tissue loading chart visualization.

To implement these concepts effectively, I have repeatedly revisited every sentence of Baker’s article. Since I do not develop this software commercially, I tend to return to my code every few months whenever I gain new insights into modifying the algorithms. Each time I revisit the article - and supplement my research with additional online resources - I uncover details I had previously overlooked or simply forgotten.

Through this process, I have come to understand why different decompression planners and technical dive computers produce varying dive plans, despite all claiming to use the Bühlmann model. These differences are not merely due to underlined hardware, programming languages, or floating-point precision. Rather, they stem from the diverse ways engineers could choose to implement Baker’s ideas.

For those unfamiliar with the process, decompression planning is not a straightforward mathematical function where inputs yield direct results. Instead, it relies on iterative simulation. In simple terms, a “software” diver is placed at depth to accumulate inert gas. The simulation then models the ascent, allowing for off-gassing and decompression stops just as in a real dive. As the software diver ascends, decompression stops are inserted whenever a tissue compartment surpasses its M-value threshold. This iterative process continues until the diver safely reaches the surface.

This iterative nature makes the implementation of Gradient Factors particularly complex. At any given time, 16 tissue compartments are simultaneously on-gassing and off-gassing, each constrained by its M-value limits. Additionally, there are 16 Gradient Factor-adjusted M-values that must be dynamically calculated. Many commercial decompression planners handle the Bühlmann algorithm with relative ease, but Gradient Factor adjustments introduce an extra challenge. Specifically, the 16 adjusted M-value lines depend on the so-called “first stop” depth, which, as Baker describes, influences the slopes of these lines. However, determining this “first stop” is itself an iterative process, as it depends on which tissue compartment first reaches its limit - something that cannot be predicted in advance.

These are software implementation challenges, not mere mathematical derivations. While all methods ultimately trace back to the same article, Baker’s writing was not intended as a step-by-step software guide.

My implementation is not intended as a commercial product (though it could be, given today’s rapid MCU advancements). Instead, I prioritize accuracy through extensive iteration, small ascent steps, and precise calculation of adjusted M-values. My primary goal has been to generate accurate chart visualizations for educational purposes. Additionally, by maintaining source code that closely follows Baker’s original ideas, I can better understand how commercial products may introduce modifications - whether for practical benefits in real-world diving or other considerations.

At the end of the day, there is no absolute right or wrong in deco plan generation, as it is not an exact science to begin with. From the perspective of software engineers, it could even be a piece of art.