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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
