Deco calculation oddities..

Linus Torvalds torvalds at
Fri Feb 8 02:22:15 PST 2013

On Fri, Feb 8, 2013 at 9:08 PM, Robert C. Helling <helling at> wrote:
> You are absolutely right, we only need the maximum of that array. And your
> patch does exactly that. My only excuse is "I did not write that", the array
> was already there in the old version of the deco code and I only modified
> how its elements are calculated.

Ok, good. I was worried about exactly where it matters that we change
GFhigh/GFlow, because for the no-fly code I needed to change that
whole logic.

The fact that the tissue saturation calculations - which is where all
the long-term state is - do not care at all about GFhigh/GFlow means
that I can safely change them in the middle of the logic without
having to worry about it. The gradient factors basically don't change
the long-term "state" of the deco calculations, they only affect the
momentary value.

>> In particular, it turns out that GF_low/high have absolutely *zero*
>> impact on the actual long-term deco calculations - they only matter
>> for the "convert deco state to a pressure tolerance and thus a depth",
>> but not for the state itself.
> I am not sure I understand what you mean by this. The tissue loadings (as
> exemplified in the calculation of tissue_inertgas_saturation,
> tissue_n2_sat[] and tissue_he_sat[] are not influenced by gradient factors.
> I would call that "tissue state" and not neccessarily "deco state".

Fair enough. The above perhaps explains why I worry about the whole
"long-term" vs "short-term" effects: the gradient factors don't change
the long-term effect, so it's perfectly valid to do all the
"init_decompression()" code without worrying about the gradient
factors at all.

And this is important exactly because I wanted to make sure it is
sensible to have different gradient factors over the long term. And
the fact that the gradient factors do not actually affect any of the
tissue calculations make me very happy. But it was very hard to see
that, when there was code that *looked* like it had long-term meaning
that did in fact use the gradient factors.

> They
> only come into play once you want to convert the loading state of the
> tissues to a ceiling (tissue_tolerated_ambient_pressure or tolerated in your
> patch)

Yes. And that can be seen as a "local" decision, ie just a matter of
"exactly how do I interpret the tissue loading as a ceiling", which
can be done at any particular point *without* changing the results for
another point.

IOW, I am much happier seeing that there is no long-term state that is
affected by the whole gradient factor, because that fundamentally
makes it a sensible operation to look at the same tissue loading state
using two different gradient factors.

>> So as far as I can tell, the array should be removed, and replaced
>> with just a single variable in the loop that calculates the per-tissue
>> thing. Something like the attached patch.
> So be it.

Good. I'll write it up with a commit message, and send to Dirk, so
that it's more clear what is long-term "tissue state" that actually
has memory, and what is just "this is the part we use to turn the
tissue state into the pressure we can tolerate".

>> Comments? Am I missing something? Where does that array come from, and
>> why was it done that way?
> Historical ballast.
> Sorry about that

No problem, it just worried me that maybe I didn't understand
something, or that maybe we had a bug in our deco implementation. So I
just wanted to clarify that.


More information about the subsurface mailing list