No-fly in Subsurface?

[Rick Walsh]

On 25 July 2016 at 10:33, Linus Torvalds <torvalds at linux-foundation.org>
wrote:

> On Sun, Jul 24, 2016 at 4:44 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
> > On Sun, Jul 24, 2016 at 4:33 PM, John Van Ostrand <john at vanostrand.com>
> wrote:
> >>
> >> So rather than calculate the deco stop at 0 ft for a safe ascent to
> 8000 ft,
> >> maybe it should do a desaturation to an arbitrary percentage, like 1.5%
> >> above ambient at 0 ft. Isn't 6 half-times considered desaturated?
> >
> > That might be a useful thing to do regardless of no-fly times. And
> > yes, many dive computers seem to consider the two things the same
> > (sometimes with a "no-fly is desat time with a minimum 24-hour")
>
> Side note: I'm not going to have time to look at it, since the merge
> window for 4.8 just started, but I'm assuming that it should be fairly
> easy to just hook into calculate_deco_information() at the end, where
> we have the tissue saturation data set up for the after-the-dive
> situation.
>
> I *think* you could just solve it analytically by looking at each
> compartment, calculating how long to desat for that compartment
> (exponential decay towards surface pressure with the factors for that
> compartment), and just taking the max time.
>
> Sounds like something Robert could do in his sleep in five minutes. Robert?
>
> Or perhaps Rick knows what the VPM-B model considers desaturated.
>
>
> The VPM-B model uses the same method (ok there's a different assumption on
effective water vapour partial pressure but it's nearly negligible) and
same theoretical tissues as Buhlmann to track gas saturation, so the
desaturation time will be the same.  The difference between the models is
in how the allowable gradient (difference between current ambient pressure
and tolerable ambient pressure) is calculated.

Something similar to how Linus calculated the no-fly time could be done
with VPM-B, but I'm pretty certain it would also end up with a very low
no-fly time compared to dive computer calculations and guidelines by DAN
and others.  I don't think we should implement a feature that produces less
than commonly accepted no-fly times, lest someone relies on it and ends up
bent.

I wouldn't be surprised if it could be shown that the Buhlmann method could
be applied to determining no-fly times, but with a different theoretical
'governing tissue' for lower than atmospheric pressure (e.g. flying), which
is slower than the slowest of the 16 Buhlmann tissues.  I have no idea what
half-life the governing tissue would have, or what the corresponding 'a'
and 'b' factors would be.

Being proprietary, I don't think we will ever know how Suunto calculates
no-fly times.  Maybe we could look at data from the dive computer and
back-analyse something.

The OSTC method is apparently just a portion (default is 60%) of the
desaturation time:
http://forum.heinrichsweikamp.com/read.php?2,9870,9878

A no-fly feature could be implemented, but unless an analytical method is
published and accepted, I don't know what the calculations should be.  I
think options for discussion could be:
1) Implement DAN's guidelines without complicated calculations: 12hr for
single no-deco dive, 18hr for repetitive no-deco dive, >18hr (maybe 24hr?)
for deco dives
2) Use the method Linus did previously, along with a really conservative
factor (ignore gradient factor preference) to come up with something
similar to DAN or dive computer calculations
3) Use the OSTC method: 60% of desaturation time (we have to determine how
many half-lives there are in effective desaturation)
4) Use a Buhlmann based method, but with a really slow "tissue", fudged
until we get the answer we expect
5) Something completely different - are there guidelines from someone's
NAVY? NASA?

The problem with all these methods is that they need to be calibrated to
get the expected value (or risk being more aggressive than any other
recommendation).  Unless it's backed by published research, I think I'll
personally stick to DAN's advice.

Cheers,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160725/c94b8b60/attachment-0001.html>