Test VPM-B

Rick Walsh rickmwalsh at gmail.com
Wed Aug 26 15:39:37 PDT 2015


Hi Robert,

On 24 August 2015 at 00:12, Robert C. Helling <helling at atdotde.de> wrote:

>
> as requested by Dirk, here is a test that tests the behaviour of VPM-B
> dive planning. The actual test is patch 5, the previous ones were created
> in the process of making the test pass (i.e. get the same dive plan as the
> full program). The test is supposed to pass after Rick’s
> first_stop_pressure patch is applied.
>
> This is a result of a multi-hour debugger session. Puh!
>
>
The infrastructure you've set up to make the tests possible is great and
very useful for evaluating changes to the code.  But the fourth patch in
the series, Prepare global state of VPM-B when starting to plan (commit
41349c29ddc45e7c19fc287f10fa8f6712bcf111 in master), changed the
calculations in what I believe is an unintended manner.

diff --git a/planner.c b/planner.c
index aca5a05..6011dd9 100644
--- a/planner.c
+++ b/planner.c
@@ -996,6 +996,13 @@ bool plan(struct diveplan *diveplan, char
**cached_datap, bool is_planner, bool
 		create_dive_from_plan(diveplan, is_planner);
 		return(false);
 	}
+	calc_crushing_pressure(depth_to_mbar(depth, &displayed_dive) / 1000.0);
+	nuclear_regeneration(clock);
+	clear_deco(displayed_dive.surface_pressure.mbar / 1000.0);
+	vpmb_start_gradient();

^^^This last line changes the calculated plan but I don't know why.  I have
attached the results of the test run twice: firstly with the current master
(80e7213582c203a128270a0e2e8fcc850eede063), the second with the line
vpmb_start gradient() removed.  Removing it improves the test results
(passes 8/10 compared to 6/10, and one of the two failing is failing by 3
seconds using the within-1%+1min-of-vpmb-comparison-result-is-good-enough
logic).  The results are replicated when the plan is calculated by running
Subsurface properly.

My problem is that I can't work out why this line should have any effect at
all.  Otherwise I would have sent a patch.  Do you understand what it's
changing?

Note also that the nuclear_regeneration line is obsolete - it updates
n2_regen_radius and he_regen_radius, which are then reset by the clear_deco
function.

Cheers,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150827/fd401a18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testplan-20150827-master
Type: application/octet-stream
Size: 18101 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150827/fd401a18/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testplan-20150827-minus-start-grad
Type: application/octet-stream
Size: 17639 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150827/fd401a18/attachment-0003.obj>


More information about the subsurface mailing list