VPM-B and the current deco algorithm

[Robert C. Helling]

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.

Best
Robert

--                                                                              
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO 
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 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150527/7dbb5dc7/attachment-0001.sig>