VPM-B oddity

[Rick Walsh]

Hi Robert,

On 11 Sep 2015 01:32, "Robert Helling" <helling at lmu.de> wrote:
>
> Hi,
>
> inspired by some discussion on a diving forum, I tried the following:
>
> Use VPM-B to plan a dive to 43m for 35min with air and EAN50 and EAN100
as deco gases. Without conservatism and with last stop at 6m this gives a
runtime of 65min (18m/min descent 8m/min ascent).
>
> Now add two waypoints, one at a runtime of 5min and one at 7min also at
43m. Then trag the 5min waypoint to greater depth. This makes the runtime
_decrease_, for example for a bounce to 73m to a total of 60min, see
https://www.dropbox.com/s/iiltnbbxumhkavd/Screenshot%202015-09-10%2017.29.42.png?dl=0
>
> I don’t think this is a bug, it’s just an oddity of the model that treats
the deepest point as very special in a dive no matter for how long we stay
there. So this is just for you curiosity (and once more a demonstration how
instructional the instant deco calculation of moving points around in
Subsurface is).
>

I think we are following the model, and I agree it's silly.  I believe the
reason is:
1. Crushing pressure is calculated at the greatest depth.  The crushing
pressure helps get rid of bubbles according to the model.
2. The Boyle's law compensation takes the baseline value as the ceiling at
the start of deco, taken as the end of the bottom phase (last user input
point) of the dive.  A deeper ceiling increases the calculated deco time.

The model assumes that deco starts at the last input point.  This is ok for
a square profile dive.  But for a multi-level dive, especially with a deep
bouncing, it doesn't make much sense.  I think a better assumption would be
that the Boyle's ceiling be taken is the deepest ceiling at any point in
the dive.  This gives very nearly the same result for a square profile
dive, but in a multilevel dive such as your example, the decompression time
would increase with the deep bounce, as one might expect.

We should test the bounce dive in other software as a comparison to see if
they've resolved the issue.

Cheers,
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150911/3b6807a1/attachment.html>