Proposal

[Jan Darowski]

1) yes, I know.
2) I think that we can modify the algorithm a little bit so it will
give the same results as the original one, without strictly specifying
phases of the dive. In fact, there are a few factors modifying
compartments state and we can apply them through all the dive. Just
some of them won't have much impact during some phases. I think that
division into phases has been used to explain the theory more easily.
3) As for now, I don't think the first phase you described would take
too much time... I still think that even with the long studying period
there will be some details discovered during the implementation. And I
need to dive into the Subsurface code before starting coding to know
how to organize it and make compatible with other parts, like the case
from point 2

2015-03-25 10:07 GMT+01:00 Robert Helling <helling at atdotde.de>:
> Jan,
>
> On 24.03.2015, at 21:34, Jan Darowski <jan.darowski at gmail.com> wrote:
>
> Here is my proposal for the GSoC. I believe it's the last thing from
> the projects checklist so if you have any suggestions on how I could
> improve it, please let me know.
>
>
> very nice proposal! Just a few additional comments (in addition to what the
> others have said already). Some of these might also apply to other
> candidates thinking about the VPM-B project:
>
> * We will not replace the old model. The bubble model will be an option the
> user can choose. A large motivation for implementing this model is to give
> the user the possibility to compare the consequences of the different models
> (also for educating divers). So some though will have to go into how to make
> it easy for users to see what they want to see when comparing one model to
> the other.
>
> * In the current code, the Buehlmann model is used in two separate (but of
> course related) places: a) to plan the decompression of future dives and b)
> to plot the ceilings in logged dives so the user can see how the real dive
> compares to the theoretical model. Existing implementations of VPM only care
> about application a) but it would be great to find a way to make it also
> usable for b). Obstacles here are for example that real world dives don’t
> have well defined descent, bottom and ascent phases.
>
> * I would slightly alter the timeline: What you describe should go into two
> phases: The first will be to actually understand the model (by reading
> texts, looking at existing code, stepping through existing code with a
> debugger). To me the duration of this phase is the big unknown. The result
> of that phase could be something like a flow diagram with formulas. The
> second phase will be the actual implementation (I think that will not take
> too much time once we understand the model, I would expect a prototype in
> about a week of coding). This phase already includes debugging, testing and
> comparing to existing implementation. Then we will have to think how to hook
> it up with the existing UI and give the user a good experience (see above).
>
> 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
>                       Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
>                       http://www.atdotde.de
>
> 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
>
>
>
>
>