<div dir="ltr">Robert,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 1 September 2015 at 08:02, Robert C. Helling <span dir="ltr"><<a href="mailto:helling@atdotde.de" target="_blank">helling@atdotde.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
here are five patches cleaning up the code mainly in the planner. Mainly, they redo the ceiling calculation. For VPM-B, this iterates the ceiling and the Boyle compensation until the reference pressure is computed at the ceiling.<br>
<br></blockquote><div>I like what you've done. At first I was hesitant about an (other) iterative calculation, but what you have done is neat. The change is clever, and I agree cleaner.<br><br>I see perhaps the greatest improvement is that it should make
calculating a decent VPM-B ceiling for a real dive one step closer.<br><div><br>I
had go at that (prior to your patch set). Calculating a good
first_ceiling_pressure for a real dive is actually quite simple (take
the deepest ceiling works). Boyle's compensation is improved now. The
one thing I couldn't think of a nice way of doing was the CVA calc. I
can't think of a better way than working through the samples until we
can calculate first_ceiling_pressure, then iterate until a calculated
plan converges, before continuing with the ceiling for the rest of the
dive.<br></div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This results in slightly different runtimes in the test dives (typically a minute compared to what we did previously). The last patch updates the test but compared to the FORTRAN code, we now fail two tests. So this is up to discussion.<br>
<br></blockquote><div>It looks like Subsurface is now more "accurate" and consistent than the Fortran code, which is nice. But it also looks like Subsurface is marginally more aggressive in most cases, which is not so good. The Fortran code, and it's more modern but seemingly barely changed derivations, is and for the near future will probably stay the standard reference, and arguably the "model" incorporates this when used for real dives. If you spend an extra minute or two at 6 m, your body won't care what model you used to plan your dive.<br><br>Assuming there's no mistake that needs fixing in our implementation, we could either live with the difference, or we could introduce a slight conservatism to our nominal case. The following is a very basic patch that makes us pass all the tests again. I'm not proposing it yes, at least not until we've worked out there isn't some other tweak that we ought to do. But it does work.<br><br>
<div>
<span style="font-family:monospace"><span style="font-weight:bold;color:rgb(0,0,0);background-color:rgb(255,255,255)">diff --git a/deco.c b/deco.c</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="font-weight:bold;color:rgb(0,0,0);background-color:rgb(255,255,255)">index 8618a7c..e21eed3 100644</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="font-weight:bold;color:rgb(0,0,0);background-color:rgb(255,255,255)">--- a/deco.c</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="font-weight:bold;color:rgb(0,0,0);background-color:rgb(255,255,255)">+++ b/deco.c</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="color:rgb(24,178,178);background-color:rgb(255,255,255)">@@ -167,17 +167,19 @@</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"> double bottom_he_gradient[16];
</span><br> double initial_n2_gradient[16];
<br> double initial_he_gradient[16];
<br> <br><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">+// Subsurface appears to produce marginally less conservative plans than our benchmarks</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">+// Introduce 1% additional conservatism</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br> double get_crit_radius_He()
<br> {
<br> if (prefs.conservatism_level <= 4)
<br><span style="color:rgb(178,24,24);background-color:rgb(255,255,255)">- return vpmb_config.crit_radius_He * conservatism_lvls[prefs.conservatism_level];</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">+</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"> </span><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">return vpmb_config.crit_radius_He * conservatism_lvls[prefs.conservatism_level] * 1.01;</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br> return vpmb_config.crit_radius_He;
<br> }
<br> <br> double get_crit_radius_N2()
<br> {
<br> if (prefs.conservatism_level <= 4)
<br><span style="color:rgb(178,24,24);background-color:rgb(255,255,255)">- return vpmb_config.crit_radius_N2 * conservatism_lvls[prefs.conservatism_level];</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">+</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"> </span><span style="color:rgb(24,178,24);background-color:rgb(255,255,255)">return vpmb_config.crit_radius_N2 * conservatism_lvls[prefs.conservatism_level] * 1.01;</span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">
</span><br> return vpmb_config.crit_radius_N2;
<br> }<br></span></div>
<br><br><br></div><div>Cheers,<br><br></div><div>Rick<br></div></div></div></div></div>