On 20 October 2017 at 12:22, Rick Walsh <[email protected]> wrote:
> > > On 16 October 2017 at 18:20, Willem Ferguson < > [email protected]> 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 <[email protected]> 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 >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
