VPM-B and the current deco algorithm
jan.darowski at gmail.com
Wed May 27 13:41:25 PDT 2015
About the code structure: ok
About the algorithm, yes, that's right.
About schreiner: I don't get it. It's just something like <10
operations more per iteration and we can calculate it not every second
but every sample... For me it sounds like it should be faster. But for
now I won't touch it, it's something that can be checked / changed
2015-05-27 21:38 GMT+02:00 Robert C. Helling <helling at atdotde.de>:
> On 27 May 2015, at 19:22, Jan Darowski <jan.darowski at gmail.com> wrote:
> Hi Jan,
>> The most important thing is if we want both algorithms to be
>> calculated for the current dive and just one of them displayed or
>> should we recalculate the plan depending on the chosen algorithm?
> Let’s go with one algorithm at a time (selected by a preference and combo box). At least for a start.
>> Should I put the new algorithm into current deco. files or should I
>> look for some way to split them? Right now, there is a lot of things
>> in deco which I need in vpmb implementation.
> Again, to get started (we might split files later) add stuff to deco.c and/or planner.c
>> Right now, planner has an ugly plan() function which among others
>> implements the main logic of the current deco algorithm. Can I add
>> plan_buehlmann and plan_vpmb() which will be called from the current
>> plan() function?
> That function has grown over quite some history. Part of the reason why it is so long is that it has to set up a lot of state.
> The other thing that takes up a lot of space is handling gas changes.
> But I believe, most of that function would be shared between Buehlmann and VPM. In fact almost everything, as the only differences are in tissue_tolerance_calc in deco.c. For VPM tolerated = tissue_inertgas_saturation[ci] - constant.
> The only thing is how to fix the constant: You start with a trial constant, calculate a deco schedule (as for Buehlmann with the above noted difference) and for that calculate volume = constant * total_deco_time (plus some surface correction). This volume has to be below a certain value. If it is too big, you decrease the constant and calculate a new deco schedule and thus a new total_deco_time and repeat until you are below the wanted volume.
> So part of the planning has to be called in this trial and error loop before the eventual constant is found.
> At least this is my understanding of basic VPM (there is also some “Boyle correction” but that is really only a correction to this basic algorithm). Correct me if I am wrong.
> Speaking of wrong: What I said in an earlier mail about the reason why transitions in the manually entered part of the dive are interpolated in second intervals was just wrong (I was on the phone and did not have the code for reference). Indeed that part could be replaced by the Schreiner equation. But honestly, I don’t think this would make too much of a difference: This function is not called too often and thanks to Linus’ caching of factors, it does only multiplications while the Schreiner equation needs exponentials so I doubt that that an implementation of Schreiner here would shave off too much execution time.
> Robert C. Helling Elite Master Course Theoretical and Mathematical Physics
> Scientific Coordinator
> Ludwig Maximilians Universitaet Muenchen, Dept. Physik
> print "Just another Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339
> stupid .sig\n"; http://www.atdotde.de
More information about the subsurface