Gradient Factors and recreational diving

[KenGordon]

I think they all do really. It is just that the planning functions are simplistic and they don't report very short stops. Plan a near the NDL dive on 10/90 on multideco and an SW and you will find stops on multideco much earlier than on the SW but they will be over in an instant as the new (higher) target GF is applied.

Clearly any dive which exceeds GF low has become a deco dive. It's just that the next stop will likely be the surface at GF high, or half way there at a substantially higher GF and so moving up is allowed directly.

Another question is where does GF start being interpolated from? That turns out to have to be different in a live dive computer than in a planner, and in the computer cannot really be like the fortran.

 

[DevonDiver]

What are the differences between A, B, and C, other than the M-values?

They're known as different models. Nonetheless, it's based, I believe on differing M-values.

A was too aggressive, B was intended for tables design, C was more conservative, applicable for dive computer implementation.

Mark Powell calls them 'models', and as his book is probably the most well read on the subject, I'd elect to use his nonclemature for a lay debate.

Andy, you know a crap-ton about diving. More than I will ever know in my lifetime, I'm sure. But, you are rapidly convincing me that you know almost nothing about software design and development

I don't intend to make any claims on software design knowledge. I'll happily admit that I have zero experience writing code.

I don't even know what Fortran is?

I'm intending to answer the OPs question, rather than engage in a software coding debate. I understand models from a user or lay person perspective only.

So, in respect to the OPs question.... software implementation isn't really an issue. We need to talk about how ZHL16-B/C GF work... as per their implementation on commercial dive computers.

That ZHL16-B/C implementation is quite standard, no? Whilst we can acknowledge that it can be adapted and changed (being open source), I don't believe those implementations have ever been used commercially as ZHL16-B/C?

As an analogy (and tell me if I'm wrong).... the same happens with Android software. It's open source. There are versions of it (1.0, 2.0, 2.4 etc) ... like there are versions of Buhlmann ZHL(A, B & C).

If coders take the base Lollipop software and change it around.. like the Cyanogenmod stuff.. that tweaked stuff isn't now called 'Lollipop'... it's differences are recognized because it's renamed in-toto.

As far as I know, the only commercially available computers that allowed user implemented code were the OSTC 2 and 3 (the 4 doesn't, I believe). Not that bright people couldn't 'hack' another type of computer, I'm sure... but that's a nerd-type project, not something a regular diver would ever encounter.

 

[KenGordon]

The difference between zhl16-a/b/c is more like changing the brightness and contrast on your monitor than a version of an OS. The actual code is the literally same. The entire difference is in the limit values. So a vs b vs c is a bit like different GF value pairs.

The real problem I have with the GF stuff is that it is all rather vague. It sort of change those M value limits but based on a very loosely defined end point - the first stop depth.

You ought to read the fortran by Erik Baker. The comments in the code is as close to a spec as you will find. There are some covering emails too.

 

[stuartv]

That ZHL16-B/C implementation is quite standard, no? Whilst we can acknowledge that it can be adapted and changed (being open source), I don't believe those implementations have ever been used commercially as ZHL16-B/C?

As an analogy (and tell me if I'm wrong).... the same happens with Android software. It's open source. There are versions of it (1.0, 2.0, 2.4 etc) ... like there are versions of Buhlmann ZHL(A, B & C).

If coders take the base Lollipop software and change it around.. like the Cyanogenmod stuff.. that tweaked stuff isn't now called 'Lollipop'... it's differences are recognized because it's renamed in-toto.

As far as I know, the only commercially available computers that allowed user implemented code were the OSTC 2 and 3 (the 4 doesn't, I believe). Not that bright people couldn't 'hack' another type of computer, I'm sure... but that's a nerd-type project, not something a regular diver would ever encounter.

No. And this is the nub of this conversation. It might be helpful for you to read this post from RonR from Atomic:

New dive computer for Divemaster internship

The algorithm is pretty well understood. You can refer to it as standard, I suppose. But, every implementation (except OSTC's) is proprietary. Thus, every implementation is different. However, the algorithm itself being fairly well understood means that every different implementation should yield pretty close to the same results in almost all cases. One case where it is clearly not always the same is the niche case of "If the diver makes a direct ascent, they will exceed GF Lo, but will not exceed GF Hi".

Your Android analogy is off in so many ways, I won't try and correct it.

 

[dmaziuk]

Some day I plan to get a fresh supply of round tuits and play with decotengu or maybe subsurface code -- I too want to see a profile that exceeds gf lo without exceeding gf hi. Which is another way of saying "stay past the ndl while still able to make direct ascent to the surface within the prescribed limits". Will probably never happen...

 

[stuartv]

It's not hard. When we had the detailed conversation about this before, in another thread, I was easily doing dive plans that came out different on different platforms because of this difference in how to determine the ascent.

 

[dmaziuk]

Different results from different implementations are a given, a profile that violates the NDL and at the same time doesn't would be fun.

 

[Miyaru]

Can somebody enlighten me?

From what I understand, it's about the partial pressure difference per gas between tissue pressure and ambient pressure.
If the tissue pressure is lower, you're on-gassing. If the tissue pressure is higher, you're off-gassing.
The m-value is the point where bubble forming might start, above the m-value it's critical supersaturation.

To make the ascent across the m-value line less aggressive, you apply a gradient factor. First value is a percentage of the supersaturation at the deepest part, second value is a percentage of the supersaturation at the surface. These two points give you a new ascent line, which is more conservative. I've tried to illustrate this in two diagrams:

Please correct me if my reasoning is incorrect.

I've used 50/80 as an example only.

What happens to that purple line if the computer ignores a GF high or low factor?

What is the new ascent line gonna look like?

 

[stuartv]

No computer ignores the GF Hi ever, that I know of. At least some implementations of the Buhlmann ZHL-16B or C algorithm do ignore GF Lo under a specific circumstance: If a direct ascent (at 30' or 10m per minute) will not result in the tissue tension ratio to ambient pressure exceeding GFHi % of the M-value at any time before or upon arrival at the surface.

So, you always know the left (in your drawing) anchor point of the pink line. What you don't have on your drawing is a line showing the actual tissue tension versus ambient pressure. But, you can plot one from the "current" ambient pressure (your X coordinate) to the surface, where you assume a 30fpm ascent in order to calculate your Y coordinate at every X.

If you then anchor the right end of the pink line at X=current ambient pressure and Y = GFHi % of the M-value (yes, I meant GF Hi)*, then all you have to do is verify that your plotted "actual" line never crosses your pink line. If it doesn't, then you are still within your NDL and you continue to ignore the GF Lo.

If your "actual" line does cross the pink line, then you change the anchor for the right end of the pink line by determining the intersection of your "actual" line (assuming 30fpm ascent) and a line that plots 20% of the M-value at all depths). That intersection (rounded up to the nearest 10' or 3m) becomes your ceiling for your first deco stop. The GF value is then interpolated from Lo to Hi for every 10' (or 3m) between there and the surface. Etc...

And, of course, in real life, you would have one of these graphs for each of the 16 compartments, reflecting each one's different M-value and compartment half-life.

* I think anchoring the right end of your pink line is moot here because I think that when you assume a 30fpm ascent, if the "actual" line doesn't exceed GFHi % of the M-value at the surface, then it will not ever cross the pink line during the ascent. So, there is actually no use for the pink line at all, until you determine that a direct ascent will exceed GFHi at the surface.

 

[Miyaru]

So your description results in the red line for the dive (which will probably be the fastest of all compartments)

I know there's no scale present, but in this case you reach the NDL at the end of the bottom time.
I get it.