Quirks of the Subsurface dive planner

[Willem Ferguson]

Robert,

Thank you very much for your feedback on this issue and for the 
associated patches you submitted. Apologies for a long reply. During the 
last week I have been using the planner quite intensively. The reason is 
mainly twofold: the graphical interface that allows a visual 
confirmation that the dive plan is set up as intended, including partial 
gas pressures; 2) the facility to check expected gas pressures at 
critical points along the planned profile: this is of enormous value for 
gas management during the dive. Below are a few comments on the 
behaviour of the planner that I think need attention.

The types of dives that we planned involved the use of a travel gas in 
trimix dives of a cave system. therefore a large part of the profile 
after the deepest point of the dive are specified in the dive points 
table (therefore differing from an open-water dive where the planner 
deals with the total ascent from the end of the bottom section of the 
dive to the surface). The strategy was to initiate the dive with nitrox, 
switch to trimix as a main back gas for the deeper part of the dive, 
then switch back to nitrox upon getting back to shallower levels and 
with final deco using oxygen. In short, there are two problems: 1) The 
order in which the gases are entered in the cylinder table has an effect 
on the rendering of the data; 2) when saving a plan and re-opening and 
editing it in the dive planner, the gas changes are forgotten. Below are 
some images of a stereotyped dive plan using the above approach.

Case 1: Here the order in which the cylinders were defined are: nitrox, 
trimix, oxygen. Image Case1a indicates a plan after saving it and 
viewing it from the dive list. Looks ok, no problems. Image Case1b shows 
the same dive after opening it again for editing in the dive planner. 
The second gas change has been forgotten, requiring extensive editing of 
the Dive Points table.

Case 2: Here the order in which the cylinders were defined are: trimix, 
nitrox, oxygen. Many divers would reason to use this order because the 
trimix is the main back gas, the other cylinders being ancillary. Here 
there are problems arising from the fact that the first cylinder defined 
was trimix, but the dive started with nitrox. The points to be seen in 
image Case2a is that

(i) the cylinder pressure graphs for nitrox are not shown on the 
planning screen. The gas pressure calculations are, however done, 
evident from the final gas pressure for nitrox actually being shown.

(ii) Also, notice on the left margin of the profile (near the 20m depth 
tick mark) that there are two cylinder labels: trimix as well as nitrox. 
I assume what happens is that, since the trimix cylinder was the first 
one defined in the cylinder table, the planner assumes that the dive 
begins with trimix. Then, when in the dive points table, the first 
segment is in nitrox, the planner inserts a gas change event from trimix 
to nitrox right at the start of the dive. It would be wonderful if the 
profile could automatically start off with the first gas defined in the 
dive points table and not with the first cylinder defined in the 
cylinder definition table. I realise that this issue is probably 
difficult to deal with because of the integration between the planner 
profile display and the "normal" dive log display where the cylinder 
definition table is filled in the order in which the dive computer 
provides the cylinder gas data after the dive. But the usability of the 
planner interface would really be much more user-friendly if the profile 
display is not dependent on the order of the cylinder definitions.

Image Case2b shows the profile after being saved, and viewed from the 
dive list. Pretty much as it looked on the dive planning screen. Still 
no gas pressure graphs for nitrox.

Image Case2c shows the same dive plan after re-opening it for editing in 
the planner. In this case, both gas changes involving trimix has been 
forgotten, again requiring extensive re-editing of the dive points table.

There are some smaller issues that relate to the ease of use of the planner:

i) If I change the gas in the dive points table, it would be very useful 
if all segments below the one being edited were also changed to the same 
gas. For instance, if I change the gas in the 3rd row of the table to 
EAN40, it would be helpful if all the rows underneath were also changed 
to EAN40. This way I do not have to change by hand each of the 
subsequent segments to EAN40. I realise that, if final deco is done with 
oxygen, these will also be overwritten with EAN40, but that would 
require only one re-edit of a row lower down in the dive points table, 
changing the gas to oxygen: then all the rows underneath would also be 
changed to oxygen. I think the fundamental reason for such a request is 
that the dive points table for these sorts of dive plans includes quite 
a long list of explicitly-defines dive points.

ii) It would be invaluable if it were possible to insert a row in the 
dive points table. Let's say I planned a dive, and in one of the dive 
segments I want to add another depth level during the descent (or 
ascent). Currently I can do that by double-clicking the profile and 
creating a new dive point. But a) this operation does not always have a 
predictable effect and b) now I am dependent on interaction with the 
dive profile panel for doing changes to the dive points table. Our 
approach in the past (I think) has always been that editing the dive 
points table is the better way to put together the segments for display 
in the profile panel.

iii) When re-opening a dive plan for editing in the planner, the final 
part of the dive plan (determined by the planner) is hard-coded into 
explicit dive points represented in the dive points table. This has some 
very nasty consequences. For instance, if I reposition a gas change 
along the profile using the profile panel, gas changes later on in the 
plan are often screwed. In many cases, the change to oxygen is moved to 
the very last segment of the dive plan: clearly erroneous. This means I 
have to delete all the dive points from the end back towards the point 
where I exit the cave into open water and let the planner recalculate 
the final deco again.

iv) When re-opening a dive plan for re-editing the plan in the planner, 
a zero-time dive point is still inserted as the very first dive point.

Please do not take these remarks as criticism of any sort. One could 
argue that the way that I use the planner here is a corner case. My 
motivation for adding improvements to the planner is twofold: 1) I place 
very large value on the Subsurface planner because it has unique 
advantages; 2) robustness of the planner is an important part of making 
this software a prime choice for other divers.

Kind regards,

willem



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case2c.jpg
Type: image/jpeg
Size: 60955 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170130/6771f359/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case2b.jpg
Type: image/jpeg
Size: 54026 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170130/6771f359/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case2a.jpg
Type: image/jpeg
Size: 61549 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170130/6771f359/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case1b.jpg
Type: image/jpeg
Size: 65606 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170130/6771f359/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case1a.jpg
Type: image/jpeg
Size: 57264 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170130/6771f359/attachment-0009.jpg>