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