VPM-B Project - Report
helling at atdotde.de
Thu May 21 01:49:01 PDT 2015
> On 21.05.2015, at 00:11, Jan Darowski <jan.darowski at gmail.com> wrote:
> Here is the current VPM-B project's state:
Thanks a lot for your report. Here are a few comments:
> I've been mostly working on two things: better understanding the
> algorithm and getting through the existing subsurface planning code.
> Lately I've started coding some skeleton of the vpm-b implementation.
> My first idea was to seperate it completely from the Subsurface code.
> Robert Helling told me that there is a lot of code that can be used
> inside vpm-b and maybe I should consider just branching the existing
> code and working on it.
> The problem here is, that current implementation of the planner code
> is completely unprepared for adding new deco algorithms. I would spend
> more time on refactoring and seeking integration bugs than on writting
> vpm-b. So wanting to first focus on the algorithm, I'm creating a new
> code, which includes only few Subsurface files (dive.h, units.h).
> Doing this, I can write implementation based on the Subsurface data
> structures, using helping functions, without loosing control over the
> whole code. Of course my implementation is based on how current deco
> code is written.
Please, please do not reinvent the wheel. There is much more that can be shared. All the code for computing tissue loadings (add_segment in deco.c and related functions) are identical in both algorithms. It is just the surfacing conditions (static double tissue_tolerance_calc(const struct dive *dive)
) that differ (plus an iteration in the case of VPM): For VPM, there are no a- and b-factors but there is a fixed allowed overpressure (that is determined in the “critical volume algorithm).
Please reuse as much code as possible, since in the end we don’t want to have a separate vpm program but we want to have Buehlmann and vpm both in subsurface next to each other so they can be compared. Also doubling code is not a good idea since in later debugging this will lead to terrible problems when the two versions diverge.
> About the algorithm: I've been planning to prepare the first part of
> the algorithms description (what algorithm does before the deco,
> during the dive simulation) by now but it appears to be quiet trivial:
> It calculates gas pressure in the tissue compartments just like
> current deco.c implementation but using more precise Schreiner
> equation (instead of Haldane)
That’s what I mean. So please use the existing code (and if you find bugs there, correct them of course).
The difference between “Haldane” and “Schreiner” are in practice non-exsistant: The true, underlying eqaution for both is
d tissue_pressure / dt = - gamma (ambient_pressure(t) - tissue_pressure) (*)
where for Haldane the solution with constant in time ambient pressure is taken while for Schreiner it can vary linearly. But what we effectively do is simulate the differential equation (*) since we only add segments of at most one minute duration for which it is pretty save to assume the ambient pressure to stay constant over that time. So Haldane is enough. You don’t gain significant precision if you take the variation of depth during that minute into account.
> and keeps track of the maximum crushing
> pressure (difference between gas pressure in the compartment and
> ambient pressure).
Yes, that should be added to add_segment.
> And that's all!
> As soon as my implementation will correctly read input files and
> simulate gas pressures, I will link a repo so anyone could take a look
> at it. I hope it will be done this weekend.
Good. Just keep in mind that in the end the input will just be for Buehlmann in subsurface (i.e. in terms of a struct diveplan) and not in terms of an input file.
Robert C. Helling Elite Master Course Theoretical and Mathematical Physics
Ludwig Maximilians Universitaet Muenchen, Dept. Physik
Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339
Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515 BB44 0820 367C 36BC 0C1D and
DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the subsurface