Subsurface planner

[Rick Walsh]

On 16 October 2017 at 18:20, Willem Ferguson <
willemferguson at zoology.up.ac.za> wrote:

>
> Attached screenshot is 4.6.4.977, downloaded yesterday(Sunday). The VPM
> plan generates an impossible ceiling. Perhaps worth another look?
>
> Thanks for this. Yes, that ceiling is not correct and I can reproduce the
problem (with 4.6.4-986 Windows binary because that's what's working on
this computer, but I don't think anything relevant has changed since).

Based on a little bit of testing I'm doing while I can't do my actual work,
the good news appears to be:
- the issue only relates to the displayed ceiling in the planner, not to
the dive plan itself.
- The tests still pass.
- once the plan is saved, the dive profile is displayed with a reasonable
ceiling, consistent with the dive plan

This is very easy to reproduce for relatively shallow decompression dives
(on air, nitrox or trimix), but I couldn't reproduce the problem for dives
deeper than 20m with air as bottom gas, or for dives deeper than 35m with
21/35 as bottom gas.  That's not to say the displayed ceiling matches the
plan's calculated ceiling exactly, just that the difference becomes
negligible for deeper dives.

In every case where I could reproduce this problem, including your 20m for
60min on air example, the deepest ceiling occurs earlier than it should.
For a constant bottom depth, the deepest ceiling should be at the end of
the bottom time, but in your example the deepest ceiling, 6.1m, occurs
around 30min, and the ceiling at 60min (end of bottom time) is only 5.9m.
The difference in ceiling looks minor, but I think the difference in
duration into the dive when the deepest ceiling occurs plays havoc with the
VPM-B Critical Volume Algorithm (CVA).

The theory behind the CVA is that there's a critical volume of oversize
bubbles that the body can tolerate without resulting in decompression
sickness.  The algorithm takes this logic and permits the calculated
"basic" maximum gradient to be exceeded by a certain amount for the
duration of the decompression phase of the dive.  The shorter the
"decompression time", the more liberal the algorithm is as the basic
maximum gradient will be exceeded for a shorter duration.  When the
decompression time is longer, the opposite occurs.  One issue with this
when dealing with a real dive with data downloaded from a dive computer is
we need to make an assumption as to when decompression starts.  We take it
as the point at which the ceiling is deepest.  This is good, but in the 20m
for 60min on air plan (and other similar cases) the deepest ceiling is
wrongly calculated (but not by much) by the code that determines the
ceiling displayed in the profile when in planner mode. Although the
difference in calculated ceiling is in the order of centimetres, the
difference in dive time means the decompression duration is
over-estimated.  Therefore, the basic maximum gradient is only permitted to
be exceeded by a little bit (because it is assumed it will be exceeded for
longer).

Previously, we took the calculated ceiling and decompression time directly
from the planner (which doesn't calculate the ceiling at each "sample",
just at the entered waypoints and decompression stops) when in planner
mode, but we changed the data structure in the planner since the 4.6.4 and
given my lack of programming ability I couldn't work out how to access this
from the profile ceiling code.

I think the fix is either:
1) Work out how to access the deepest ceiling and importantly time of
deepest ceiling from the planner, or
2) Calculate the deepest ceiling and time of deepest ceiling better for the
profile code when in planner mode (outside of the planner, we calculate the
decompression time separately for each sample, using the TTS code, which
uses the planner to plans an ascent from the current depth and time - we
don't do this is planner mode because that is needless iterations of
potentially hundreds of plans, when we should "know" the decompression time
because we have "the" plan that the planner has calculated)

The following change to core/profile.c:1015 might be a fix based on the
second option, but I don't have a build environment to test.
Change:
                /* If using VPM-B outside the planner, take
first_ceiling_pressure as the deepest ceiling */
                if (decoMode() == VPMB) {
                    if  (current_ceiling > first_ceiling) {
                            time_deep_ceiling = t1;


To:
                /* If using VPM-B outside the planner, take
first_ceiling_pressure as the deepest ceiling */
                if (decoMode() == VPMB) {
                    if  (current_ceiling >= first_ceiling || entry->depth
>= entry[-1].depth) {
                            time_deep_ceiling = t1;

Could someone with a build environment please test?

On 16 October 2017 at 22:29, Stefan Fuchs <sfuchs at gmx.de> wrote:

>
> Hi All,
> Am 16.10.2017 um 10:55 schrieb Rick Walsh:
>
> About the "EAN32" issue (which may not be only restricted to EAN32):
> - Yes, at least the "deepest ceiling before end of bottom time" part of
> the EAN32 issue is still there. And what we see here looks very similar to
> this.
> - Also for this example setup the ceiling calculated inside and outside
> the planner is different
> - For the ceiling calculated outside the planner I also still have the
> effect that ceiling for EAN31 is larger/deeper than for EAN30%
>
>
> I once again investigated the EAN32 dive with the strange ceiling results
> and took some more screenshots.
> What is so strange here:
> Inside the planner the ceiling for EAN32 is already somehow strange. Maybe
> in the same way strange as the examples from Willem.
>
Yes, I think it is related to what's explained above.  It may not always
calculated a "broken" ceiling, but I think it's getting the CVA stuff
wrong.

>
> If I then save the dive and leave the planner, deselect the created dive
> and select it again (pictures "normal view") I see a different ceiling. And
> if I then change the O2 percentage outside the planner I see a even more
> strange effect. Please see pictures.
>
> I see the problem in your screenshots, but wasn't able to reproduce it
with the 4.6.4-986 build I'm using right now.  I'm not sure what's going on
there.

Cheers,

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