On 15 Jul 2015 11:38 pm, "Jan Darowski" <[email protected]> wrote: > > Hi, thanks for verification. > > 2015-07-15 14:49 GMT+02:00 Rick Walsh <[email protected]>: > > 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 <[email protected]> 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
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
