Son of Deep Stops *or* Waiting to be merged with the mother thread...

[lowviz]

Well yeah. If you start adding conservatism then you deviate from the model on the side of caution. A little bit of deviation is fine, but things go sour fast. You may find that you are doing an awful lot of unnecessary deco.

Example:
Either my 250' or my 200' Excel sheet contains a "model" for that depth and the stated range. Works fine if you stay close to the given depth and time range. When something works people start to trust it for ever greater things. Per Storker, you don't EVER use an approximation outside of the parameters that it was designed for.

Example:
My sheets work great for either 200 or 250 feet. They were designed for that. You get great numbers in and around the narrow area that is modeled. The model also shows the "lumpiness" expected in something created from observation (Navy Table 5) Look at the differences.

Wow, nice fit. This can be trusted! (that feeling is easily cured)

Just enter a dive to 20 feet for 10 minutes in either of the yellow boxes (calculator) and look at the required deco...

 

[rossh]

Its not intentional though. Its because the models are ******. Its accepted only because there's no other commercially available method outside of manipulating gradient factors.

Good point. Agreed.

But current GF is rather poorly designed for that purpose, because of its compounding issues. If GF is to be used for this purpose,, then It needs to be replaced with a revised or improved design.


The GF needs be modified so gradients are intrinsic to model calculations. Current GF is just an external patch on the end time.

****

The current GF Hi is a simple linear value (% increase) applied to underlying values that are mostly logarithmic in nature. Hence x % increases in GF Hi tends to be an exponential adjustment.

But it gets worse. As a dive grows longer, the slower cells come into play. So the same GF Hi value now gets applied to a longer timed logarithmic value. So the exponential growth goes up a step again.


When GF was being used in small amounts to just shift a ZHL plan a little bit, then these exponential growth errors were not an issue. But today, what you are asking of GF, is beyond its useful and calibrated scope.

.

 

[lowviz]

...//... The current GF Hi is a simple linear value (% increase) applied to underlying values that are mostly logarithmic in nature. ...//... But it gets worse. As a dive grows longer, the slower cells come into play. So the same GF Hi value now gets applied to a longer timed logarithmic value. ...//... When GF was being used in small amounts to just shift a ZHL plan a little bit, then these exponential growth errors were not an issue. But today, what you are asking of GF, is beyond its useful and calibrated scope.

Thank you!

The fog is beginning to lift...

 

[UWSojourner]

The current GF Hi is a simple linear value (% increase) applied to underlying values that are mostly logarithmic in nature. Hence x % increases in GF Hi tends to be an exponential adjustment.

But it gets worse. As a dive grows longer, the slower cells come into play. So the same GF Hi value now gets applied to a longer timed logarithmic value. So the exponential growth goes up a step again.

This behavior of gradient factors is both rational and desirable.

Suppose you are going to be exposed to supersaturation for 30 minutes and you believe 22.5fsw of supersaturation pressure is fine.

Now suppose you double the time to 60 minutes. Should a decompression method lower the allowed pressure? YOU BET. If it holds the pressure constant at 22.5fsw, then it is simply allowing more bubble formation. That's bubble theory 101 -- same pressure, longer time = more bubbles.

The GF method DOES lower the allowed supersaturations in the face of increasing exposure times because the M-Values drop as slower compartments come into play. That's a good feature.

What about VPM-B? It holds the pressure constant for mid-level and above tech dives (basically when critical volume algorithm wears off). That's not a good feature. See this post, and this post for more discussion.

 

[lowviz]

@UWSojourner,
I appreciate you sharing your insights as to total run time. I am starting to compare several models for a fixed 200 foot dive from 20 minutes to 360 minutes. Do you (or anyone else) have suggestions as to additional decompression models to add to the workbook that will aid in the comparison?

 

[KevinNM]

DCIEM? USN E-L? RNPL/BSAC?

 

[rossh]

This behavior of gradient factors is both rational and desirable.....

Gradient Factors, as currently implemented, are a disaster. The current and extended use that you are now proposing is grossly beyond the patch work / add-on method they employ. GF simply cannot be consistent, and are no longer relative to the model they started from.

It's not hard to "fix' GF. All that's needed is to put the adjustment into the model parameters, before it calculates the plan.

I already built a test model ZHL-D.

 

[Storker]

I have a serious problem seeing this

as being described by the top part of your figure. The figure I've linked to shows quite obviously - to me, that is - that the conservatism adjustment(s) come into play before the model parameters are combined with the dive parameters to formulate a dive plan.

(the figure is linked from Gradient Factors | Dive Rite, BTW)

 

[rossh]

I have a serious problem seeing this

as being described by the top part of your figure. The figure I've linked to shows quite obviously - to me, that is - that the conservatism adjustment(s) come into play before the model parameters are combined with the dive parameters to formulate a dive plan.

(the figure is linked from Gradient Factors | Dive Rite, BTW)

That diagram is the simple theory of GF. .... but, the reality, it was not implemented that way. there are more conditions and issues than shown above. The way its coded, is to be patched onto the end of a finished plan. It has compounding time problems, and gets into exponential runaway conditions.

The problem is, when is used in excessive amounts, like x/70, or what you guys are trying to do now. It turns into stretched out chewing gum equations. Nonsense equations... which is what you have now. Its almost completely unrelated to the ZHL where it started from.

If you want to have something that makes grossly over-inflated plans, then invent a new design that can do it properly.


.

 

[Storker]

That diagram is the simple theory of GF. .... but, the reality, it was not implemented that way. there are more conditions and issues than shown above. The way its coded, is to be patched onto the end of a finished plan. It has compounding time problems, and gets into exponential runaway conditions.

If that's correct, the problem isn't the gradient factor which you are criticizing. It's its implementation in the programming.