No-fly in Subsurface?

[Robert Helling]

Hi all,

I am still far too busy with work related things (this will hopefully get better next week), so just a few remarks:

> On 26.07.2016, at 10:41, Miika Turkia <miika.turkia at gmail.com> wrote:
> 
> I guess this is the only exact information we have gathered so far.
> And of course the DAN recommendations are based on real life testing
> with clear basis of statistical data, but no algorithms behind them.
> Other than that, no info on what the no-fly is based on.
> 
> […]

> How about using the OSTC method of 60% of desaturation but falling
> back to DAN recommendation if that value is higher. The DAN
> recommendations are easy to use even without support from Subsurface,
> but I like to try to keep the DC happy as well when flying. Right now
> it is just guess work, and didn't succeed on my latest attempt :D


I had a look at the OSTC source code

https://bitbucket.org/heinrichsweikamp/hwos_code/src/36a9ac914ce376ec1d1680b61e6c723287e69876/src/p2_deco.c?at=default&fileviewer=file-view-default

void deco_calc_desaturation_time(void)

starting in line 1742.

They define desaturation as the point when a tissue is at 5% over the partial pressure at ambient pressure, i.e. the time until then is

log2( (tissue - ambient) / (1.05 * ambient)) * half_time

so it is logarithmic in the ambient pressure and has a natural maximum since a dive without deco violation has a tissue pressure of the surface m-value times GF_HIGH. So this has a natural maximum of a few hours and every factor of 2 of being less oversaturated subtracts a half-time. As you can see from the comments they lowered the value of 5% several times over the development time, starting from 10% which has one half-time less no-flight time for each tissue.

Then the no-flight time is a user configurable (typically 50-60%) percentage. To me, this makes no sense at all since at the end of the no flight time, the amount of gas in your tissues depends on where you started: If you did a heavy deco dive and your tissues are still at the max, according to the formula, it is ok to fly with more gas in your tissues, i.e. be more aggressive. This makes no sense at all to me.

Physically, this makes no sense to me at all. My guess is it “works” because the possible range of input values (tissue saturations) is quite small, and all you need is a monotonic function  that outputs times in the 12-24 hour ball park. And it does not really hurt if you overdo the no-flying. You could probably factor in the phase of the moon and the outcome would not be much different. Or we take the DAN value which officially is a wild guess.

I haven’t had time to read in the proceedings of the DAN workshop that was linked before. What I saw that came most closely to a recommendation was a report of a plan to do a study trying to bend subjects in a simulated fly after dive scenario. Which is not much that could be put into software. Maybe one should check the Rubicon Archive for more scientific information on the issue.

Best
Robert

--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160726/b58616de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160726/b58616de/attachment-0001.sig>