Re: VPM-B Patches for discussion
I agree that these commits would make the code cleaner and easier to understand. So if their influence on the plan is insignificant, they should be applied. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: planner / VPM-B patches
2015-08-18 13:12 GMT+02:00 Robert C. Helling hell...@atdotde.de: On 18 Aug 2015, at 12:18, Davide DB dbdav...@gmail.com wrote: Ok Should we copy the entire profile or just the runtime? :) Let’s do the entire profile, getting the runtime from there should be trivial in a spread sheet. Here is the link: https://docs.google.com/spreadsheets/d/1ZWs6eOW2pF4yBRRj4JYtVxIr0vlyFNxS9Z4nka2PP6k/edit?usp=sharing Please give me a few minutes to set it up. Best Robert Hi! Thanks for doing this. Here is one more small patch that fixes when Boyle's compensation is run. It's important when the first gas change during the deco is before the first deco stop. -- Jan Darowski From 81a792e1209e0943b6ff848c1b54467b5066845c Mon Sep 17 00:00:00 2001 From: Jan Darowski jan.darow...@gmail.com Date: Tue, 18 Aug 2015 13:20:56 +0200 Subject: [PATCH] VPM-B: Fix calculating Boyles compensation on gas change stops. Previously we were calculating the compensation only on the deco stops, gas change stops appearing before the first deco stop were ommited. Signed-off-by: Jan Darowski jan.darow...@gmail.com --- planner.c | 5 + 1 file changed, 5 insertions(+) diff --git a/planner.c b/planner.c index a4aacc0..f9ede6e 100644 --- a/planner.c +++ b/planner.c @@ -1167,6 +1167,11 @@ bool plan(struct diveplan *diveplan, char **cached_datap, bool is_planner, bool plan_add_segment(diveplan, clock - previous_point_time, depth, gas, po2, false); previous_point_time = clock; stopping = true; + +// Boyles Law compensation +if (first_stop_pressure == 0) + first_stop_pressure = depth_to_mbar(depth, displayed_dive); +boyles_law(first_stop_pressure / 1000.0, depth_to_mbar(stoplevels[stopidx], displayed_dive) / 1000.0); /* Check we need to change cylinder. * We might not if the cylinder was chosen by the user -- 2.2.2 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] VPM-B
I think that currently first_stop is being calculated for each stop (so isn't actually first_stop) rather than just the first. That's what it looked like from my limited running under gdb with a break every time first_stop is calculated, and printing the depth variable. To calculate the first stop for every cva iteration we need to be more clever than what my patch does, but I'm not sure you'll get a very different resulting plan. From my understanding, cva is significant for short deco / no deco dives, whereas Boyle's law compensation is significant for long deco dives. I can't reproduce this. I've checked, there are only two places setting this variable, the only place it's used is passing it to the boyles_law(). Printing it there gives the same value several times... -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] VPM-B
I think I've worked out at least one difference in the programs' algorithms, and sorry I doubt you'll like it. Subsurface calculates required stops considering the ascent rate and the time to reach the stop. The Fortran program calculates the 'instantaneous' ceiling, i.e. the depth corresponding to the tolerated ambient pressure according to the current allowable pressure gradient. More fun! Which approach is more justified? Debatable. The method used by Subsurface should be 'better', but when the depth of the first stop/ceiling is given a special significance thanks to the Boyles law compensation process, I'm not so sure. The 'instantaneous' ceiling method is more conservative, and, without having modified the code and tested, I'm guessing would produce deco schedules more consistent with other VPM-B programs. R I expected something like this... calculations are checked, gradients are checked. It had to be something mechanical. For the examples you've posted I got 16 vs 16min and 46 vs 49min after the fix (in trial_ascent I changed the segment time to 0 and added one more place for boyles_compensation). Thanks a lot for this, I spent many days on searching for bugs in this code. I suppose there can be some other small issues but this one explains a lot. Today there will be a patch for this. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Re: [PULL REQUEST] VPM-B
2015-08-17 17:54 GMT+02:00 Robert C. Helling hell...@atdotde.de: Hi, On 17 Aug 2015, at 15:44, Rick Walsh rickmwa...@gmail.com wrote: Which approach is more justified? Debatable. The method used by Subsurface should be 'better', but when the depth of the first stop/ceiling is given a special significance thanks to the Boyles law compensation process, I'm not so sure. The 'instantaneous' ceiling method is more conservative, and, without having modified the code and tested, I'm guessing would produce deco schedules more consistent with other VPM-B programs. I thought a bit about this. To me, it does not make much sense to ascent only if I can „see“ the ceiling is above the next stop and not to ascent as long as we don’t violate the ceiling. On the other hand, one could argue this behaviour is part of the definition of the model and has been tested as such (or otherwise, some of the constants would have to be changed). So maybe the best might be to let the user decide. So here is a patch that adds this as a preferences value (so far without UI, so to test it, you have to set it in the code). On the other hand, we don’t want to confuse the user with too many options. And what is a reasonable default? Set this to false for Buehlmann and to true for VPM-B or maybe even only make this an option for VPM-B? Best Robert In my opinion we shouldn't leave this as a preference, it's to technical and complicated to explain to most of users. We have the conservatism levels already, so users can manipulate how aggressive their schedule is. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] VPM-B
Hi, I've looked at and tested your latest series of VPM-B commits. From what I can see, it looks like it's doing the correct thing, except that first_stop_pressure is reset to zero every iteration, so it then gets set each stop (rather than just at the first stop) before running the Boyle's law compensation. The upshot is that the Boyle's law compensation isn't work as intended and an overly aggressive profile is calculated. The attached patch brings the line that sets first_stop_pressure to zero outside the loop, so it is only run once. Please have a look at what it does. Have you checked that it improves the deco time? CVA (the do loop) runs several simulations of the deco. For each of these simulations, first stop can happen to be at the different depth (to be specific: later iterations have bigger gradients, first stop can be later in time, on lower level). What you have done here, is assuming that each simulation has the first stop at the same level as the first simulation. I will check it but it doesn't sound like a correct solution for me. The problem is, the algorithm isn't precisely specified anywhere, so the only criterion of correctness is comparing against other implementations... And they differ. Yay! -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] VPM-B
Hi! Here is my next pull request, it adds all the remaining vpm-b elements. What is left to code is some way of logged dives rating against vpm-b and probably some fixes. The following changes since commit 342479586d1f34a2b7f3d1d69037cb0d631489fa: Planner: use the heap for note buffers (2015-08-10 00:04:17 -0700) are available in the git repository at: https://github.com/Slagvi/subsurface boyle-ready for you to fetch changes up to ffe2884f72ace4d04158b72fc806823c87a62e4b: VPM-B: Set radius constants to values reccomended by V-Planner. V-Planner reccomends smaller values for the VPM with the Boyles compensation. Also missing units comments were added. (2015-08-15 15:55:46 +0200) Jan Darowski (7): VPM-B: Fix trial_ascent() for vpm-b. Previously, current depth was checked, instead of the depth after the move. VPM-B: Add simple Boyle's law compensation. This is a very basic implementation that uses bin search for solving the cubic. It's not called anywhere at this stage, needs to be changed to analytic solution. VPM-B: Add Boyles compensation to the planner. VPM-B: Add surface decompression time. Now, we calculate the volume of free gas not only based on the deco time but also time on the surface, needed for the full desaturation. VPM-B: Add conservatism levels to deco.c VPM-B: Add conservatism levels to the ui. Fix planner settings disabling. Conservatism level can now be changed from gui, is saved in settings. Also way of disabling the planner settings in the ui was improved to support more deco models and be called at the widget creation. VPM-B: Set radius constants to values reccomended by V-Planner. V-Planner reccomends smaller values for the VPM with the Boyles compensation. Also missing units comments were added. deco.c | 115 dive.h | 3 ++- planner.c | 13 -- pref.h | 1 + qt-models/diveplannermodel.cpp | 6 + qt-models/diveplannermodel.h | 1 + qt-ui/diveplanner.cpp | 60 +++--- qt-ui/diveplanner.h| 2 +- qt-ui/plannerSettings.ui | 228 -- subsurfacestartup.c| 3 ++- 10 files changed, 275 insertions(+), 157 deletions(-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (VPM-B)
Hi, thanks for verification. 2015-07-15 14:49 GMT+02:00 Rick Walsh rickmwa...@gmail.com: Jan, I was curious and had a peek at your github. I hope you don't mind. Robert's feedback is what you should be most interested in, but I'll give mine anyway. https://github.com/Slagvi/subsurface boyle On 15 July 2015 at 06:31, Jan Darowski jan.darow...@gmail.com wrote: Yes, I've seen this link first time you sent it. Parameters are not the problem here. We have a different tissue saturation calculation method, so results differ a little bit at the beginning of the ascent. So the first stop is a little bit later (6m), It has a big influence on the total deco time because later gradients are calculated against this depth. The first thing I noticed was that the critical radii for N2 and He were still 0.8 and 0.7 microns, which is the usual setting for VPM without Boyles law compensation. With Boyles law compensation, 0.55 and 0.45 microns are generally considered to be the nominal values (zero conservatism). This means that your model was being more conservative than V-Planner's most conservative (+4) setting, which increases the critical radii by 35%. It is not surprising you've been getting huge decompression times. I know about the radii, it will be fixed with next pull request but If I have it set on the same values in both programs, it shouldn't be a problem. (But right now its 0.6 and 0.5, not 0.8, 0.7). After changing the critical radii, I compared the total ascent times to published results from V-Planner for 200ft and 300ft trimix dives. Links to pdf files are about 1/3 of the way down the page. http://www.decompression.org/maiken/VPM/VPM_Publications.htm Just looking at the total ascent time and depth of the first stop, the match is very good for the 200 ft dives in the 20-60min bottom time range (all total ascent times within 1minute, and appears to be the same first stop depth). This is impressive. For a 10min bottom time, Subsurface was 3min more conservative, and for 60min bottom time, Subsurface was progressively less conservative than the V-Planner profiles (e.g. 10min difference in ascent time for 120min bottom time). For the 300ft dives, Subsurface was less conservative than the V-Planner profiles. Could the differences for longer and deeper dives be due to the critical volume algorithm you mentioned you needed to investigate further? I was checking against C implementation from github (which is the easiest for quick modifications and additional data extraction and also is an original codes direct translation). After finding two more bugs I got around 20min of difference with the depth of 80m and 30min at the bottom (15/45 mix). CVA can't be a problem as I switched it off to isolate the Boyles influence. I suspect one more place: the original implementation uses projected depths (estimates some maximum depth the diver can ascend to) and later verifies it but only in one direction. So maybe, that's why for deeper dives it's more conservative. For sure, original implementation has slightly different saturation results. But tracing it and saying which way it changes the schedule is terrible as it depends on the depth. I would say that 10% of deco time difference is the limit. As long as we can stay there, it's fine. If you just play with the bottom time (for example increase it by 1-2min), you can see that the original code generates very uneven schedules. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 7 (VPM-B)
Yes, I've seen this link first time you sent it. Parameters are not the problem here. We have a different tissue saturation calculation method, so results differ a little bit at the beginning of the ascent. So the first stop is a little bit later (6m), It has a big influence on the total deco time because later gradients are calculated against this depth. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 7 (VPM-B)
Hi! This week I wrote a Boyles law compensation and checked all the calculations to find the root of the differences of results against the original implementation. I found that there is a difference between the code and papers in one of the CVA formulas. I need to add one more calculation, which will estimate the time at the surface required for the diver to fully regenerate. Another important thing, is that the Boyles law compensation seems to be just stupid. It scales the allowable gradients based on the nucleons radius at the first deco stop. The problem is, even very small difference in the tissue saturation or different way of ascent simulation can cause the diver to have the first stop sooner or later. Then, gradients are scaled against different radius, which has a huge influence on the total deco time. I will confirm it but for now, on one of the tests I had a minute of difference without Boyles compensation and 235 vs 289min with it on. That's way too much. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 6 (VPM-B)
Hi! This week I spent mostly on testing and refactoring my commits. I also started the promised article and checked how the Boyle's law compensation should work. I still haven't discovered where some of the result differences come from, I want to finish it this week but it's hard to predict how much time it will take. I will also implement Boyle's law compensation and finish the algorithm's description. Then the great testing will come but it will probably the next week. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Analytic solution rather than binary root search
Of course, I'm working on it right now, should be ready tonight.. 2015-07-03 6:09 GMT-07:00 Dirk Hohndel d...@hohndel.org: On Thu, Jul 02, 2015 at 08:49:29PM +0200, Jan Darowski wrote: Solution tested, results the same as with existing implementation. Great. I assume that I will get a pull request from you with re-done patches. Feel free to include Robert's patch in that as well. Thanks /D -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] VPM-B
Hi, here is the link to the results of some tests I did. https://docs.google.com/spreadsheets/d/1jrafQsE9bwHLszJadYzRlD2zBD57UB7TIAh2Xz0o-XQ/edit?usp=sharing Some comments: As you can see the are some cases when results differ. Test 4: starting gradients are the same, final gradients differ a lot. I suspect that it can be caused by the different deco time calculation. Test 8: almost no difference between gradients. Possibly time difference caused by the time granularity in both programs. ~30 stops can have a huge influence. I'm not a diver myself so please, If you have any comments on the results or any cases that I should test please, tell me. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] VPM-B
Dirk: fine, I agree that these commits aren't of the highest quality. One of the reasons is that this work is based in huge part on the existing implementation which I had to discover part by part and which has a lot of strange solutions (including units and constants scaled all the time). The other reason is probably my negligence. I hope to have all of this repaired by Friday. 2015-06-30 21:43 GMT+02:00 Robert C. Helling hell...@atdotde.de: Now for less formal aspects: I computed a few schedules with your code and they seem to be not totally off (I did not compare them to the output of other programs that claim to compute vpm-b, yet). I guess you did. Could you please post those tests (the dives you did your benchmarking on and what the other programs said)? I will send this in the evening, I used the implementation from github, with the Boyle's law compensation removed. I haven't implemented it yet and it changes results a lot. Tests were pretty simple, I can't say that it's tested on all cases and proved correct. Something that applied to the old Buehlmann code as well: We should define the constants in useful units, so we don’t have to convert them before we can use them. In particular I am thinking of all half-times (including the regeneration time) which, currently we state in minutes but use (as all times) in seconds. We could simply add „* 60“ in all the initialisations so the multiplication is done at compile time rather than at runtime. Agreed. The plan() function is by now a huge monolith. We should break it into digestible pieces. The problem is of course all the state held in its local variables. Maybe those should be put in a struct and a pointer to that passed around. Yes, something should be done with this. I've been thinking about something similar to the saturation state cache. There is one thing that I did not expect: I printed the final allowable gradients and the deeper and longer the dives get, the gradients increase. I must say I expected the opposite. But maybe that is my flawed understanding of the model. Without thinking too much: it's fine for the deeper dives to have bigger gradients. The smaller the radius at the start of deco, the bigger the gradient (bigger pressure needed to make the nucleon turn into bubble). Gas saturation in the tissue increases slowly during the descent so if we descent quickly, nucleon shrinks a lot (gas pressure inside the bubble much bigger than saturation), so quick, deep descent - big gradient. Longer time at the bottom should let the saturation increase, making the nucleon bigger and decreasing the gradient... But besides nuclear regeneration algorithm seems to completely ignore this part of the dive (the saturation increases so the first deco stop is deeper what increases deco time but that's not connected to the gradient). I will test this, maybe I'm missing something. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 5 (VPM-B)
Hi, This week I've solved all the remaining problems with the CVA and added ui deco algorithm selection. I've modified the original code so I could test the results. On few tests I run difference was ~1min. It's pretty good as we have completely different saturation calculation implemented. On Friday I've rebased my changes and prepared for merging with master. This week I will write the promised paper about the algorithm and maybe add Boyle's Law compensation. What also needs to be done is optimization of some calculations. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] VPM-B
Hi, here is the request for the basic vpm algorithm. Right now it doesn't include Boyle's law compensation so the deco plans it generates can be too short in some situations. The following changes since commit f763da66b3db17347954272b9f856df6f8b9888d: Implement planner option to switch only at required stops (2015-06-26 06:14:28 -0700) are available in the git repository at: https://github.com/Slagvi/subsurface.git beta-vpm for you to fetch changes up to 2ce3f0289d446a1b32a932128f1640dc0bc11291: Cleaned up VPM-B work, improved coding style, removed redundant conditions. (2015-06-26 20:47:13 +0200) Jan Darowski (11): Added basic VPM-B deco algorithm settings. Added crushing pressure state and is_vpmb parameter. Added basic crushing pressure calculation, without calculating current radius in the impermeable part. Added simple radius calculation for crushing pressure. Using bin search with const number of iterations. Refactored crushing pressure a little bit. Added simple nuclear regeneration. All the parameters for the deco should be ready. Probably units adjustments needed. Fixed vpmb rs value in nuclear regeneration. VPM-B improvements: Scaled constants Added initial supersaturation calculation Fixed minor calculation bugs VPM-B critical volume algorithm implemented VPM-B CVA fixed. Added ui option to choose deco algorithm. Cleaned up VPM-B work, improved coding style, removed redundant conditions. deco.c | 168 +++ dive.h | 4 + planner.c | 298 - pref.h | 8 +- qt-models/diveplannermodel.cpp | 6 +- qt-models/diveplannermodel.h | 2 +- qt-ui/diveplanner.cpp | 20 ++- qt-ui/diveplanner.h| 2 + qt-ui/plannerSettings.ui | 23 +++- subsurfacestartup.c| 4 +- 10 files changed, 398 insertions(+), 137 deletions(-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 4 (VPM-B)
Hi! Last week I've managed to fix previous problems with crushing pressure calculation and implemented critical volume algorithm for vpm-b. It means that now we can generate vpm-b based deco plans. I've spent a lot of time on finding the way to merge this new method with the previous algorithm but I think the result is fine. Now I will focus on testing these deco plans, integrating with Subsurface (ui part) and cleaning up the code. By the end of the week, code should be ready for pull request. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: GSoC Status - Week 1 (VPM-B)
Hi, right now I'm getting first deco plans from the vpmb algorithm so It's time to add some ui option to switch between algorithms. For now, a simple check box in the planning section should be enough (just like for the recreational dives). Maybe later there will be some more parameters to specify. Do you want to do this as proposed or maybe you're busy and I should do it? Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Reproducable hang when using edit dive in planner on non-planned dive
ok. 2015-06-15 6:24 GMT+02:00 Dirk Hohndel d...@hohndel.org: On Mon, Jun 15, 2015 at 12:25:43AM +0200, Jan Darowski wrote: First problem from the daily build of subsurface hangs (reproducable for me) thread solved: in planner.c unsigned int stoplevels were compared with int depth. Thanks for tracking this down, Jan. Much appreciated. Can you look at the commit that I pushed? I changed your commit message. You had everything in the commit title - that should be shorter and more to the point. And there's some magic syntax for the references to tickets - this way the ticket gets automagically closed with a reference to your commit /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] Reproducable hang when using edit dive in planner on non-planned dive
First problem from the daily build of subsurface hangs (reproducable for me) thread solved: in planner.c unsigned int stoplevels were compared with int depth. Jan Darowski From ed0d74a067e2dd33e83bc4f5c48bc453d4b1eb1a Mon Sep 17 00:00:00 2001 From: Jan Darowski jan.darow...@gmail.com Date: Mon, 15 Jun 2015 00:20:09 +0200 Subject: [PATCH] Fixed ticket 880 reproducable hang when using edit dive in planner on non-planned dive unsigned / signed int comparing. Signed-off-by: Jan Darowski jan.darow...@gmail.com --- planner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/planner.c b/planner.c index ad855e6..c8578c3 100644 --- a/planner.c +++ b/planner.c @@ -1028,7 +1028,7 @@ bool plan(struct diveplan *diveplan, char **cached_datap, bool is_planner, bool TIMESTEP, po2, displayed_dive, prefs.decosac); clock += TIMESTEP; depth -= deltad; - } while (depth stoplevels[stopidx]); + } while (depth 0 depth stoplevels[stopidx]); if (depth = 0) break; /* We are at the surface */ -- 2.2.2 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 2 (VPM-B)
Hi! This week I've added two things: nuclear regeneration and crushing pressure calculation. There still is one place that requires a better solution but all the data needed for the deco simulation is in place. This week I will start from calculated results verification and probably later I will add the basic deco. Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 1 (VPM-B)
Hi! This week I started from creating the new repo for my work: https://github.com/Slagvi/subsurface vpm-b branch As I had to change my plans about the implementation, I needed to get more familiar with the planner code which took some time. Then I started implementing the first part of the algorithm, extracted needed algorithm settings from the other implementation and added them to the existing code. I spent some time on planning how to implement next parts, tomorrow crushing pressure calculation should be ready and I will start checking if existing saturation calculation is similar to results from the other c implementation. I'm not sure about it, as it's calculated differently and I already spotted some differences in constants values. Today I finished some big projects at the university so I should be able to catch up with the project a little bit. There shouldn't be any problems with reaching the first big milestone: having a basic implementation of the algorithm on 14.06. Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
VPM-B and the current deco algorithm
Hi! If as Dirk said, you guys want to have a constant access to my work and relatively often merge it with master, I need to change my approach a little bit (I wanted to first implement the algorithm, independent from the rest of the source, then integrate it). Maybe it's a good idea to keep it integrated all the time. But it leads to some questions about how this new algorithm should work with the current deco implementation: 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? 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. 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? Thanks, Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: VPM-B and the current deco algorithm
About the code structure: ok About the algorithm, yes, that's right. About schreiner: I don't get it. It's just something like 10 operations more per iteration and we can calculate it not every second but every sample... For me it sounds like it should be faster. But for now I won't touch it, it's something that can be checked / changed easily later. 2015-05-27 21:38 GMT+02:00 Robert C. Helling hell...@atdotde.de: On 27 May 2015, at 19:22, Jan Darowski jan.darow...@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 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
VPM-B Project - Report
Hi! Here is the current VPM-B project's state: 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. 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) and keeps track of the maximum crushing pressure (difference between gas pressure in the compartment and ambient pressure). 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. Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
VPM-B Project
Hi! Thanks for accepting me as a GSoC participant! I hope to meet your expectations and add some useful features to the project. It's going to be a busy and exciting summer. Regards, Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Proposal
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 hell...@atdotde.de: Jan, On 24.03.2015, at 21:34, Jan Darowski jan.darow...@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 0C1Dand DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Proposal
Hi! 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. Jan Darowski subsurface.pdf Description: Adobe PDF document ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Improved adding images
Dirk: Do you still have any problems with adding images? If so, could you send me any examples? To be honest I'm still not sure how it should look like... Also there is no easy way of getting number of dives for which I have any photos selected. The checks logic is closed in the dive.c as Tomaz asked me at the beginning. Are you fine with the table solution? (sorry that I didn't respond for a while, busy time lately). 2015-03-16 8:55 GMT+01:00 Miika Turkia miika.tur...@gmail.com: On Mon, Mar 16, 2015 at 9:39 AM, Jan Darowski jan.darow...@gmail.com wrote: Ok, I can introduce changes you mentioned but i'm not sure how to handle multiple dives. Maybe I will introduce some kind of tables, one with filenames and timestamps and the second one with dives and their time range. Then highlight invalid photos... Or just assume that in most cases we only use one dive. I have always had multiple dives selected when importing. Maybe just show how many dives had matching images (and possibly the count how many were selected). From my point of view, you don't have to show everything, just examples of these (having the full count also displayed should make this obvious?) miika I did some testing already and for me shifting invalid image works... I'm using exiftool for testing images, if anyone else wants to play a little bit with it. 2015-03-16 6:55 GMT+01:00 Miika Turkia miika.tur...@gmail.com: On Mon, Mar 16, 2015 at 1:10 AM, Dirk Hohndel d...@hohndel.org wrote: On Sun, Mar 15, 2015 at 10:33:53PM +0100, Jan Darowski wrote: I've cleaned whitespaces, removed completely qstrdump (left one copy_string where it was needed), merged 2 later patches into one (3. was just changing message from 2.), changed author of the commits to match Signed-off-by. Nicely done. I'll take the patches as they are but would like you to work a bit more on this topic: a) when the user makes changes to the direction of shift, the information displayed should be updated b) don't show the full path, just show the file names c) also show the start and end time of the dive Some feedback would be nice to have even if everything is aligning correctly. E.g. dive times of the first time and the time stamp of one image that was shot during the dive. Also a count of how many of the loaded images are shot within accepted time frame versus all loaded images would be nice to have. Finally, I just tried this with a few pictures and couldn't get things to work. Now I haven't used this feature in ages and maybe I'm confused, but I have four pictures from a dive and the time offset for them is 7h and I'm certain that at one point in the past they were displayed correctly, but things don't work when I try it now... this could be user error, but I'd love it if some others would play with this as well to make sure nothing got broken. I was able to load images properly. However, my clocks were synced at the time, so it was easy to import. I did try some time adjustments as well and the pics were moved later on the dive, and if long enough shift, then the warning message appeared. For me, even if the times were shifted correctly it still showed the warning and if I ignored the warning no pictures were shown on the profile... I haven't debugged the issue any further as I figured that you had looked at this code just recently and maybe would be willing to continue working on it. The warning appeared and disappeared for me when I shifted the pics, but the case is different as the times were correct to begin with. miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Improved adding images
Ok, I can introduce changes you mentioned but i'm not sure how to handle multiple dives. Maybe I will introduce some kind of tables, one with filenames and timestamps and the second one with dives and their time range. Then highlight invalid photos... Or just assume that in most cases we only use one dive. I did some testing already and for me shifting invalid image works... I'm using exiftool for testing images, if anyone else wants to play a little bit with it. 2015-03-16 6:55 GMT+01:00 Miika Turkia miika.tur...@gmail.com: On Mon, Mar 16, 2015 at 1:10 AM, Dirk Hohndel d...@hohndel.org wrote: On Sun, Mar 15, 2015 at 10:33:53PM +0100, Jan Darowski wrote: I've cleaned whitespaces, removed completely qstrdump (left one copy_string where it was needed), merged 2 later patches into one (3. was just changing message from 2.), changed author of the commits to match Signed-off-by. Nicely done. I'll take the patches as they are but would like you to work a bit more on this topic: a) when the user makes changes to the direction of shift, the information displayed should be updated b) don't show the full path, just show the file names c) also show the start and end time of the dive Some feedback would be nice to have even if everything is aligning correctly. E.g. dive times of the first time and the time stamp of one image that was shot during the dive. Also a count of how many of the loaded images are shot within accepted time frame versus all loaded images would be nice to have. Finally, I just tried this with a few pictures and couldn't get things to work. Now I haven't used this feature in ages and maybe I'm confused, but I have four pictures from a dive and the time offset for them is 7h and I'm certain that at one point in the past they were displayed correctly, but things don't work when I try it now... this could be user error, but I'd love it if some others would play with this as well to make sure nothing got broken. I was able to load images properly. However, my clocks were synced at the time, so it was easy to import. I did try some time adjustments as well and the pics were moved later on the dive, and if long enough shift, then the warning message appeared. For me, even if the times were shifted correctly it still showed the warning and if I ignored the warning no pictures were shown on the profile... I haven't debugged the issue any further as I figured that you had looked at this code just recently and maybe would be willing to continue working on it. The warning appeared and disappeared for me when I shifted the pics, but the case is different as the times were correct to begin with. miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Improved adding images
I've cleaned whitespaces, removed completely qstrdump (left one
copy_string where it was needed), merged 2 later patches into one (3.
was just changing message from 2.), changed author of the commits to
match Signed-off-by.
2015-03-15 15:31 GMT+01:00 Dirk Hohndel d...@hohndel.org:
On Sun, Mar 15, 2015 at 11:01:06AM +0100, Jan Darowski wrote:
1) To be honest I'm not sure where it comes from, seems like
QtDesigner chenged it...
OK, that makes sense.
2) I think this qstrdup can and should be removed... I used qstrdup
instead of strdup (they work the same) because somewhere else qstrdup
was used.
In general we should use copy_string().
A quick grep shows that we have one single other use of qstrdup and
usually use our own copy_string (and occasionally use strdup). The
difference is that copy_string handles NULL pointers while strdup doesn't.
In this case you shouldn't have the risk of getting a NULL pointer back
but using copy_string might still be the most consistent choice.
From looking at the code in this particular instance the copy isn't needed
because the fileNames QStringList is in scope until the end of this
function. Since the called function only references the string but doesn't
keep the pointer that is passed in around there is no issue.
It's good that you pointed it out because most of these
qstrdup uses cause mem leaks right now.
Well, usually they are there because either the original string would go
out of scope or because we want to make sure that we can free the pointer
later. Subsurface does leak some memory here and there, but I don't think
most of the string copying is incorrect. There might be a few calls to
free missing here and there (even though we do our occasional attempts to
find and add those).
In the evening I will send corrected version of these patches, sorry
for the bugs.
Thanks. Just in case this wasn't obvious - your patches looked good. What
I did was mostly nitpick since this was your first submission to
Subsurface...
One more small comment - your From line (which turns into the Author)
and your Signed-of-by line don't agree with each other.
Eltharan johny@gmail.com / Jan Darowski jan.darow...@gmail.com
It would look better if you could be consistent. We have many contributors
who use several email addresses and I usually don't mind, but again, as
you set things up, this might be an easy thing to fix.
Thanks
/D
From a9bc13de8cea1110aba2208b8ce07347fc92bd6e Mon Sep 17 00:00:00 2001
From: Jan Darowski jan.darow...@gmail.com
Date: Sat, 14 Mar 2015 15:35:47 +0100
Subject: [PATCH 1/2] Refactored image timestamp checking.
Seperated getting image timestamp from picture_load_exif_data() and
ShiftImageTimesDialog::syncCameraClicked() into picture_get_timestamp()
and seperated checking timestamp from dive_create_picture() to
dive_check_picture_time().
Signed-off-by: Jan Darowski jan.darow...@gmail.com
---
dive.c | 44 +++-
dive.h | 5 -
qt-ui/simplewidgets.cpp | 14 --
qthelper.cpp| 19 +--
4 files changed, 60 insertions(+), 22 deletions(-)
diff --git a/dive.c b/dive.c
index 2fb0875..afa38e4 100644
--- a/dive.c
+++ b/dive.c
@@ -2884,22 +2884,47 @@ static bool new_picture_for_dive(struct dive *d, char *filename)
// only add pictures that have timestamps between 30 minutes before the dive and
// 30 minutes after the dive ends
#define D30MIN (30 * 60)
+bool dive_check_picture_time(struct dive *d, char *filename, int shift_time)
+{
+ timestamp_t timestamp = 0;
+ picture_get_timestamp(filename, timestamp);
+ offset_t offset;
+ if (timestamp) {
+ offset.seconds = timestamp - d-when + shift_time;
+ if (offset.seconds -D30MIN offset.seconds (int)d-duration.seconds + D30MIN) {
+ // this picture belongs to this dive
+ return true;
+ }
+ }
+ return false;
+}
+
+bool picture_check_valid(char *filename, int shift_time)
+{
+ bool result = false;
+ int i;
+ struct dive *d;
+
+ for_each_dive (i, d)
+ if (d-selected)
+ result = result || dive_check_picture_time(d, filename, shift_time);
+ return result;
+}
+
void dive_create_picture(struct dive *d, char *filename, int shift_time)
{
timestamp_t timestamp;
if (!new_picture_for_dive(d, filename))
return;
+ if (!dive_check_picture_time(d, filename, shift_time))
+ return;
+
struct picture *p = alloc_picture();
p-filename = filename;
- picture_load_exif_data(p, timestamp);
- if (timestamp) {
- p-offset.seconds = timestamp - d-when + shift_time;
- if (p-offset.seconds -D30MIN || p-offset.seconds (int)d-duration.seconds + D30MIN) {
- // this picture doesn't belong to this dive
- free(p);
- return;
- }
- }
+ picture_get_timestamp(filename, timestamp);
+ p-offset.seconds = timestamp - d-when + shift_time;
+ picture_load_exif_data(p);
+
dive_add_picture(d, p);
dive_set_geodata_from_picture(d, p);
}
@@ -2940,6 +2965,7 @@ static void
