Run time

[broady]

I have been comparing my results on Baltic with other Buhlmann GF programs and the overall run time always seemed to be noticeably longer.

Looking further into this I noticed that the addition of stop time to run time isn't always accurate.
For example lets say the current run time is 58 minutes and the stop time is 2 minutes the total run time should be 60 minutes but often it would add an extra minute here and in this example lets say it would show a 61 minutes RT.

This theme does not continue throughout the entire plan however where the stop-time + run-time is usually correct. Random minutes appear to be added to the calculation. I usually find 4 or 5 minutes in my plans have been added illogically.

This can also apply to leaving bottom up to first stop. When a known ascent speed is programmed in I can't understand why random minutes get added.

When I have compared Baltic plans and accounted for all the additional minutes and subtracted them from the plan the total run time is within a minute or so of other Buhlmann GF planners.

I am using exactly the same planning data when comparing programmes and am careful to ensure that the bottom and leave bottom time are the same and these have no bearing on this particular issue with Baltic.

Thank you

[eskil]

Sorry for the late reply - was so tied up with the next update that I
missed your bug report, but here goes ;

I think what you're seeing is the ascent times, and how they're being
accounted for / displayed.

Say that you're at 70fsw/21msw and your RT is 58 minutes at the end of
this stop, and your next stop is at 60fsw/18msw for 2 minutes. Now the
RT at the end of 60fsw/18msw isn't going to be exactly 60 minutes,
since in addition to the stop time, there's also the ascent time to
cover the 10fsw/3msw (it was chosen to not assume that people "slide"
to their next stop, nor that they would bounce up in no time).

With the default setting of 30fsw/min / 10msw/min ascent rate, that
means 18-20 seconds of ascent time (dependon on fsw vs. msw). This
gets added to the total RT, so at the end of 60fsw/18msw stop, the RT
is 60:20 for fsw and 60:18 for msw.

Since rounding down seems "wrong" and displaying seconds for
everything except the descent/level seemed like too much detail, I
chose to round up, so it would be shown as 61.

Internally when computing the tissue loadings for the ascent, it of
course does not round, but assumes a 18/20 seconds long ascent to the
next stop.

So with this way of displaying it (which I should have explained and
made clearer somewhere) you'll see what looks like off by 1 minutes
here and there. However, if you're doing 7 stops, and the RT didn't
account for the ascent time, you'd lose about two and a half minutes
total.

Of course this is carried over to the next stop, so if the 50fsw/15msw
stop is 3 minutes, that would mean the RT at the end of the
50fsw/15msw stop is 60:18 + 0:18 (ascent) + 3 minutes = 63:36 which
gets shown as 64 minutes. This now looks "right" since 61 + 3 = 64
minutes.

When you saw 4-5 minutes being added, would that happen to coincide
with plans where the deco would start around 120fsw/39msw and deeper ?

The beta people that tried it out didn't seem to care about these 1
minutes, but admittedly most of them were probably focused on the
VPM/B based plans and looking more at the total runtime.

Does this alleviate any concerns ?

cheers,
eskil

[eskil]

Hi,

Haven't heard back about this issue. I'm hoping that later releases, particularly the 0.9.5 with ability to turn off ascent rate between deco stops helped with this.

If not, let me know/feel free to reopen this issue.

eskil