Meaning of GF settings

[Dirk Hohndel]

On January 5, 2013 2:56:59 PM "Robert C. Helling" <helling at atdotde.de> wrote:
>
> On Jan 5, 2013, at 5:35 PM, Dirk Hohndel wrote:
>
> if I understand this correctly, at least in the smooth case, this loop 
> tries to reverse the calculation of the function actual_gradient_limit 
> by trial an error. It tries to find a pressure (i.e. depth) where the 
> corresponding percentage of saturation matches the current maximal) by 
> increasing the pressure until it matches while one could much more 
> easily invert the formula as
>
> pressure_diff = (gf_high - gf)/(gf_high - gf_low) * gf_low_position_this_dive
>
> Furthermore, it seems, gf_low_position_this_dive should be set to the 
> difference between ambient pressure and surface pressure at the deepest 
> point of the dive (where GF_low applies) but this is not in the code. 
> It is only initialized but never again set.

Yes, I noticed that. The original sources set it in their tts 
calculation which I'm not doing.
So I need to do that elsewhere.

> The real origin of the discontinuities is the return statement of 
> gradient_factor_calculation: When the leading compartment changes, 
> indeed as I wrote earlier the tolerated ambient pressure of the two 
> compartments is equal. But the tissue_inertgas_saturation differs as 
> the compartments have different a's and b's. Thus the return value 
> jumps when the leading compartment changes.

OK, that at least explains it...

> I should say that this code is not how I would have implemented GF's 
> according to my understanding of the algorithm. I always thought that 
> at the deepest point of the dive GF_low applies and that at any other 
> depths one uses a linearly interpolated GF between GF_low at max depth 
> and GH_high at the surface. Then one calculates the tolerated ambient 
> pressure for each compartment by computing the pressure excess 
> according to Buehlmann and multiplies this with the GF of the current 
> depth. I.e. I would calculate with pressures or depths rather than percentages.
>
> Let me know what you think but it seems to me deco.c would need a 
> complete rewrite to at least match my understanding of the GF algorithm.

Well, instead of starting with the theory and formulas I decided to 
start with an existing implementation. That's were many of the choices 
and implementation details come from. But with your and Jan's help I'm 
thinking I'm getting a much better grasp of the formulas and may decide 
to redo this.

But my experience is that it is much better to have some half assed 
code and make it better than to wait for someone else to do the perfect 
implementation.

See the planner ui attempt that clearly disgusted Linus enough for him 
to try his hand at ui code again. Of course I was actually hoping that 
someone with some actual skill in that area would step up... :-D

/D