On 27 May 2015, at 19:22, Jan Darowski <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
