Slow tissue on gas from stops

[TrimixToo]

To me, RD, it is less safe because of the human factors. It requires doing math, correctly, underwater, all the time. On a dive where there is no particular stressor you can make mistakes, as happened in John's team. On a dive where things go pear-shaped the probability of a mistake is greater. It's much less likely that I'll read my computers wrong than that I'll make such a mistake, stressed or not. This is exactly what computers are for; to serve us by making complicated things less complicated. Computers are much less fallible than people are, too.

Add to that any shortcomings it might have as a method for calculating ascent profiles that match our current understanding of the most efficient decompression strategies ("least time, best outcome," which was closer to the actual topic of this discussion...I think), and it's clear to me that it should not be anyone's first choice.

The big value I *do* see in RD is that of being able to see whether what your computer is telling you makes any sense and having an alternative that will keep you alive and perhaps uninjured if it fails. Also, if you have two computers, they disagree, and you suspect a malfunction, it's also good to have some clue about which of them to trust for the ascent. For that reason, RD or something else that lets you know your approximate obligation and how to distribute the stop times is a valuable tool to have in one's belt, and in my opinion worth learning about.

I'm fear I'll now hear from the RD crowd that I'm being blind to how much better it actually is, but perhaps its proponents will simply accept that this is my firm opinion even if it happens not to agree with their equally firm opinions, and that mine is unlikely to change unless you can get people like Simon to agree that it's better. Otherwise, I expect the mods to split this into another long thread that will never reach a conclusion in which all agree. I do hope that won't actually be necessary.

 

[Dan_P]

To me, RD, it is less safe because of the human factors. It requires doing math, correctly, underwater, all the time. On a dive where there is no particular stressor you can make mistakes, as happened in John's team. On a dive where things go pear-shaped the probability of a mistake is greater. It's much less likely that I'll read my computers wrong than that I'll make such a mistake, stressed or not. This is exactly what computers are for; to serve us by making complicated things less complicated. Computers are much less fallible than people are, too.

Add to that any shortcomings it might have as a method for calculating ascent profiles that match our current understanding of the most efficient decompression strategies ("least time, best outcome," which was closer to the actual topic of this discussion...I think), and it's clear to me that it should not be anyone's first choice.

The big value I *do* see in RD is that of being able to see whether what your computer is telling you makes any sense and having an alternative that will keep you alive and perhaps uninjured if it fails. Also, if you have two computers, they disagree, and you suspect a malfunction, it's also good to have some clue about which of them to trust for the ascent. For that reason, RD or something else that lets you know your approximate obligation and how to distribute the stop times is a valuable tool to have in one's belt, and in my opinion worth learning about.

I'm fear I'll now hear from the RD crowd that I'm being blind to how much better it actually is, but perhaps its proponents will simply accept that this is my firm opinion even if it happens not to agree with their equally firm opinions, and that mine is unlikely to change unless you can get people like Simon to agree that it's better. Otherwise, I expect the mods to split this into another long thread that will never reach a conclusion in which all agree. I do hope that won't actually be necessary.

Fair play.
You have that opinion, you have every right to it, and I don't have a problem with it.
We must all land on a decision on what our course of action shall be, and I appreciate your views for sure.

Personally, I see diving beyond one's limits as a massive baseline risk in scuba, from dive planning to execution and contingency - I can only speak for myself when I say that I've appreciated forcing myself to think because it's continuously developed my capacity for doing so. During training, I expand my comfort zone, and during diving, I stay within it.

I believe it is our differing views on how to approach the human factor, that seems to differentiate our conclusions on RD - if my brain is the limiting factor, I'll seek to develop it, never "outsource" it.
My logic is that by going the other way, I increase my risk.

Of course, that's just my view on the matter, but I do think recent works on automation include some interesting reads, and I am greatly inspired by the learnings from space aviation in relation to reliance upon automation and value of developing on the human factor.

As for the mistakes, I've got a plan already in place - granted, it can change, but that means I have something in the back of my mind, and agreed upon throughout the team. Any/all deviations from that still go through everybody in the team.

If one is not comfortable with that, I think that's a problem, especially if it's a dive on a good day.
It is my honest view that if one is not comfortable with that situation, one is diving well beyond capacity, which to me is a significantly greater risk than using a deep stop emphasis that is (probably, slightly?) suboptimal.

 

[boulderjohn]

Por que no los dos?

If my computer machine spits out something different than I expect based on RD and prior planning I start investigating. SOMETHING is up. Either the avg depth was different than I thought, my math was off (likely. I run out of fingers real quick), or maybe I put something into the computer box wrong.

So you are allowed to have a computer? We were not.

 

[PfcAJ]

So you are allowed to have a computer? We were not.

I’m in charge of me. Who’s going to “allow” me to have a computer or not?

I’ve been diving with a shearwater for years now.

 

[boulderjohn]

I’m in charge of me. Who’s going to “allow” me to have a computer or not?

I’ve been diving with a shearwater for years now.

I was talking about my UTD years, when as a UTD student the use of a computer was forbidden. I assume that those rules are still in effect for UTD students, but I am happy to be corrected if wrong.

 

[Dan_P]

I know for certain that the standards and procedures are written so that it's up to the instructor/students to decide if using computer or RD.

 

[Nirvana]

I’m in charge of me. Who’s going to “allow” me to have a computer or not?

I’ve been diving with a shearwater for years now.

As my understanding of Ratio Deco goes, the way GUE uses it is to approximate a given algorithm, say Bühlmann ZHL-16c with gradient factors 30/80. Using a computer, therefore, makes absolute sense, as it should, if configured properly, produce a decompression schedule close to what you calculated mentally.

UTD's version, on the other hand, shapes the ascent curve differently from any algorithm used by a dive computer, substantially reducing the usefulness of carrying a computer (except, of course, in gauge mode).

Is this reasonably accurate?

 

[boulderjohn]

UTD's version, on the other hand, shapes the ascent curve differently from any algorithm used by a dive computer, substantially reducing the usefulness of carrying a computer (except, of course, in gauge mode).

When I took Ratio Deco from Andrew, another instructor in the room was on a computer so he could compare every RD plan with an established algorithm. The goal was to show how different each one was in order to emphasize the inferiority of the established algorithms to the UTD version of RD. In the video linked earlier in the thread, Andrew said confidently that the Spinsi study would prove RD's superiority to the Buhlmann-based algorithm to which it was being compared.

 

[Dan_P]

...and Dr. Brambilla, also in a video about the Spisni-study, sided by Dr. Longobardi and Prof. Spisni, said that using the 30/80 in that study was purely for safety reasons.

 

[UWSojourner]

When someone posts a statement to the effect of "RD is dangerous/unsafe/defective", they have no scientific support for that claim. I'd say quite the contrary, as envelopes seemingly need pushing to an extraordinary degree, to show what I'll call a practically actionable difference in results, in regards safe/unsafe.

First, my posts in this discussion about "RD" have been exclusively about "UTD-RD".

Second, you're the culprit who brought absolute terms into this discussion with your "not unsafe" argument. In prior discussions the statements would tend toward something like "UTD-RD is less safe than ..." or "profiles that use UTD-RD deep stops introduce less safety into the profile than those using the same run time that don't." And those types of statements are backed by all the current scientific evidence. So you can have your "not unsafe" placebo. I'll stand by "The current state of research would imply that UTD-RD is less safe than widely used and available alternatives."

Third, since you seem to have taken particular offense at the label "defective", I'll just say this. It was a bit of sarcasm in response to another post (not yours) that was attempting to put the label "effective" on UTD-RD, or on deep stops in general. I argued that it would be difficult to attach that label to UTD-RD after seeing the results of the UTD-RD vs GF study. Unless, of course, you attach "effective" to UTD-RD's name so that it reads "UTD-RDefective". A bit of a poke I admit, but one I enjoyed very much.

Having said that, I don't think "defective" is entirely too strong anyway. A "strategy" that can take 40+% more decompression time and transform that time advantage into a profile that imposes MORE decompression stress on divers HAS to be considered defective in some regard. Trying to salvage the argument with "well it's not unsafe" seems a bit ridiculous to say the least.