Spikes: Please try this patch

Rick Walsh rickmwalsh at gmail.com
Mon Sep 18 21:23:50 PDT 2017


Stefan, Robert,

On 18 Sep. 2017 18:40, "Robert Helling" <helling at atdotde.de> wrote:

Stefan,

On 17. Sep 2017, at 22:47, Stefan Fuchs <sfuchs at gmx.de> wrote:

I see a somehow unexpected result:
The situation that the plotted ceiling changes in respect to the spike
being present or not when clicking at the dives in a different sequence is
gone. So resetting additional things seems to be the correct approach
because the result of the deco calculation really shouldn't depend on the
sequence the dives are selected.

But: The spike is now only gone for the one specific dive (#710 in my
example) where I discovered this "unstable" results. Many of my other dives
now still always show such a spike at the beginning of the deco ceiling
exactly as before.
I have the fear we see two different issues here.
I now discovered s.th. else which could help solving the issue: If a plan a
dive in the planner the deco ceiling displayed shows no spike. If I save
the dive and the very same profile is displayed outside the planner in the
"normal" main window view the spike is there. I will send you some pictures
tomorrow and try to generate some debug output.

One more important hint I maybe didn't mention up to now: The spikes in the
profiles are only present if I enable " show ceiling in 3m steps".


Ah, that’s an important clue: Turning on the steps let’s be see the spike
as well. Apparently, it comes from the 5min tissue which has a ceiling of a
few centimetres which gets rounded to 3m.

We have to look into this a bit more to properly understand it. It could
well come from the way that we adopted the VPM model to work for logged
dives (which do not have a well defined bottom time and then stops). Maybe
Rick has some ideas, he wrote that part.


Unfortunately I don't have much time to look into this at the moment, and I
haven't even had a chance to try to reproduce it. My guess is that the
spike in the ceiling early in the dive is related to either:
- the Boyle's law compensation, which relies on deepest ceiling  (or first
deco stop depth in the original VPM-B definition/implementation which was
essentially the same thing for a planned dive that ignores ascent legs like
Baker's Fortran program, but isn't defined for a real dive), but is not
defined in the literature for points leading up to the start of the ascent
(the VPM-B literature is all about planning dives, so the ceiling during
the bottom phase is not considered) and/or
- the Critical Volume Algorithm (CVA), which is an iterative process to
determine an allowable "over" gradient; the iteration converges according
to total ascent time - outside of the planner we use the TTS calculation
(which calls the planning algorithm) for this

Obviously, displaying the ceiling in 3m stop intervals means that at the
end of the no deco time a 1mm fast-tissue ceiling could be shown as a 3m
ceiling spike, then disappear suddenly if the diver ascends a bit.  But by
your report it sounds like this is changing the calculation rather than
just rounding up to 3m steps in the ceiling.



Another observation:

Start from an empty log. Plan a VPMB+2 dive to 30m for 20m. -> no spike
Save. In the logbook, this dive has a spike.
Edit dive in planner, spike gone.
Save again, spike still gone.
Save to xml, quit subsurface
Open Subsurface with this dive: spike reappeaered.
Edit dive in planner: much less ceiling
Delete all computed waypoints ceiling normal again
Save, no spike

This looks like we're failing to calculate a parameter until we open the
planner.  I suspect it's the CVA part, and we start off assuming TTS = 0.
Out of curiosity, is the behaviour the same whether or not TTS is enabled
or not in the profile?

Also, could you check with a binary/release from last year to confirm this
isn't new?  My last VPM-B related commit was 22afd4a1 in April 2016.

Cheers,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170919/9c2d17b5/attachment.html>


More information about the subsurface mailing list