<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Willem,</p>
    <p>please find a few comments from my side on top of your two mails
      from today about this topic.<br>
    </p>
    Am 16.10.2017 um 15:31 schrieb Willem Ferguson:<br>
    <blockquote type="cite"
      cite="mid:573d0707-f4f6-8b98-19a7-621ef4d7fa3d@zoology.up.ac.za">Attached
      two images of a mixed gas dive.
      <br>
      <br>
      Plan1 is a first step of a multigas dive plan and the planner
      places some points above the ceiling. There are three issues to
      note:
      <br>
      <br>
      1) The planner places the last number of points during which the
      violation occurs. If I change the conservatism to either 2 or to
      4, then the violation disappears.
      <br>
      <br>
      2) If I change the mix of the intermediate gas to 27/27, the
      violation disappears.
      <br>
      <br>
    </blockquote>
    The feeling I had all the time during the last weeks is that the
    deco ceiling calculation for the ceiling displayed in the profile
    (inside and outside the planner) still has some bugs.<br>
    What is interesting is that it seems that the waypoints generated by
    the planner are correct. Minimum two reasons why I say this:<br>
    - Test did always pass.<br>
    - Your example from your second mail comparing current master with
    4.6.3.xx and also my tests show that planner generated waypoints
    didn't change<br>
    <br>
    So for the moment I guess you and me provided more than enough
    examples for Rick and Robert and the only thing we can do now is
    hope that they find some time to search for the bug(s).<br>
    At the same moment I wouldn't see the situation too negative because
    as I'm saying the planner results seem to be correct.<br>
    <br>
    <blockquote type="cite"
      cite="mid:573d0707-f4f6-8b98-19a7-621ef4d7fa3d@zoology.up.ac.za">
      <br>
      Two suggestions, not at stake at all for V4.7 (see Plan2):
      <br>
      <br>
      1) I would like to insert a top row in the dive points table to
      accommodate a travel gas (27/27 in this case) and at this stage I
      cannot. It would be really helpful if there was a way to do this.
      As it is at present, I would have to delete the whole dive points
      table and start from scratch.
      <br>
      <br>
    </blockquote>
    Isn't this already possible? Insert a new waypoint at the end and
    then set the value for runtime to a value lower than runtime of your
    first table row. This will move the table line to the first
    position. And then you can enter your travel gas.<br>
    <br>
    <blockquote type="cite"
      cite="mid:573d0707-f4f6-8b98-19a7-621ef4d7fa3d@zoology.up.ac.za">2)
      The minimum gas need is meaningless in this situation and I
      suggest that this calculation is only done for single cylinder
      dives.
      <br>
      <br>
    </blockquote>
    Yes, you are right. This is what is also written in the
    documentation :-)<br>
    The minimum gas results are useless for some more complex cylinder
    setups like your example where you have a travel gas for ascend.<br>
    But limiting the minimum gas calculation for single cylinder dives
    is not the correct approach. There are many multi cylinder setups
    where todays minimum gas calculation works perfectly.<br>
    For example this - for me rather complex one - works and is also
    what I need for myself:<br>
    Descend with 1st deco gas 50/15<br>
    Switch to 80cuft bottom stage 18/45 at ~15m<br>
    Dive until bottom stage empty at e.g. 60m<br>
    Switch to back gas 18/45 24l and continue at 60m<br>
    Then start ascend and do deco with 50/15 and Oxy<br>
    Minimum gas will be calculated perfectly for the last bottom
    datapoint at 60m when you are breathing the 18/45 from the back gas.<br>
    <br>
    Could you provide me examples (xml and setups) of dives where you
    think todays minimum gas implementation is useless?<br>
    I would like to check if I can improve something or maybe even force
    the calculation off for such setups.<br>
    <br>
    BTW: You could be one of the best candidates for testing my latest
    changes around cylinder handling in the planner. It would be great
    to hear from your side if this improves or breaks s.th. for you.
    Robert merged the changes already but the PR was this one:<br>
    <a class="moz-txt-link-freetext" href="https://github.com/Subsurface-divelog/subsurface/pull/663">https://github.com/Subsurface-divelog/subsurface/pull/663</a><br>
    <br>
    Best regards<br>
    Stefan<br>
    <br>
    <div class="moz-signature">-- <br>
      <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
      <title></title>
      <meta name="GENERATOR" content="OpenOffice.org 3.3 (Win32)">
      <meta name="CREATED" content="0;0">
      <meta name="CHANGEDBY" content="Stefan Fuchs">
      <meta name="CHANGED" content="20120503;23115492">
      <style type="text/css">
        <!--
                P { color: #000000 }
        -->
        </style>
      <p>Stefan Fuchs<br>
        E-Mail: <a href="mailto:sfuchs@gmx.de">sfuchs@gmx.de</a></p>
    </div>
  </body>
</html>