[PATCH]Re: Deco calculation for repetitive dive - strange effect

Linus Torvalds torvalds at linux-foundation.org
Tue Feb 7 15:33:42 PST 2017


On Tue, Feb 7, 2017 at 3:09 PM, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
>
> On 8 February 2017 at 07:24, Robert Helling <helling at atdotde.de> wrote:
>>
>> I guess (as so often) Linus is right, we should reset the state between
>> dives (except of course tissue saturations) to get rid of this anomaly, and
>> if other code does that even better.

So you really should not assume I'm right.

Quite frankly, I didn't make any sense of the C code. The code that
handles the "repetitive" flag will indeed do some surface-interval
correction and then clear some of the fields (those max crushing
values etc).

But if the repetitive flag is *not* set, it clears no data at all,
which makes even less sense (ie it does not reset anything at all in
between dives, and instead just seems to continue with the old state
for the next dive).

>> I attach a patch that does this.
>>
> This is entirely sensible and rational and makes sense to me.

So I agree that that patch seems to make sense within what subsurface does.

But the logic in the actual VPM-B python/C implementation (which is
supposed to be a straight translation from the Fortran one - I do not
want to even look at Fortran code, so I skipped that entirely) made
very little sense to me, so I'm at a loss to what the "real" behavior
is really supposed to be.

So I agree very much with Rick on the following "But":

> But...
>
> In the last paragraph of an article by Eric Baker, he states, "The
> "crushing" (i.e. compression) and slow regrowth of gas nuclei providee an
> explanation of the common qualitative observation that greater pressure
> reductions can be tolerated on repetitive dives than on first dives."  He
> then discusses that no decompression limits may be greater (!) for
> repetitive dives, and a hypothetical commercial diver who tolerates
> multi-day repetitive dives but gets bent on the first dive after returning
> from vacation.

So I really don't know. The VPM-B code make very little sense to me in
general. The whole "keep track of various maximums so far" really
seems a fundamentally bad idea due to the whole odd special cases it
causes. As Robert points out, you get different behavior when you
consider your surface interval to be just a small break inside one
dive than if you consider it to be two dives with a surface interval
in between.

                 Linus


More information about the subsurface mailing list