Padi Advanced OW - Deep stops??

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

It is interesting the Buhlmann ZHL-16C is not implemented exactly the same in all planning software and dive computers. I wonder if this should be the case?

Perhaps it explains why there is no open source code for PDC's - or why they call it proprietary software to avoid having to justify the "tweaks" and can charge a premium (different from other software)?
 
@KenGordon's post prompted me, so I just went and had a readthrough of Erik Baker's Fortran code for calculating an ascent.

To the best of my reading (it's been a long time since I was coding Fortran for a living), his code uses GF Lo to calculate the first stop on the ascent, period. It does not check for a direct ascent against the GF Hi first.

I also re-read Baker's article on Understanding M-values and I don't find anything there that really specifies whether GF Lo is to be used always or only after GF Hi dictates at least one mandatory stop.

My thought is that this little nit, in the small window of dive time where GF Hi does not dictate a stop but GF Lo does (or would), is one that is really up to the discretion of the implementer. So, I don't think either way is "wrong" and they only give different results for a pretty small subset of all dives - with the fuzziness of deco theory rendering that difference meaningless in any practical sense.

I have mixed feelings about how I would want it to work. But, as I am now sold (based on other threads) on using a fairly high value for GF Lo (usually, 50), I think the difference is REALLY irrelevant to me.
 
Perhaps it explains why there is no open source code for PDC's - or why they call it proprietary software to avoid having to justify the "tweaks" and can charge a premium (different from other software)?

The HW OSTC 3 and 4 PDCs are open source.

If they had AI, I would already have one.
 
Wow, I'm surprised that your computer might put you in violation gauge mode for skipping the deep stops, a steep penalty to pay for a practice that is not widely accepted in recreational diving. In the planning mode, how does you computer give you an NDL for a given depth and time, does it include the deep stops? With mandatory stops, seems like this is no longer NDL. Obviously, I'm confused about the Mares-Wienke RGBM algorithm.

In planning mode the Puck will give you NDL in 10 foot increments down to 157 feet. It does not take deep stops into account because deep stops have nothing to do with NDL. The NDL, as far as the Puck is concerned, is the time remaining at depth for no deco stops. A deco stop is not the same thing as a deep stop. Deep stops, I believe, are incorporated into the Mares-Weinke (RGBM) algorithm as an extra safety measure specifically designed into the Mares Puck computer which is intended for recreational use.

It is confusing if you adhere to the strict definition of NDL as the time remaining at depth for a no stop dive before safety stops became the de-facto standard for deep recreational dives. It is no more confusing than the majority of recreational computers calling for a safety stop when NDLs have not been exceeded.
 
Last edited:
@KenGordon's post prompted me, so I just went and had a readthrough of Erik Baker's Fortran code for calculating an ascent.

To the best of my reading (it's been a long time since I was coding Fortran for a living), his code uses GF Lo to calculate the first stop on the ascent, period. It does not check for a direct ascent against the GF Hi first.

I also re-read Baker's article on Understanding M-values and I don't find anything there that really specifies whether GF Lo is to be used always or only after GF Hi dictates at least one mandatory stop.

My thought is that this little nit, in the small window of dive time where GF Hi does not dictate a stop but GF Lo does (or would), is one that is really up to the discretion of the implementer. So, I don't think either way is "wrong" and they only give different results for a pretty small subset of all dives - with the fuzziness of deco theory rendering that difference meaningless in any practical sense.

I have mixed feelings about how I would want it to work. But, as I am now sold (based on other threads) on using a fairly high value for GF Lo (usually, 50), I think the difference is REALLY irrelevant to me.

In 2015, Neal Pollock wrote on article for Alert Diver on gradient factors Alert Diver | Gradient Factors

This is what he had to say about recreational diving: "Gradient factors were primarily developed for technical diving, but the concept translates directly to recreational diving, particularly use of the GF-high value. The typically slow ascent rates common in modern diving mean that GF low is often not reached unless a low value favoring deep stops (perhaps less than 20) is selected. GF high typically determines the greatest magnitude of decompression stress reached during the dive. Gradient factors are relevant to multilevel as well as square-profile diving."
 
I have been reading the subsurface code, as well as some 2013 mailing list posts about their GF implementation. i am not wildly confident that it is correct, although to be sure I will need to grab the sources and refactor the lines I question to something readable.

if ((surface / buehlmann_inertgas_b[ci] + buehlmann_inertgas_a[ci] - surface) * gf_high + surface <
(gf_low_pressure_this_dive / buehlmann_inertgas_b[ci] + buehlmann_inertgas_a[ci] - gf_low_pressure_this_dive) * gf_low + gf_low_pressure_this_dive)
tolerated = (-buehlmann_inertgas_a[ci] * buehlmann_inertgas_b[ci] * (gf_high * gf_low_pressure_this_dive - gf_low * surface) -
(1.0 - buehlmann_inertgas_b[ci]) * (gf_high - gf_low) * gf_low_pressure_this_dive * surface +
buehlmann_inertgas_b[ci] * (gf_low_pressure_this_dive - surface) * tissue_inertgas_saturation[ci]) /
(-buehlmann_inertgas_a[ci] * buehlmann_inertgas_b[ci] * (gf_high - gf_low) +
(1.0 - buehlmann_inertgas_b[ci]) * (gf_low * gf_low_pressure_this_dive - gf_high * surface) +
buehlmann_inertgas_b[ci] * (gf_low_pressure_this_dive - surface));
else
tolerated = ret_tolerance_limit_ambient_pressure;

They seem to try to track the lowest (deepest I guess) ceiling during the dive and use that in the calculation above, perhaps that is instead of the first stop depth as the GF low anchor.

I wrote that code. And your observation is correct. Subsurface, after all, is a dive log and this is supposed to work on real dives downloaded from dive computers. For those there is no such thing as "first stop", just a stream of depth samples. But we can continuously track the ceiling and the deepest value of that is indeed the anchor for GF_low.

The code is somewhat complicated since to find the next ceiling you have to use the gradient factor at at that ceiling, not where you are at the moment. This involves solving slightly more involved equations. I did that at the time with mathematica and attached that mathematica notebook to the email in which I sent that batch of code. You should be able to find that in the subsurface mailing list archive. If not, let me know and I will try to dig it out.

Best
Robert
 
I wrote that code. And your observation is correct. Subsurface, after all, is a dive log and this is supposed to work on real dives downloaded from dive computers. For those there is no such thing as "first stop", just a stream of depth samples. But we can continuously track the ceiling and the deepest value of that is indeed the anchor for GF_low.

My view, without any experiments, is that would not be the proper behaviour. I'd suggest the anchor ought to be the depth where the profile meets the ceiling (maybe the rounded to next deeper stop depth ceiling).

This would mostly make a difference, I guess, for multi level dives or quite slow ascents.

BTW, why the GF low anchor option in the planner preferences (sorry I can't remember what it is called)? That makes a big difference, and perhaps it contributed to Stuart's confusion above.

Of course GF is full of confusion. Take this graphic which is on a page trying to explain GF. Look closely at the GF line, it extends deeper than the first stop to sme arbitrary ambient pressure where it meets the GF low. No wonder the users have to resort to reading FORTRAN.

https://www.diverite.com/wp-content/uploads/2016/02/image013.png
 
My view, without any experiments, is that would not be the proper behaviour. I'd suggest the anchor ought to be the depth where the profile meets the ceiling (maybe the rounded to next deeper stop depth ceiling).

BTW, why the GF low anchor option in the planner preferences (sorry I can't remember what it is called)? That makes a big difference, and perhaps it contributed to Stuart's confusion above.

I don't think this would work (in a reasonable way) for real dives where you might stay away from the ceiling for quite a bit of the ascent. Plus what we do gives identical or at least very similar plans to many other programs (we checked that), so there seems to be some consensus. Your suggestion would make deco longer since smaller gradient factors apply at shallower depths.

The preferences button is mainly there for historical reasons: At first I thought GFlow had to be anchored at the maximal depth of the dive. Then, upon staring more at Baker's graph figured that would be wrong. But I left the old version in the code as a compile time option and somebody liked to so much that there is now a button for doing this. But I am convinced there is only one correct position of that button and that is "off" (which of course is the default setting).
 
I don't think this would work (in a reasonable way) for real dives where you might stay away from the ceiling for quite a bit of the ascent. Plus what we do gives identical or at least very similar plans to many other programs (we checked that), so there seems to be some consensus. Your suggestion would make deco longer since smaller gradient factors apply at shallower depths.

The preferences button is mainly there for historical reasons: At first I thought GFlow had to be anchored at the maximal depth of the dive. Then, upon staring more at Baker's graph figured that would be wrong. But I left the old version in the code as a compile time option and somebody liked to so much that there is now a button for doing this. But I am convinced there is only one correct position of that button and that is "off" (which of course is the default setting).

So in the planner, rather than the log display, where is the anchor? At the first planned stop or the deepest ceiling?
 
This thread brings to mind a quote from an article commonly attributed to Richard Pyle called "Diving Physics and Fizzyology". The quote is ...

If you ask a random, non-diving person on the street to explain what's really going on inside a diver's body that leads to decompression sickness, the answer is likely to be "I don't know".

If you ask the same question of a typical scuba diving instructor, the answer will likely be that nitrogen is absorbed by body under pressure (a result of Henry's Law); and that if a diver ascends too quickly, the excess dissolved nitrogen in the blood will "come out of solution" in the blood to form tiny bubbles; and that these bubbles will block blood flow to certain tissues, wreaking all sorts of havoc.

Pose the question to an experienced hyperbaric medical expert, and you will probably get an explanation of how "microbubbles" already exist in our blood before we even go underwater; and that ratios of gas partial pressures within these bubbles compared with dissolved partial pressures in the surrounding blood (in conjunction with a wide variety of other factors) determine whether or not these microbubbles will grow and by how much they will grow; and that if they grow large enough, they may damage the walls of blood vessels, which in turn invokes a complex cascade of biochemical processes called the "complement system" that leads to blood clotting around the bubbles and at sites of damaged blood vessels; and that this clotting will block blood flow to certain tissues, wreaking all sorts of havoc. You will likely be further lectured that decompression sickness is an unpredictable phenomenon; and that a "perfect model" for calculating decompression schedules will never exist; and that the best way to calculate the best decompression schedules is by examining probabilistic patterns generated from reams of diving statistics.

If, however, you seek out the world's most learned scholars on the subject of decompression and decompression sickness, the top 5 or 6 most knowledgeable and experienced individuals on the subject, the ones who really know what they are talking about; the answer to the question of what causes decompression sickness will invariably be: "I don't know". As it turns out, the random non-diving person on the street apparently had the best answer all along.


It always amuses me to read expert opinion from people who should have long ago figured out that we ain't got it all figured out just yet ... and that in scuba diving, beyond a few well-used basic rules, there are usually more than one "right" way to do anything, and more than several valid reasons why. Most of them boil down to the fact that the "right" approach to any given dive is going to depend upon a great number of circumstances that are in one way or another dependent upon each other.

The question of deep stops has been hashed about on ScubaBoard ... and the diving world in general ... since before I started diving in 2001, and there are few better answers today than there were back then ... with often-conflicting data to support often-contradictory conclusions. All of this equates to headache-inducing arguments that fly right past both the knowledge and interest levels of most recreational divers.

Suffice it to say, deep stops ... yes, or no, depending on your preference. If you're going to make them, don't overstay your welcome. More isn't necessarily better than less, because while you're stopping, some of your tissues will be offgassing while others are still taking on more nitrogen. It might (though for recreational-level dives probably won't) increase your overall level of nitrogen loading ... again depending on several related circumstances, many of which will be unique to either your physiology or what your specific dive profile looks like. Suffice it to say, coming up slow is generally better than going up fast ... depending on what your definition of slow and fast is.

But rather than dwelling on all the minutiae, my take is that it would be far better for you to pay attention to how you manage that last minute or so of your dive. I've known many people who carefully follow a profile that, deep stops or not, take them to their safety stop. They'll religiously follow their 3-minutes, or 5-minutes, or whatever it was their training told them to adhere to. Then they'll look at each other, give the thumbs-up signal, and 10 seconds later they're on the surface. They just did more damage to themselves than they'll ever do by making a deep stop ... or by skipping it ... or even by coming up to that safety stop a little bit too fast.

That last bit of your ascent needs to take a full 30-seconds. If you're taking anything less than that, then you're wasting your time discussing deep stops, reading articles on all these theories that they use to build decompression algorithms, or making careful selection of a computer for whatever reason you decided was most important to you.

Recreational dives are, by definition, no decompression dives ... so all this theory is nice, but of secondary importance in terms of risk management. Pay attention when it matters most ... which is AFTER you and your buddy put your thumbs toward the surface at the end of your safety stop. That's where slower is better. As for the rest of this stuff ... frankly, there is no "best" approach, except as it applies specifically to one particular dive. And that approach may not be the one that's "best" in your particular case.

"What it all boils down to, is that no one's really got it figured out just yet."
- Alanis Morissette


... Bob (Grateful Diver)
 
Last edited:

Back
Top Bottom