GSoC Status - Week 7 (VPM-B)

[Rick Walsh]

On 15 Jul 2015 11:38 pm, "Jan Darowski" <jan.darowski at gmail.com> wrote:
>
> Hi, thanks for verification.
>
> 2015-07-15 14:49 GMT+02:00 Rick Walsh <rickmwalsh at gmail.com>:
> > Jan,
> >
> > I was curious and had a peek at your github.  I hope you don't mind.
> > Robert's feedback is what you should be most interested in, but I'll
give
> > mine anyway.
> > https://github.com/Slagvi/subsurface boyle
> >
> > On 15 July 2015 at 06:31, Jan Darowski <jan.darowski at gmail.com> wrote:
> >>
> >> Yes, I've seen this link first time you sent it. Parameters are not
> >> the problem here. We have a different tissue saturation calculation
> >> method, so results differ a little bit at the beginning of the ascent.
> >> So the first stop is a little bit later (6m), It has a big influence
> >> on the total deco time because later gradients are calculated against
> >> this depth.
> >
> >
> > The first thing I noticed was that the critical radii for N2 and He were
> > still 0.8 and 0.7 microns, which is the usual setting for VPM without
Boyles
> > law compensation.  With Boyles law compensation, 0.55 and 0.45 microns
are
> > generally considered to be the nominal values (zero conservatism).  This
> > means that your model was being more conservative than V-Planner's most
> > conservative (+4) setting, which increases the critical radii by 35%.
It is
> > not surprising you've been getting huge decompression times.
>
> I know about the radii, it will be fixed with next pull request but If
> I have it set on the same values in both programs, it shouldn't be a
> problem. (But right now its 0.6 and 0.5, not 0.8, 0.7).
>
> > After changing the critical radii, I compared the total ascent times to
> > published results from V-Planner for 200ft and 300ft trimix dives.
Links to
> > pdf files are about 1/3 of the way down the page.
> > http://www.decompression.org/maiken/VPM/VPM_Publications.htm
> >
> > Just looking at the total ascent time and depth of the first stop, the
match
> > is very good for the 200 ft dives in the 20-60min bottom time range (all
> > total ascent times within 1minute, and appears to be the same first stop
> > depth).  This is impressive.
> >
> > For a 10min bottom time, Subsurface was 3min more conservative, and for
> >>60min bottom time, Subsurface was progressively less conservative than
the
> > V-Planner profiles (e.g. 10min difference in ascent time for 120min
bottom
> > time).
> >
> > For the 300ft dives, Subsurface was less conservative than the V-Planner
> > profiles.
> >
> > Could the differences for longer and deeper dives be due to the critical
> > volume algorithm you mentioned you needed to investigate further?
>
> I was checking against C implementation from github (which is the
> easiest for quick modifications and additional data extraction and
> also is an original codes direct translation). After finding two more
> bugs I got around 20min of difference with the depth of 80m and 30min
> at the bottom (15/45 mix). CVA can't be a problem as I switched it off
> to isolate the Boyles influence. I suspect one more place: the
> original implementation uses projected depths (estimates some maximum
> depth the diver can ascend to) and later verifies it but only in one
> direction. So maybe, that's why for deeper dives it's more
> conservative.
>
> For sure, original implementation has slightly different saturation
> results. But tracing it and saying which way it changes the schedule
> is terrible as it depends on the depth. I would say that <10% of deco
> time difference is the limit. As long as we can stay there, it's fine.
> If you just play with the bottom time (for example increase it by
> 1-2min), you can see that the original code generates very uneven
> schedules.

I agree that is odd.  Essentially it's scaling the algorithm according to
the depth of the first stop. Which would be ok, except there's a step
change between defined stop levels.

But if that's how it is, I think you should stick with that method, flawed
or not, for consistency with other programmes.

>
> --
> Jan Darowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150715/9492c50f/attachment-0001.html>