[PATCH] VPM-B: Calculate first_stop_pressure before starting ascent

[Rick Walsh]

Robert,

On 24 August 2015 at 01:25, Robert C. Helling <helling at atdotde.de> wrote:

> Rick,
>
> On 22 Aug 2015, at 07:15, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
> To show what this actually does to the calculated profiles, I have made a
> new column on the Google docs spreadsheet Robert set up.
>
> This gets the calculated profiles noticeably closer to those calculated by
> other software, except for the multi-level dive (20m for 10min, then drop
> to 60m for 30min).
>
>
> are you sure, you computed the data in the spread sheet with what you
> actually sent as a patch?
>
> With you patch I just reproduce the old run times. But when I take the
> ceiling rather than rounding to the next stop depth (your stupindex
> gymnastics) I get the runtimes you reported in the table.
>
>
Short answer:
My patch changed the 100 m / 60 min trimix dive total time to be 316 min
(as reported in the Google spreadsheet).
Commit 41349c29ddc45e7c19fc287f10fa8f6712bcf111 (Prepare global state of
VPM-B when starting to plan) changed the total dive time to 319 minutes,
but for a couple of shorter dives I tested had no effect.
Removing the rounding gymnastics makes it slightly less conservative (but
more logical) in at least some cases, but I think it's a coincidence that
it also ends up with 316 minute total dive time.

Long answer:
Before sending my patch, I tested the effect of calculating the Boyle's law
"first stop" at various places in various methods the code: before the CVA
iterations rounding depth to next stop (my patch, and I agree the rounding
bit makes little sense but the result appeared to be consistent with other
software), before the CVA iterations without rounding, at the start of the
CVA loop with the rounding (my initial guess at what would match other
software but there's a good reason not to do it inside the CVA loop).  I
also tested the effect of changing back the trial ascent function to use
the incremental ascent like we do with Buhlmann (very minor effect as a 3m
ascent only takes ~20s, depending on ascent rate).

When I read your email, I assumed I must have reported the result (at least
for that run) from the wrong trial build.  That would have been an easy
mistake for me to make as I had 6 instances of Subsurface open at once,
each built from slightly different code.
But I went back to my local branch (git is great) where I prepared the
patch, and sure enough that produced the 316 minute total dive time.  From
there, I checked out at each commit until I found where the change
occurred.  I know git bisect is the tool designed for this, and I'm sure
easy to use, but I haven't worked it out yet, so I did this manually.

As usual, I need to go to work and don't have time to work out how your
Prepare global state patch changed the calculation, and whether the new or
old behaviour is more correct.

Cheers,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150824/f4a30494/attachment.html>