Gradient Factors and recreational diving

[DevonDiver]

I'd be interested to know if any computers currently implement these different iterations of Buhlmann?

I've only seen ZHL16-B/C, as per the commonly understood gradient factor implementation.

Is this museum stuff? Or a mathematical exercise playing around with open source algorithm? Or is it actually a working implementation that we'd need to be aware of in any current computer?

 

[stuartv]

I'd be interested to know if any computers currently implement these different iterations of Buhlmann?

I've only seen ZHL16-B/C, as per the commonly understood gradient factor implementation.

ZHL-16B vs C are not implementations, nor are they different algorithms.

I'm not a professional deco theory scientist, so I will freely admit that what I am about to say could wrong for technical reasons that are above my pay-grade. [/disclaimer]

B and C are just different sets of M-values that are used by the same algorithm. And either, or both, can be implemented on any computer.

An algorithm is a description of how to do something. An implementation is a an actual process that performs the steps described by the algorithm.

One can implement ZHL-16B (or C) and (as it is not strictly defined by the algorithm) choose whether to implement it the way you described or implement in the alternate way that I described. Erik Baker's original code implements a first stop based on GF Lo, regardless of whether you'll exceed GF Hi or not. Erik Baker's code also does not factor ascent time into the calculation. It determines your stops based on "if you were at this depth immediately".

But, I have tested my Shearwater and it ignores GF Lo until such time as you would exceed GF Hi on a direct ascent. It also factors ascent time into its calculations so that it does not display a stop if your obligation will clear before you actually ascent to that depth. That is the way I want my dive computer to work, but I have had long debates with at least one other person on here about that and have to say that some people would prefer it to work the other way. I don't know any way to tell which way any given computer works other than by testing it.

 

[DevonDiver]

Ok...nomclemature... ZHL16-A/B/C are differing models. GF is additive to the base model, allowing user manipulation. They behave in a certain way, as described.

What you seem to be describing is an adaptation of either the base model or the GF additive. It seems like it's the additive that's different (?).

Sounds to me like people tinkering with an open source model, rather than a formal published model that you'd find on a commercially produced computer.

From how you describe it, it sounds like someone tried to create 'deep stops' on no-stop dives?

It'd probably be better described if given a name other than 'gradient factors' as that'd cause considerable confusion at the user end. People have an understanding of what the common 'gradient factors' achieve (if they research).

 

[stuartv]

Ok...nomclemature... ZHL16-A/B/C are differing models.

What are the differences between A, B, and C, other than the M-values? Feel free to give a link so I can go and read it, if you prefer. I have Weinke's books, Powell's book, Salama's book, the US Navy Diving Manual, and the NOAA Diving Manual, if you prefer to cite a reference from one of those.

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 (which is what I have been doing for a living for 30-something years now and with hundreds of thousands of people using or having used software that I wrote).

 

[uncfnp]

But, other implementations work differently. For those, if a direct ascent would exceed GF Lo, regardless of whether the ascent would exceed GF Hi at the surface, then that implementation says the diver is "in deco" and prescribes one or more stops.

Hey Stuartv! I am on my way out the door but this caught my eye earlier and I have been thinking about it. I don't recall see this before. Would not this make it closer to a bubble model?

 

[BoltSnap]

thousands of people using or having used software that I wrote

What kind of software do you write/develop??

 

[scubadada]

There have been several previous discussions on SB on these topics

I have been diving Oceanic computers running DSAT since 2002, about 1300 dives. I dived a Geo 2, also running DSAT, as a backup for about 750 dives. Last summer, I switched to a Dive Rite Nitek Q as backup, to gain experience with Buhlmann ZH-L16C with GF, and have about 125 dives. The mapping between DSAT and Buhlmann is not perfectly straightforward. Buhlmann will match DSAT reasonably well running a GF hi of between 90-100, lower at shallower depths and higher at deeper depths. I am guessing that, even though the surfacing M values (Mo) are reasonably close between the 2 algorithms, the slope of the M-value lines (deltaM) are probably different, with DSAT being steeper. The Mo values for both algorithms can be found in Mark Powell's, Deco for Divers. The deltaM values for Buhlmann are also listed but not for the proprietary DSAT algorithm. I have not been able to find them.

Regarding Buhlmann ZH-L16A, B, and C, also in Deco for Divers, it states that mathematically derived A was too liberal in the mid-range. B is more conservative and designed for table use, C a bit more conservative and designed for computer use.

The GF lo for my Nitek Q does not kick in until one goes into deco, GF hi alone controls a recreational dive. I have my GF low set relatively high, as suggested above, for the relatively rare instance for which I have a short deco obligation. I believe Shearwater works this way too, I can't comment on other computers running Buhlmann.

For anyone considering switching from DSAT (or any other algorithm they are very familiar with) to Buhlmann, I would suggest doing what I have done and dive both in parallel to gain experience. I'm still deciding exactly how I would dive Buhlmann as my only algorithm

Good diving, Craig

 

[dmaziuk]

Hey Stuartv! I am on my way out the door but this caught my eye earlier and I have been thinking about it. I don't recall see this before. Would not this make it closer to a bubble model?

I can think of a couple of reasons to say "yes" but I expect for practical purpoises: for some settings, on some profiles, probably. Like Craig's examination of DSAT vs GF.

I think in general I want a computer that calculates its guesstimates for "now" as opposed to for what they were at max. depth or may become if and when I reach the surface.

 

[stuartv]

Hey Stuartv! I am on my way out the door but this caught my eye earlier and I have been thinking about it. I don't recall see this before. Would not this make it closer to a bubble model?

I guess that's kind of a subjective question. I would say no, as the only time this difference in implementation has any relevance is when you are not yet at the point where a direct ascent would not exceed GF Hi. For any "real" deco dive, the difference is completely moot.

 

[uncfnp]

I guess that's kind of a subjective question. I would say no, as the only time this difference in implementation has any relevance is when you are not yet at the point where a direct ascent would not exceed GF Hi. For any "real" deco dive, the difference is completely moot.

But I am thinking of the recreational implementation. I am no theorist, mathematician or anything remotely similar. So in your readings and research you have found that it is possible in real life recreational diving to reach a GF lo limitation to direct ascent before the GF hi? If so, a DC using such an implementation would seem to be more "conservative" in at least some of the same aspects as a DC runnng a bubble model. Do you know of any dive computers that implement the GF lo limitation to NDL's?