Subsurface planner
Rick Walsh
rickmwalsh at gmail.com
Thu Oct 19 19:04:22 PDT 2017
On 20 October 2017 at 12:22, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
>
> 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;
>
> Actually, that could be quite wrong for saw-tooth profiles such as
Subsurface (4.6.4.986) dive plan created on 10/20/17
Runtime: 83min + 0:34 /m + 0:41 /min
depth
duration
runtime
gas
➘
50m
3min
3min
(18/45)
➙
50m
17min
20min
➚
30m
2min
22min
➙
30m
10min
32min
➘
35m
1min
33min
➙
35m
10min
43min
➚
21m
2min
45min
-
21m
1min
46min
EAN50
-
15m
2min
48min
-
12m
3min
51min
-
9m
6min
57min
-
6m
26min
83min
➚
0m
1min
84min
Try:
/* 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 = t0 && 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/c097bf34/attachment-0001.html>
More information about the subsurface
mailing list