What's with the UTD haters?

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!

Status
Not open for further replies.
Do you use the GUE version of Ratio Deco or the UTD version?

No idea ... I learned it from a NAUI Tech instructor ... :wink:

... Bob (Grateful Diver)

---------- Post added June 25th, 2014 at 01:36 PM ----------

Also, this thread is the epitome of why we need the :popcorn: back.

... it'd only make ya fat ...

... Bob (Grateful Diver)
 
... Bob (Grateful Diver)

---------- Post added June 25th, 2014 at 07:03 AM ----------



I think if I was a UTD instructor I'd cringe every time he posted something.

I don't, personally, dream about his trips. There's plenty of other places I'd really rather go.

... Bob (Grateful Diver)

I was mostly referring to Chuuk.
I have been there once and loved it.
I am looking forward to going back.

I am not involved in this thread in ANY way! LOL!
I stumbled into this thread after clicking the new post sub-menu.

I'll just say....wow!!
 
To be fair, it isn't Ratio Deco itself, but it's elevation to the level of dogma that defies rational justification. I've used it successfully myself for entry level planned deco dives, but I've always cross checked it with one of the other established decompression algorithms (usually ZHL16-B).

I think most of us understand that RD is a useful tool for arriving at a reasonably safe ascent profile using a simple formula that lends itself to mental calculations rather than use of a computer. And we understand that it is successful because it approximates the other algorithm. And that as an approximation, it breaks down outside of its optimum range.

The problem lies in using RD as the only deco algorithm and treating it as a stand-alone model without reference to others. This, I believe goes against that a thinking diver would do.


Sent from my iPad using Tapatalk
 
I was never trained on the GUE version of Ratio Deco, but I was thoroughly versed in the UTD version. I took half of a Webinar conducted by Andrew, I took the full class from Andrew in person (although he never sent the card), and I used it for all decompression dives for several years. Because I had some questions and concerns about the overall concept, I asked a lot of challenging questions. I then had a very detailed email exchange with Jarrod Jablonski of GUE about the topic. I believe there are mathematical differences between the two, but to me the main difference is in the approach to using it, and I think I can explain the reason Aquavelvet referred to it as religious dogma. I will try to compare the two in several ways below. It has been several years since I left UTD, so this might not reflect changes that have taken place since then. If there have been changes, I will happily be corrected.

My first true encounter with the UTD version was in the webinar conducted by Andrew, and one of the students asked about some of the research behind it. She wanted to know how she could be sure it worked. Andrew replied that you had to have faith, meaning you had to have faith in him when he said it works. She was incredulous and made a comment about doing something like that with nothing but faith as an assurance that it worked. In comparison, Jarrod Jablonski explained how the mathematical construct enabled you to create a profile that closely approximated an established decompression theory that had been tested. IN other words, your assurance is that you are recreating very closely an established and tested protocol. In that Webinar, Andrew never mentioned its relationship to any established program.

As Jarrod explained, the GUE version is supposed to approximate closely an established protocol. Jarrod told me that if it departs too far from the established profile, then it is wrong. Students in class are supposed to be able to show that their results are close to that established protocol. When I took the full UTD class, whenever we worked out a profile in Ratio Deco, another instructor worked it out using an established program for comparison. In each case, the differences were celebrated as clear evidence that Ratio Deco was superior to the established programs. Because Ratio Deco is assumed to be correct, any differences showed the defects of the other programs.

According to Jarrod, Ratio Deco only works within a certain range of parameters. Get outside of that range, and it starts to depart too far from the established program on which it is based. According to UTD, UTD's version of Ratio Deco works for all decompression diving.

According to Jarrod, Ratio Deco was created at sea level and has never been tested or recalculated for altitude. He said common sense would tell you that it would have to be adjusted for use at altitude. According to UTD, diving at any altitude does not make enough difference to merit any changes in Ratio Deco. Since I did almost all of my decompression diving at altitude then, I asked Andrew how he knew that. He said that he sometimes dives at Lake Tahoe, and he's just fine using it there as is. Being very concerned with the altitude issue, I pushed it, and I was told that no one has ever been bent at altitude using Ratio Deco. I can name 5 myself. Well, it is true that they were bent, and it was true that they were at altitude, and it was true they were using Ratio Deco, but there was another reason for them being bent. It was not due to Ratio Deco. So what was that other reason? Well, we don't know, but we know it was not because of Ratio Deco. How do you know? Because altitude is not a factor in ratio Deco, so it could not have been the cause.

At that point, I was still using ratio Deco while diving at altitude, and I was still concerned. I made the mistake of writing on ScubaBoard that I was concerned about whether Ratio Deco had to be adjusted for altitude because I knew a couple of people who got bent while using it. That was just about all I wrote. I was contacted by a UTD representative and told that if I wrote anything like that again, I would be reported to PADI for my unprofessional conduct in demeaning another agency. When I asked what I had said that was wrong, they said that after I mentioned that they had been bent, I should have gone on to explain in detail why it had nothing to do with altitude. (I guess I am risking that report right now.) That was pretty much the end of my relationship with UTD.
 
How would a UTD diver plan a 2.5hr cave dive at 80ft average depth?

I think this question clarifies UTD's system doesn't work for all dives.
 
To be fair, it isn't Ratio Deco itself, but it's elevation to the level of dogma that defies rational justification. I've used it successfully myself for entry level planned deco dives, but I've always cross checked it with one of the other established decompression algorithms (usually ZHL16-B).

I think most of us understand that RD is a useful tool for arriving at a reasonably safe ascent profile using a simple formula that lends itself to mental calculations rather than use of a computer. And we understand that it is successful because it approximates the other algorithm. And that as an approximation, it breaks down outside of its optimum range.

The problem lies in using RD as the only deco algorithm and treating it as a stand-alone model without reference to others. This, I believe goes against that a thinking diver would do.

... and that's why I "fly" my computers ... as a sanity check. If they're off by more than a minute or two from what I think the ascent profile should be, then I know I've screwed something up.

Truth to tell, I just don't do planned deco dives that often anymore. Sunday will be the first one since last July, when I was up diving the Great Lakes ...

... Bob (Grateful Diver)
 
I'm pretty sure the origin of the UTD IWR program is with out group diving at altitude in a remote location. We dealt with several of our Type I cases there using IWR. We had the equipment on hand for it, all ready to go. There was talk then about creating a UTD class for what we were doing, but I left before that happened.
 
In fairness, he's diving in relatively warm, shallow spots like Truk. It's not as though he's pushing any boundaries or doing anything noteworthy from an exploration perspective. I'd expect ratio to be just fine in those circumstances.

Except that it apparently doesn't, hence the addition of IWR to the decompression strategy. I don't know, it just seems to me that if the plan includes pretty much expecting to get bent, it might be an idea to take another look at the plan...


Sent from my iPad using Tapatalk HD

---------- Post added June 26th, 2014 at 08:45 AM ----------

Kev, what does NEDU research regarding possible problems with deep stops have to do with strategies for managing decompression over multiple dives/multiple days of diving? I'm not seeing the logic. On-gassing of slow tissues during deep stops has nothing to do with long-term build-up of inert gas in those tissues over extended periods of decompression diving, other than to suggest that you should be using an old-fashioned neo-haldanian model (raw Buhlmann, anyone?) so as to avoid compounding the problem by hanging around deeper during your ascents.

Apart from anything else, Ratio Deco was originally intended to mimic the output from algorithms modified to start decompression deeper - precisely the model that NEDU are suggesting might be flawed. Trying to 'fix' that with IWR rather than going back and re-examining the decompression strategy seems, at best, stubborn.

And I'm genuinely curious to know whether this approach to decompression - "probably bend and hope to mend", perhaps - is something you were trained to use, or you've arrived at it in the course of your own experience.

Edit: For some reason, Tapatalk wasn't showing me the pale grey bit until after I posted. So you're not actually using RD at all, then, but running your dives with either VPM-B or ZH16 on the Petrel?


Sent from my iPad using Tapatalk HD
 
Last edited:
To be fair, DCS incidence is just a probability. Some deco profiles have a higher probability of DCS than others. None of the commonly used deco algorithms put a % risk next to the output, so its exceedingly difficult to state the risk of one profile over another in any meaningful way.

IWR might be a valuable tool if you find yourself bent and far from a chamber (other parameters apply, naturally). Better to be armed with knowledge, imo.

In regards to what ratio deco was designed to mimic, it can mimic any algorithm you want. Just find the trend and apply.
 
To be fair, DCS incidence is just a probability. Some deco profiles have a higher probability of DCS than others. None of the commonly used deco algorithms put a % risk next to the output, so its exceedingly difficult to state the risk of one profile over another in any meaningful way.

IWR might be a valuable tool if you find yourself bent and far from a chamber (other parameters apply, naturally). Better to be armed with knowledge, imo.

In regards to what ratio deco was designed to mimic, it can mimic any algorithm you want. Just find the trend and apply.

Absolutely agree that IWR is a potentially valuable tool - I'm six hours from a chamber if everything slots into place and the timings work out, anything up to a couple of days if there's a problem.

What I don't get is the implicit 'I don't expect my chosen decompression strategy to get me through my planned dives unbent, so I'm ready to rock with IWR' approach. As you say, it's all a matter of probabilities, but I'd be looking for ways to shift the odds in my favour in preference to starting every dive with a FFM hooked up to a G-cylinder of O2.


Sent from my iPad using Tapatalk HD
 
Status
Not open for further replies.
https://www.shearwater.com/products/swift/

Back
Top Bottom