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 <[email protected]>: > Jan, > > On 24.03.2015, at 21:34, Jan Darowski <[email protected]> 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 > > > > > _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
