[PATCH] Unify ceiling calculation between Buehlmann and VPM-B

[Dirk Hohndel]

Hi Robert,

On Sat, Aug 15, 2015 at 04:19:12PM +0200, Robert Helling wrote:
> > Please remind me, what is missing to be able to show VPM-B ceilings for
> > logged dives? I remember there was something about the way VPM-B makes
> > assumptions about remainder of the dive…
> 
> OK, here is VPM-B in a nutshell (not totally accurate but you get the
> idea): It uses the same tissue loadings as Buehlmann to start with.
> Then, for a given loading, one needs to know how far to ascent, i.e.
> what is the minimal ambient pressure. While for Buehlmann that is a
> linear function of the depth (something like
> 
> max. allowed overpressure = const1 * ambient pressure + const2 )
> 
> the max allowed overpressure (“gradient” in the model’s parlance) is
> constant over the ascent. But it varies from dive to dive and is
> determined by the requirement (here is where I am simplifying a bit)
> that the gradient times the total deco time (plus a but for the
> remaining desaturation at the surface) should be below a given value.
> The idea is that the rate at which bubbles are produced is proportional
> to the gradient, so the total number is the gradient times the deco
> time.
> 
> So, one guesses a gradient, computes a deco schedule and thus the total
> deco time. Then the gradient gets adopted iteratively until the
> criterion is met (not even clear to be if the gradient is increased — as
> then the deco is shortened — or decreased as then the first factor in
> the product gets smaller).
> 
> So that is the theory. And for a planned dive, with my patch, we simply
> plot the ceiling based on the gradient that was computed as described in
> the previous paragraph. To do so, we need do know this gradient to which
> we converged to (one per tissue actually), total_gradient[ci]. When not
> in planner anymore, this value is not stored (we could do that but I
> doubt that makes much sense and is not available for real dives anyway),
> so we cannot plot the ceiling outside the planner.
> 
> For a real dive, the above product gradient * deco time could of course
> be replaced by the integral of the gradient over the deco time. But
> different from Buehlmann, where at each point during the dive we can
> check if we violate a ceiling, for VPMB the criterion for a good deco is
> really this integral (representing the total volume of gas in bubbles).
> We can of course print this number (or this number as a percentage of
> the allowed value). But this is not a thing we can plot as a function of
> time.
> 
> What I proposed to plot instead as a function of time is the rate of
> bubbling (i.e. the gradient) in units of the rate accruing to VPM-B to
> meet the criterion assuming the total deco time of the dive.
> 
> Does this explain the problem?

It does, but let me ask the question differently. Let's assume we are on a
dive. So all we know is the profile so far, not what is coming in the
future. So for VPM-B, what would be a sane definition of a ceiling?

a) I think it's pretty clear what the definition of "no ceiling" would be.
   It's if we are able to ascend to the surface at a sane rate and if the
   resulting gradient times duration of the rest of the dive is below the
   threshold.

   Is this correct? Am I missing something?

b) Then I think we could define a "ceiling" as "how far can we ascend so
   that it is still possible for that product to stay below the given
   threshold, correct?

   Let's ignore for a moment how this would be calculated, I'm just
   talking about the definition of a ceiling. And I'll stop here to make
   sure we have a sane definition before I keep going on what we could
   then do with that information :-)

> > Sure, that's a way to do that. We have way too many global variables that
> > hold some state like that :-(
> > 
> > You could just as easily have a helper function that queries the state and
> > is callable from C. That way we only have to keep the actual state once
> > and can simply access it from the C routines as well.
> 
> I tried not to violate the “C++ calls C but not the other way around”
> rule (and, honestly, I did not know how to do it actually.

No, the rule is "core code must no call UI code". We have a bunch of
helper functions in qthelper.cpp for example. And if you run this command

git grep "extern \"C\""

you'll see quite a few examples how to call C++ code from C.

> I am about to leave for my vacation (just taking a break from packing
> bags). I will have internet there but I don’t know when I have time
> again. Right now, I don’t have time to do the helper function, but I can
> promise to look into this once I have time again.

No problem. I just got back from my vacation and went through the patches
that came in the last few days :-)

> > Can you explain this part, please? So with the changes made above
> > deco_allowed_depth() now works in both VPM-B and Buehlmann mode?
> > I'm guessing that's the side effect of adjusting tissue_tolerance_calc()
> > but it would be nice to have that explicitly explained in the commit
> > message.
> 
> Indeed, that was the intention of the whole patch. But, as explained
> above, only if the data in total_gradient[] is valid (which is the case
> only in the planner). Therefore, outside the planner it always uses the
> Buehlmann ceiling.
> 
> Again, I am not on my coding computer, so cannot just send patch with updated commit message.
> 
> Would you mind adding
> 
> “This patch makes deco_alled_depthO() work both for Buehlmann as well as VPM-B (as long as the VPM-B internal variable total_gradient[] is valid).”
> 
> to the commit message if you decide to take the patch?

Yes, I can do that. And I'll take the patch because it works. I'd still
want the helper function in a future patch, though.

> > OK, admittedly that should keep things in sync. Still, it seems rather
> > awkward to me.
> 
> I felt the same. As I said, in a few days, I should be abel to update the to using a helper function (in C++ to be called from C).

Thanks

/D