Re: Dive planner problems

[Willem Ferguson via subsurface]

On 2022/02/08 00:17, Michael Andreen wrote:

The problem seems to be what JB2Cool mentioned in the previous thread. You
have the planner deco pO2 set to 0.60 instead of 1.60. The available gases
shows both Bot. MOD and Deco switch at. The Bot. MOD uses the Bottom pO2 and
18m for 50% and 4m for 100% seems fine. The deco switch at uses the Deco pO2
and in your case it shows nonsense -3m for oxygen. I've recreated your plan
with Deco pO2 set to 0.60 and 1.60 and the 0.60 matches your values.

/Michael


Problem solved. As indicated previously, my finger trouble. Have no idea 
how the preference was set to pO2=0.6


Thank you, Michael.

wf



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner problems

[Robert Helling via subsurface]

Willem,

> On 7. Feb 2022, at 20:22, Willem Ferguson  > wrote:
> 
> See attached image of a normoxic OC dive. The problem is that the MOD values 
> are not calculated correctly. Given that the dive preferences have been set 
> to a Max PO2 of 1.6 bar, the expected MOD for O2 is 6m and for EAN50 it 
> should be 22m. But it gives the MOD as 4m and 18m respectively. That is 
> erroneous. There appears to be no way to convince the planner otherwise.

the planner has it’s own settings for the maximal pO2, separate for the bottom 
time and the deco part of the dive. The MOD in the gas table is computed with 
the bottom pO2. In you screenshot I cannot see those values.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner problems

[Robert Helling via subsurface]

Hi Willem,

> On 7. Feb 2022, at 20:22, Willem Ferguson  
> wrote:
> 
> See attached image of a normoxic OC dive. The problem is that the MOD values 
> are not calculated correctly. Given that the dive preferences have been set 
> to a Max PO2 of 1.6 bar, the expected MOD for O2 is 6m and for EAN50 it 
> should be 22m. But it gives the MOD as 4m and 18m respectively. That is 
> erroneous. There appears to be no way to convince the planner otherwise.
> 
> Now the mystery is that I have downloaded Subsurface AppImages going back to 
> V4.9.3 and in all versions that I tested this behaviour is consistent. I use 
> the planner rather frequently and I did some planning before upgrading to 
> V5.0.6 and those plans were not problematic. I am not absolutely sure which 
> version I had before 5.0.6, but I am reasonably sure it was 5.0.5. I can only 
> assume that the planner accesses the preferences file and gets some 
> information there that is not used correctly. I am at a loss to explain this 
> behaviour, even in older versions. Consequently I have this nagging fear that 
> it is finger trouble on my side and I am making a fool of myself.

currently, I am somewhat busy. I will look at it, as soon as I have some time. 
I am sure, there is a simple explanation, this used to work.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner: SAC

[Robert Helling]

Hi,

> On 14. Apr 2019, at 15:38, Philippe Massart  wrote:
> 
> When doing the same with the latest master from Git (OS X), one line is 
> added, with a huge amount of liters! I tested the same from a fresh raspberry 
> (Raspbian) compilation from git, same « strange » new  line.
> 
> Perhaps that was already present for a while, I didn’t previously check the 
> planner while compiling from git. But no idea where it comes from.
> 
There should be a fix on 
https://github.com/Subsurface-divelog/subsurface/pull/2060

> Note also that CNS and OTU values are slightly different, that difference 
> increasing with deeper dives simulations (not just a rounding issue, I guess).
> 

These calculations we revamped in 1aef22116c0f0d4a6675225ab1b896715f3e9212 and 
fba6ec5ad500f0106a1590f061a583376dcbd23d. Should be more accurate now.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner: SAC

[Robert Helling]

> On 14. Apr 2019, at 18:45, Berthold Stoeger  
> wrote:
> 
> if I comment out the changes to planner.c introduced in 5e494ce761 (Show a bit
> of surface degassing in the planner), then the scary line goes away.

Yes, this sounds like I screwed up. Will look into this.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner: SAC

[Berthold Stoeger]

Hi Robert,

On Sonntag, 14. April 2019 15:38:28 CEST Philippe Massart wrote:

> Some strange behavior in the dive planner, between 4.8.6 (released version)
> and the latest master from git

if I comment out the changes to planner.c introduced in 5e494ce761 (Show a bit 
of surface degassing in the planner), then the scary line goes away.

This is code way over my head.

Berthold


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner: SAC

[Berthold Stoeger]

Hi Philippe,

On Sonntag, 14. April 2019 15:38:28 CEST Philippe Massart wrote:
> 
> When doing the same with the latest master from Git (OS X), one line is
> added, with a huge amount of liters! I tested the same from a fresh
> raspberry (Raspbian) compilation from git, same « strange » new  line.

Thanks for your report. This looks like the gases-array is not initialized 
correctly. Probably a fallout from the undo changes. I will try to find the 
cause later today.

Berthold


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Dean Murray]

excuse me, link here:
https://github.com/Subsurface-divelog/subsurface/issues/1998


On Tue, Mar 12, 2019 at 9:07 PM Dean Murray  wrote:

> Done, thanks.
>
> On Tue, Mar 12, 2019 at 6:38 PM Willem Ferguson <
> willemfergu...@zoology.up.ac.za> wrote:
>
>> On 2019/03/12 03:48, Dean Murray wrote:
>> > Hi all, thanks for checking. I also now tested in Ubuntu 18.04 / xfce
>> > and also find no problem there. Just in Windows. Shall i report this
>> > via github if no one here is in a position to take a look anytime
>> > soon? Is there any further detail I should provide?
>> >
>> > Dean
>>
>> Thank you for your time and effort. Please report the bug in Github?
>>
>> Kind regards,
>>
>> willem
>>
>>
>>
>> --
>> This message and attachments are subject to a disclaimer.
>>
>> Please refer to
>> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
>>  for
>> full
>> details.
>>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Dean Murray]

Done, thanks.

On Tue, Mar 12, 2019 at 6:38 PM Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> On 2019/03/12 03:48, Dean Murray wrote:
> > Hi all, thanks for checking. I also now tested in Ubuntu 18.04 / xfce
> > and also find no problem there. Just in Windows. Shall i report this
> > via github if no one here is in a position to take a look anytime
> > soon? Is there any further detail I should provide?
> >
> > Dean
>
> Thank you for your time and effort. Please report the bug in Github?
>
> Kind regards,
>
> willem
>
>
>
> --
> This message and attachments are subject to a disclaimer.
>
> Please refer to
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
>  for
> full
> details.
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Willem Ferguson]

On 2019/03/12 03:48, Dean Murray wrote:
Hi all, thanks for checking. I also now tested in Ubuntu 18.04 / xfce 
and also find no problem there. Just in Windows. Shall i report this 
via github if no one here is in a position to take a look anytime 
soon? Is there any further detail I should provide?


Dean


Thank you for your time and effort. Please report the bug in Github?

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Dean Murray]

Hi all, thanks for checking. I also now tested in Ubuntu 18.04 / xfce and
also find no problem there. Just in Windows. Shall i report this via github
if no one here is in a position to take a look anytime soon? Is there any
further detail I should provide?

Dean

On Tue, 5 Mar. 2019, 02:33 Willem Ferguson, 
wrote:

> On 2019/03/04 12:06, Dean Murray wrote:
>
> deanm-planner-bug-a.xml
>
> 1. open and then edit the single dive in the planner
> 2. note that the plan output includes the gas consumption details (all
> info below line "Gas consumption (based on SAC 20|17ℓ/min):")
> 3. note that calculations update and change if you adjust for example the
> runtime to 13min (ie all normal so far)
> 4. delete the 50% deco gas
> 5. note that the plan output no longer includes gas consumption details
> 6. if you save the dive plan the gas consumption info will be there in the
> notes of the dive plan entry.
> 7. if you reopen in the editor its still not visible there
> 8. edits to runtime etc that would normally trigger a recalculation do not
> fix it. the gas consumption does not reappear until you add the deco gas
> back in
> deanm-planner-bug-b.xml
>
> 1. as before, but note that the gas consumption is missing as soon as you
> open the dive in the planner.
> 2. change the depth from 45m to 50m and the gas consumption now shows up.
> 3. change back to 45m and it dissapears again
>
> hope this is helpful to debug it.
>
> Regards
>
> Dean Murray
>
>
> I have no abnormal behaviour at all using Linux (Ubuntu 18.04).
>
> Kind regards,
>
> willem
>
>
>
>
>
> This message and attachments are subject to a disclaimer.
> Please refer to
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full
> details.
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Willem Ferguson]

On 2019/03/04 12:06, Dean Murray wrote:

deanm-planner-bug-a.xml

1. open and then edit the single dive in the planner
2. note that the plan output includes the gas consumption details (all 
info below line "Gas consumption (based on SAC 20|17ℓ/min):")
3. note that calculations update and change if you adjust for example 
the runtime to 13min (ie all normal so far)

4. delete the 50% deco gas
5. note that the plan output no longer includes gas consumption details
6. if you save the dive plan the gas consumption info will be there in 
the notes of the dive plan entry.

7. if you reopen in the editor its still not visible there
8. edits to runtime etc that would normally trigger a recalculation do 
not fix it. the gas consumption does not reappear until you add the 
deco gas back in

deanm-planner-bug-b.xml

1. as before, but note that the gas consumption is missing as soon as 
you open the dive in the planner.

2. change the depth from 45m to 50m and the gas consumption now shows up.
3. change back to 45m and it dissapears again

hope this is helpful to debug it.

Regards

Dean Murray



I have no abnormal behaviour at all using Linux (Ubuntu 18.04).

Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: dive planner bug - gas consumption missing

[Robert Helling]

Dean,

> On 4. Mar 2019, at 11:06, Dean Murray  wrote:
> 
> hope this is helpful to debug it.
> 

thank you very much for you bug report. On my Mac, I cannot reproduce this but, 
works as expected. Could somebody else with Windows please look into this?

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Willem Ferguson]

Robert, Anton,

In my dive log I have many dives with OTU = zero where it should have 
some positive value. Do you have the same in your dive logs?


One needs to distinguish the otu which is calculated at the time a dive 
is saved for the first time (and which is shown in the Information tab), 
as opposed to any realtime calculations of otu that is performed within 
the planner in divelist.c.


Kind regards,

willem




--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Anton Lundin]

On 09 November, 2018 - Willem Ferguson wrote:

> Hi Robert, Anton,
> 
> Robert, apologies for ascribing the CNS calculations to you. Anton,
> any comments on the text below would be extremely valuable.
> 
> As you might have deduced, the CNS and OTU calculations can rapidly
> become pretty complex for dives with long-ish segments. To be
> absolutely accurate, one needs to divide each dive segment up into
> parts that fit into each 0.1 bar PPO2 interval. E.g., a segment that
> runs from 10m to 20m using EAN50 runs through five intervals of 0.1
> bar PPO2 (PPO2=1.0 at 10m to PPO2=1.5 at 20m). Then the CNS
> calculations for each of these five parts (1.0-1.1; 1.1-1.2; 
> 1.2-1.3;  1.3-1.4;  1.4-1.5)of the single segments needs to be added
> to get a CNS value that pertains only to the segment from 10m to
> 20m. Before you know what happens, Subsurface is likely to spend 80%
> of the computing needs just to calculate CNS. One cannot simplify
> CNS calculations by using mean PO2 during a segment: it is a sort-of
> exponential relationship, not linear.
> 
> This brings me to the topic of segment lengths in the planner. I
> know that planning segments are actually implemented as much shorter
> profile segments. The big question is what happens to an initial
> descending dive planner segment that goes from surface to 40m in two
> minutes. Using EAN32, PPO2 would run from 0.30 at surface to 1.5 at
> 40m, spanning some 12 PO2-classes of 0.1 in the lookup table, each
> with its own maximal O2 exposure duration and its own set of
> calculations.
> 
> What is the profile segment duration in the planner, as opposed to
> planner segments defined in the dive planner points table? I am
> trying to make an assessment of what level of additional complexity
> to expect in the planner. This is complicated by the fact that one
> needs to do different calculations in horizontal segments, as
> opposed to segments that ascend or descend. OTU calculations are
> affected in an exactly similar way. Any comments would be highly
> appreciated.

The cns calculator we currently got was never intended to be used in the
planner. Back when it was written, subsurface didn't have a planner.

The model it uses works just fine with a 1-3-10-30-60 second sample
interval from a divecomputer.

Btw. It works just fine for the diving I tend to do, IE, drop to rock
bottom, swim around and deco.


I'd suggest we "expand" the planner dive points into some sane sample
size, like 10s intervals before doing this sort of calculations.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Willem Ferguson]

Hi Robert, Anton,

Robert, apologies for ascribing the CNS calculations to you. Anton, any 
comments on the text below would be extremely valuable.


As you might have deduced, the CNS and OTU calculations can rapidly 
become pretty complex for dives with long-ish segments. To be absolutely 
accurate, one needs to divide each dive segment up into parts that fit 
into each 0.1 bar PPO2 interval. E.g., a segment that runs from 10m to 
20m using EAN50 runs through five intervals of 0.1 bar PPO2 (PPO2=1.0 at 
10m to PPO2=1.5 at 20m). Then the CNS calculations for each of these 
five parts (1.0-1.1; 1.1-1.2;  1.2-1.3;  1.3-1.4;  1.4-1.5)of the single 
segments needs to be added to get a CNS value that pertains only to the 
segment from 10m to 20m. Before you know what happens, Subsurface is 
likely to spend 80% of the computing needs just to calculate CNS. One 
cannot simplify CNS calculations by using mean PO2 during a segment: it 
is a sort-of exponential relationship, not linear.


This brings me to the topic of segment lengths in the planner. I know 
that planning segments are actually implemented as much shorter profile 
segments. The big question is what happens to an initial descending dive 
planner segment that goes from surface to 40m in two minutes. Using 
EAN32, PPO2 would run from 0.30 at surface to 1.5 at 40m, spanning some 
12 PO2-classes of 0.1 in the lookup table, each with its own maximal O2 
exposure duration and its own set of calculations.


What is the profile segment duration in the planner, as opposed to 
planner segments defined in the dive planner points table? I am trying 
to make an assessment of what level of additional complexity to expect 
in the planner. This is complicated by the fact that one needs to do 
different calculations in horizontal segments, as opposed to segments 
that ascend or descend. OTU calculations are affected in an exactly 
similar way. Any comments would be highly appreciated.


Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Willem Ferguson]

Hi Robert,

I have been doing some testing, as you have seen from emails on the mail 
list and have looked at the existing Subsurface code in divelist.c.


With respect to the calculation of CNS%, your and my calculations are 
identical EXCEPT that, for a specific PO2, you only use the next-lower 
tabulated maximum time and do not interpolate to provide for a PO2 value 
that is intermediate between two tabulated max-time values (line 214 in 
divelist.c). We use the same table originating from the NOAA Diving 
Manual and I think that is safe. Therefore the Subsurface CNS% values 
are slightly conservative.


With respect to the calculation of OTUs, you use an analogous but 
different formula from the one provided in the Baker document. At this 
stage I would not say that the formula in the existing code (line 165 in 
divelist.c) is better or worse than that of the Baker document (taking 
into account other bugs in the Baker document). But do you have any idea 
where the formula in divelist.c comes from? I would like to do more 
reading around the issue to come to a sensible conclusion about these 
differences.


Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Benjamin]

In the end everything is always implemented in C. Even if only for clarity,
brevity and simplicity :)

On Thu, Nov 8, 2018, 17:01 Willem Ferguson 
wrote:

> On 2018/11/08 08:37, Willem Ferguson wrote:
>
> On 2018/10/29 23:52, Robert Helling wrote:
>
> Hi,
>
> On 29. Oct 2018, at 22:31, Robert Helling  wrote:
>
> I can confirm the problem and here is a simplified version that also shows
> problem 1) (let’s deal with that first).
>
>
> it seems, this is a regression that was introduced sometime between 4.8.1
> and 4.8.2. Bisecting….
>
>
> Robert,
>
> On the Web I found a document with no provenance but written by Erik Baker
> and with a good approach towards calculating OTU & CNS.
>
> I will get back to you about OTU & CNS. My spreadsheet is so complex now I
> could have done everything in C.
>
> Kind regards,
>
> willem
>
>
>
>
> This message and attachments are subject to a disclaimer.
> Please refer to
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full
> details.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Willem Ferguson]

On 2018/11/08 08:37, Willem Ferguson wrote:

On 2018/10/29 23:52, Robert Helling wrote:

Hi,

On 29. Oct 2018, at 22:31, Robert Helling > wrote:


I can confirm the problem and here is a simplified version that also 
shows problem 1) (let’s deal with that first).


it seems, this is a regression that was introduced sometime between 
4.8.1 and 4.8.2. Bisecting….




Robert,

On the Web I found a document with no provenance but written by Erik 
Baker and with a good approach towards calculating OTU & CNS.


I will get back to you about OTU & CNS. My spreadsheet is so complex now 
I could have done everything in C.



Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner CNS calculations

[Willem Ferguson]

On 2018/10/29 23:52, Robert Helling wrote:

Hi,

On 29. Oct 2018, at 22:31, Robert Helling > wrote:


I can confirm the problem and here is a simplified version that also 
shows problem 1) (let’s deal with that first).


it seems, this is a regression that was introduced sometime between 
4.8.1 and 4.8.2. Bisecting….




Robert,

I am messing around with CNS and OTU calculations. I cannot find any 
original formulae for doing this. I have reverse-engineered the IANTD 
oxygen tables and derived formulas for CNS and OTU, but this is only a 
last-ditch alternative. Do you have any better information?


Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner

[Robert Helling]

Hi,

> On 29. Oct 2018, at 22:52, Robert Helling  wrote:
> 
> it seems, this is a regression that was introduced sometime between 4.8.1 and 
> 4.8.2. Bisecting….


I think I fixed this in 
https://github.com/Subsurface-divelog/subsurface/pull/1835 
 Please test.

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

Re: Dive Planner: Inconsistent dive ceiling calculations

[Willem Ferguson]

On 02/01/2018 15:34, Robert Helling wrote:

Willem,

reading your second mail, I understand there are only two different 
ceilings left: The one in the divelist which equals the one in the 
planner when you remove the ascent points and the second one you get 
in reedit until you remove the ascent waypoints.


This is a „feature“ of the VPM-B model: It treats the „decompression 
phase“ different from the bottom part of the dive, in particular it 
takes note of the ceiling at the beginning of the decompression. In 
the planner (as well as replan), we take all the explicitly listed 
waypoints as the definition of „bottom phase“ (so in replan before 
deleting the waypoints, the whole dive is „bottom phase“). In the 
divelist we make a clever guess (thanks to Rick’s code) as to where 
the bottom phase ends. This tends to be very close to the true bottom 
phase of planned dives (when the entered waypoints end at the deepest 
part of the dive and then the planner takes over and manages the 
ascent) but is not exactly the same.


I have recently blogged about this problem here

https://thetheoreticaldiver.org/wordpress/index.php/2017/12/22/vpm-b-for-real-dives-or-not/

Best
Robert


Hi Robert,

It's such a pleasure interacting with someone who really understands 
this thing, because I do not. I will document this issue in the user 
manual. It's really the way that the representation in Subsurface 
interacts with the VPM algorithm when a dive plan is reloaded for editing.


Would there be a possibility of a user defining the end of the bottom 
section of the dive and for automatically clearing the ascent dive 
points when a plan is reloaded from the dive list for editing? I 
understand how arbitrary the "start of ascent" can be, e.g. when doing 
multi-level diving.


V-planner handles this problem in a bit of a different way. One can 
define predetermined segments (e.g. a multilevel dive or a cave dive) 
that cannot be avoided in the ascent. However, between these segments, 
V-Planner still calculates a deco schedule. For instance if a multilevel 
dive has two depths, e.g. 40m for 20 min; then 20m for 20 min, V-Planner 
still gives deco stops between 40m and 20m, even though there is a 
pre-determined 20min "stop" at 20m. It would be wonderful if Subsurface 
has a way of dealing with this situation. You have no idea how powerful 
the Subsurface dive planner is for rapid graphical assessment of gas 
volumes used, planning for possible failure of a deco cylinder and many 
other things. The graphical representation makes an enormous difference.


Thank you so much for your time.

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.
Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive Planner: Inconsistent dive ceiling calculations

[Robert Helling]

Willem,

> On 2. Jan 2018, at 13:57, Willem Ferguson  
> wrote:
> 
> Attached four files: a dive plan and three profiles.
> 
> 1) Load dive plan into Subsurface. This gives dive1_list.png.
> 
> 2) Open the dive plan for edit in the planner. This gives dive1_2.png. A 
> totally different ceiling compared to previous representation.
> 
> 3) Delete all the dive points in the ascent phase of the dive plan. I used 
> the Dive Points Table to delete the points. This gives dive1_3.png. Yet 
> another ceiling totally different from previous representation.
> 
> We have three entirely different ceilings for the same dive plan.
> 
> I have no idea where the inconsistency arises.

reading your second mail, I understand there are only two different ceilings 
left: The one in the divelist which equals the one in the planner when you 
remove the ascent points and the second one you get in reedit until you remove 
the ascent waypoints.

This is a „feature“ of the VPM-B model: It treats the „decompression phase“ 
different from the bottom part of the dive, in particular it takes note of the 
ceiling at the beginning of the decompression. In the planner (as well as 
replan), we take all the explicitly listed waypoints as the definition of 
„bottom phase“ (so in replan before deleting the waypoints, the whole dive is 
„bottom phase“). In the divelist we make a clever guess (thanks to Rick’s code) 
as to where the bottom phase ends. This tends to be very close to the true 
bottom phase of planned dives (when the entered waypoints end at the deepest 
part of the dive and then the planner takes over and manages the ascent) but is 
not exactly the same.

I have recently blogged about this problem here

https://thetheoreticaldiver.org/wordpress/index.php/2017/12/22/vpm-b-for-real-dives-or-not/
 


Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner VPM-B problems

[Willem Ferguson]

On 17/10/2017 09:53, Stefan Fuchs wrote:


Hello Willem,

Am 17.10.2017 um 09:42 schrieb Willem Ferguson:

On 16/10/2017 21:56, Stefan Fuchs wrote:


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:

https://github.com/Subsurface-divelog/subsurface/pull/663

Best regards
Stefan

-

Stefan,

I have been trying out a lot of things around dive planning today this 
afternoon to test your patches within my dive context. I could not find 
any problem. Attached one of the dives I worked with. I loved it when 
changing the gas of the first segment of the dive, the cylinder table 
changed to put the gas first used at the top. I added segments at the 
bottom of the dive planner points table and these were placed at the 
start of the profile if the runtime was set appropriately. I really 
messed around, deleting cylinders, changing cylinders and adding 
cylinders and everything remained coherent and stable. I also see that 
all the cylinders used in the dive planner points table are marked as 
non-removable from the dive. Ok, Good.


About minimum pressures, you can see that the minimum pressure is given 
for the final bottom gas. As planned, there are 34 bars of bottom gas 
required to from the start of ascent complete the dive. If I double the 
deco SAC (SAC factor = 2) I would need 41 bars of back gas for the 
ascent. If I took one minute for problem solving I would need 
30(litres/min=2*deco SAC)*9(atm) = 360 litres of air = 11 bars of D12 
cylinders. That is 45 bars in total. But the problem solving would have 
been at the bottom depth (80m) before ascent, therefore the problem 
solving need is possibly better defined in terms of the bottom SAC, not 
the deco SAC (i.e. 15 bars and not 11 bars). But, I am very slowly 
getting to understand the argument.


Kind regards,
willem



--
This message and attachments are subject to a disclaimer.
Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner VPM-B problems

[Stefan Fuchs]

Hello Willem,

Am 17.10.2017 um 09:42 schrieb Willem Ferguson:
> On 16/10/2017 21:56, Stefan Fuchs wrote:
>>
>> 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:
>> https://github.com/Subsurface-divelog/subsurface/pull/663
>>
>> Best regards
>> Stefan
>>
>> -
> Thanks Stefan,
> Please give me a quick explanation on how the cylinder handling has
> changed? I am very dumb.
May I please ask you to read the PR description and even more important
the commit messages :-)

Based on the commit messages you will quickly see that there are a
couple of bugfixes or minor changes and mainly two real new features.
The new feature are:
- Used gas in dive planner points: Support for multiple cyl with same gas
- Planner: Autom. move first datapoint gas to first gaslist position

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner VPM-B problems

[Willem Ferguson]

On 16/10/2017 21:56, Stefan Fuchs wrote:


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:

https://github.com/Subsurface-divelog/subsurface/pull/663

Best regards
Stefan

-

Thanks Stefan,
Please give me a quick explanation on how the cylinder handling has 
changed? I am very dumb.

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.
Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner VPM-B problems

[Stefan Fuchs]

Hello Willem,

please find a few comments from my side on top of your two mails from
today about this topic.

Am 16.10.2017 um 15:31 schrieb Willem Ferguson:
> Attached two images of a mixed gas dive.
>
> 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:
>
> 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.
>
> 2) If I change the mix of the intermediate gas to 27/27, the violation
> disappears.
>
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.
What is interesting is that it seems that the waypoints generated by the
planner are correct. Minimum two reasons why I say this:
- Test did always pass.
- 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

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).
At the same moment I wouldn't see the situation too negative because as
I'm saying the planner results seem to be correct.

>
> Two suggestions, not at stake at all for V4.7 (see Plan2):
>
> 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.
>
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.

> 2) The minimum gas need is meaningless in this situation and I suggest
> that this calculation is only done for single cylinder dives.
>
Yes, you are right. This is what is also written in the documentation :-)
The minimum gas results are useless for some more complex cylinder
setups like your example where you have a travel gas for ascend.
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.
For example this - for me rather complex one - works and is also what I
need for myself:
Descend with 1st deco gas 50/15
Switch to 80cuft bottom stage 18/45 at ~15m
Dive until bottom stage empty at e.g. 60m
Switch to back gas 18/45 24l and continue at 60m
Then start ascend and do deco with 50/15 and Oxy
Minimum gas will be calculated perfectly for the last bottom datapoint
at 60m when you are breathing the 18/45 from the back gas.

Could you provide me examples (xml and setups) of dives where you think
todays minimum gas implementation is useless?
I would like to check if I can improve something or maybe even force the
calculation off for such setups.

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:
https://github.com/Subsurface-divelog/subsurface/pull/663

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner MG, TP and FC

[Ivan Wagner]

I think there are two main applications here:

1. for tracking data with the current planner which calculates
everything in detail for every dive sample.
2. for bottom timer users which want to have an idea of the plan thus
calculations are really easy by just adding parameters such as stops,
SAC rate, depth and so on.

These are two different approaches. One gets integrated in today's
subsurface planner, and the other one could be a easy to use custom
calculator (like a normal math calculator) and it would be easy to
implement.

What do you think?

Ivan
On 10/14/2015 04:34 PM, Willem Ferguson wrote:
> On 14/10/2015 16:28, Willem Ferguson wrote:
>> On 14/10/2015 16:05, Robert Helling wrote:
>>> Hi,
>>>
 On 14.10.2015, at 15:26, Willem Ferguson
  wrote:

 This is the gas pressure in the cylinder at the start of the ascent
 phase? This is a meaningful request but would require another selection
 to be made in the planner (gas turn rule). This is something that I use
 all the time in dive planning.
>>>
>>> what would that mean for the planner? Except for recreational mode,
>>> the planner always starts the ascent at the end of the manually
>>> entered waypoints.  Would you want to say something like “go to 80m
>>> and then figure out the pressure at which you have to leave 80m so
>>> you and your buddy make it to the surface with x bars remaining”?
>>>
>>> Best
>>> Robert
>>>
>>> -- 
>> Robert,
>>
>> Correct.
>>
>> Of course, actually, I commonly dive 230 bar and start the ascent at
>> around 90-95 bar, using thirds. So the 77 bars accurately constituting
>> a third is really a bare minimum and it is affected by deco
>> obligations.  But a message indicating "Ascent back gas pressure = 90
>> bar, i.e. within rule-of-thirds pressure (77 bar)" would be helpful.
>> It is an additional bit of safety information that checks the accuracy
>> of the deep section of the overall dive planning outside of
>> Subsurface. Does this make any sense?
> Of course you can see Ferguson' muddled mind here. In a strict thirds
> approach turning would be at around 140 bars in a cave. Reason for every
> bit of additional safety information from the planner. Fortunately I do
> not put my foot in a cave, otherwise I might consider turning at 90 bar!
> 
>> Kind regards,
>> willem
>>
>>
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> 
> 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner MG, TP and FC

[Henrik Brautaset Aronsen]

14. okt. 2015 16.45 skrev "Ivan Wagner" :
>
> In fact I use the Shearwater Petrel as a bottom timer... a :D so
much
> money for a bottom time.

Hehe, same here. Allthough the latest firmware added a stopwatch and
resettable average depth in OC Tec mode,  so now the Petrel is even usable
as a computer ;)

Henrik
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner MG, TP and FC

[Willem Ferguson]

On 14/10/2015 16:05, Robert Helling wrote:

Hi,

On 14.10.2015, at 15:26, Willem Ferguson 
> wrote:


This is the gas pressure in the cylinder at the start of the ascent
phase? This is a meaningful request but would require another selection
to be made in the planner (gas turn rule). This is something that I use
all the time in dive planning.


what would that mean for the planner? Except for recreational mode, 
the planner always starts the ascent at the end of the manually 
entered waypoints.  Would you want to say something like “go to 80m 
and then figure out the pressure at which you have to leave 80m so you 
and your buddy make it to the surface with x bars remaining”?


Best
Robert

--

Robert,

Correct.

Of course, actually, I commonly dive 230 bar and start the ascent at 
around 90-95 bar, using thirds. So the 77 bars accurately constituting a 
third is really a bare minimum and it is affected by deco obligations.  
But a message indicating "Ascent back gas pressure = 90 bar, i.e. within 
rule-of-thirds pressure (77 bar)" would be helpful. It is an additional 
bit of safety information that checks the accuracy of the deep section 
of the overall dive planning outside of Subsurface. Does this make any 
sense?

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner MG, TP and FC

[Willem Ferguson]

Robert,

Can a make a second attempt to make more sense? But this is, I am sure, 
boring to you.


The group that I do deep dives with use a thirds approach: whether you 
dive caves or open water and nothing goes wrong, diver needs a third of 
the back gas remaining at the end of the dive. So, given SAC rate(s) it 
is simple (but sometimes tedious) to calculate the cylinder pressure at 
which ascent starts. But ascent pressure is not merely a third, diver 
and buddy must be able to get to 1st cylinder change depth, so this 
amount is added to the cylinder pressure value of a third. This often 
gives ascent start pressures between 80 and 100 bar. It would be useful 
if this pressure at start of ascent were calculated by Subsurface. The 
reason why this number is useful is of course when one underestimates 
SAC for that particular dive and the bottom time should be shortened 
because of remaining back gas requirement. This number goes on my slate 
every dive, therefore the usefulness. Do I make sense at all this time 
round? Good communication is difficult.

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Fwd: Re: Dive planner MG, TP and FC

[Willem Ferguson]

Ivan, Robert,

I think I understand the request.

On 14/10/2015 14:21, Ivan Wagner wrote:

Dear list,

I was taking a look at the dive planner feature within subsurface and I
see some useful features that could be added:

- Minimum gas (based on a scenario of an out-of-gas event and and ascent
respecting ascent rates, deep stops etc)


The planning takes into account all gas available and subtracts the
amounts required for gas sharing as well as a 'residual' amount that
needs to remain. If one requires 50 bar for buddy-sharing (calculated by
the planner automatically) and another 30 bar residual was requested on
the dive planner form, the minimum gas use at the end of the dive is
start-pressure minus 80 bar. So the concept of minimum gas required is
not really relevant here, at least for recreational dives.


- Turn pressure based on gas rule such as all usable, half usable or
rule of thirds


This is the gas pressure in the cylinder at the start of the ascent
phase? This is a meaningful request but would require another selection
to be made in the planner (gas turn rule). This is something that I use
all the time in dive planning.


- Fractional consumption at depth with 5 minutes interval.


There is a continuous trace of the gas pressure throughout the dive and
the precise pressure can actually be read from the profile information
box (the moving black box on the profile panel). Would fractional gas
information really give one more useful insight?


This is something I use on a daily basis not only for technical dives
but also recreational dives.

Could this be interesting for you? I could implement something.

Let me know,

ivan



Kind regards,
willem



___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner oddities

[Rick Walsh]

On 12 October 2015 at 18:21, Sergey Starosek 
wrote:

> Robert, Rick,
>
> On Sun, Oct 11, 2015 at 10:44 PM, Rick Walsh  wrote:
>
>> The cylinder pressure graph should start to flatten when starting
>> ascent.  Assuming a constant SAC, gas consumption varies with depth.  Is
>> that what you're referring to?
>>
> See another image attached (rec model, 1 min descent to 30 min, 17 min at
> 30 m, SAC set to 17/15 l/min). See the pressure graph spike (in red circle).
>
> Sergey
>

Yes, now I see what you mean.  I can reproduce it if the bottom time
exceeds the NDL in recreational mode.  I'm not sure about the cause.

Cheers,

Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner oddities

[Sergey Starosek]

Robert, Rick,

On Sun, Oct 11, 2015 at 10:44 PM, Rick Walsh  wrote:

> The cylinder pressure graph should start to flatten when starting ascent.
> Assuming a constant SAC, gas consumption varies with depth.  Is that what
> you're referring to?
>
See another image attached (rec model, 1 min descent to 30 min, 17 min at
30 m, SAC set to 17/15 l/min). See the pressure graph spike (in red circle).

Sergey
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] Re: Dive planner oddities

[Robert C. Helling]

Hi,On 12 Oct 2015, at 09:21, Sergey Starosek  wrote:Robert, Rick,On Sun, Oct 11, 2015 at 10:44 PM, Rick Walsh  wrote:The cylinder pressure graph should start to flatten when starting ascent.  Assuming a constant SAC, gas consumption varies with depth.  Is that what you're referring to?See another image attached (rec model, 1 min descent to 30 min, 17 min at 30 m, SAC set to 17/15 l/min). See the pressure graph spike (in red circle).Sergey
this patch should correct this oddity.BestRobertFrom b77526a748a026c9ef3accee5a70fc29b7c8af0b Mon Sep 17 00:00:00 2001
From: "Robert C. Helling" 
Date: Mon, 12 Oct 2015 22:03:50 +0200
Subject: [PATCH] Don't do a negative time step in recreational mode when
 beyond NDL

In recreational mode, we keep adding time at the last depth
until an ascent does violate the ceiling. Then we roll back
the last added time step and record the ascent. The test for
the ceiling violated was before adding the time so if it alreay
failed the first time we tried to unroll a time step that was
never added which resulted in a small kink in the pressure graph.

This patch corrects this logic by changin a while to a do {} while.

Furthermore, it removes the computation of deco state during the
final ascent since that is not used anywhere later.

Signed-off-by: Robert C. Helling 
---
 planner.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/planner.c b/planner.c
index 05fd26e..22d3716 100644
--- a/planner.c
+++ b/planner.c
@@ -1070,15 +1070,21 @@ bool plan(struct diveplan *diveplan, char 
**cached_datap, bool is_planner, bool
bool safety_stop = prefs.safetystop && max_depth >= 1;
track_ascent_gas(depth, 
_dive.cylinder[current_cylinder], avg_depth, bottom_time, 
safety_stop);
// How long can we stay at the current depth and still directly 
ascent to the surface?
-   while (trial_ascent(depth, 0, avg_depth, bottom_time, 
_dive.cylinder[current_cylinder].gasmix,
- po2, diveplan->surface_pressure / 1000.0) &&
-  enough_gas(current_cylinder)) {
+   do {
add_segment(depth_to_bar(depth, _dive),
-  
_dive.cylinder[current_cylinder].gasmix,
-  DECOTIMESTEP, po2, 
_dive, prefs.bottomsac);
+   
_dive.cylinder[current_cylinder].gasmix,
+   DECOTIMESTEP, po2, _dive, 
prefs.bottomsac);
update_cylinder_pressure(_dive, depth, depth, 
DECOTIMESTEP, prefs.bottomsac, _dive.cylinder[current_cylinder], 
false);
clock += DECOTIMESTEP;
-   }
+   } while (trial_ascent(depth, 0, avg_depth, bottom_time, 
_dive.cylinder[current_cylinder].gasmix,
+ po2, diveplan->surface_pressure / 1000.0) 
&&
+enough_gas(current_cylinder));
+
+   // We did stay one DECOTIMESTEP too many.
+   // In the best of all worlds, we would roll back also the last 
add_segment in terms of caching deco state, but
+   // let's ignore that since for the eventual ascent in 
recreational mode, nobody looks at the ceiling anymore,
+   // so we don't really have to compute the deco state.
+   update_cylinder_pressure(_dive, depth, depth, 
-DECOTIMESTEP, prefs.bottomsac, _dive.cylinder[current_cylinder], 
false);
clock -= DECOTIMESTEP;
plan_add_segment(diveplan, clock - previous_point_time, depth, 
gas, po2, true);
previous_point_time = clock;
@@ -1093,9 +1099,6 @@ bool plan(struct diveplan *diveplan, char **cached_datap, 
bool is_planner, bool
if (depth - deltad < 0)
deltad = depth;
 
-   add_segment(depth_to_bar(depth, _dive),
-   
_dive.cylinder[current_cylinder].gasmix,
-   TIMESTEP, po2, _dive, 
prefs.decosac);
clock += TIMESTEP;
depth -= deltad;
if (depth <= 5000 && depth >= (5000 - deltad) && 
safety_stop) {
-- 
1.9.5 (Apple Git-50.3)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner oddities

[Robert C. Helling]

Sergey,

thanks for testing this. Unfortunately I think I need some more explanation of 
your findigs.

> On 11 Oct 2015, at 20:06, Sergey Starosek  wrote:
> 
> Some planner testing results:
> Reset preferences, no default divelog
> Start planner (Buehlmann model)
> Switch to recreational model
> Note that 2nd waypoint is not aligned with graph
What exactly do you mean by „not aligned“? Do you refer to the fact that the 
handle is not at the end of the 15m segment? That is on purpose, this is what 
„recreational mode“ is about: The second handle is the last manually entered 
waypoint and in recreational mode the planner stays at that depth for the 
maximum time that does not get you in conflict with gas usage and deco 
obligations.


> Change depth for the 1st and 2nd waypoint to be 30m
> Note a peak on a SAC graph
Maybe I am stupid but I cannot see it on your screen shots. Actually, I don’t 
see the pO2 graph at all. When I run subsurface, I can see the graph but no 
peak. Could you indicate on the screen shot where I am supposed to look?

> Cancel plan, close and restart ssrf
> Open planner
> Note that 2nd waypoint is not aligned with graph

As above.

Best
Robert



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner oddities

[Rick Walsh]

Hi Sergey,

Thanks for testing the planner.  The more people that try it and the more
feedback the better.

On 12 Oct 2015 6:35 am, "Sergey Starosek"  wrote:
>
> HI Robert,
>
> Away from keyboard, answering from mobile.
>
> On Oct 11, 2015 22:18, "Robert C. Helling"  wrote:
> >
> > Sergey,
> >
> > thanks for testing this. Unfortunately I think I need some more
explanation of your findigs.
> >
> > What exactly do you mean by „not aligned“? Do you refer to the fact
that the handle is not at the end of the 15m segment? That is on purpose,
this is what „recreational mode“ is about: The second handle is the last
manually entered waypoint and in recreational mode the planner stays at
that depth for the maximum time that does not get you in conflict with gas
usage and deco obligations.
>
> Thanks for the explanation,  user manual needs to clarify on this,  I
think. Will do more testing on this tomorrow.
>

Maybe we should also add a tooltip on recreational mode saying something
like, "maximize bottom time without deco".

> >> Note a peak on a SAC graph
> >
> > Maybe I am stupid but I cannot see it on your screen shots. Actually, I
don’t see the pO2 graph at all. When I run subsurface, I can see the graph
but no peak. Could you indicate on the screen shot where I am supposed to
look?
>
> I was talking about  cylinder pressure graph (SAC is irrelevant here,
just color of the line). Look for the spike just around ascent beginning.
>

The cylinder pressure graph should start to flatten when starting ascent.
Assuming a constant SAC, gas consumption varies with depth.  Is that what
you're referring to?

Cheers,

Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Dive planner oddities

[Sergey Starosek]

HI Robert,

Away from keyboard, answering from mobile.

On Oct 11, 2015 22:18, "Robert C. Helling"  wrote:
>
> Sergey,
>
> thanks for testing this. Unfortunately I think I need some more
explanation of your findigs.
>
> What exactly do you mean by „not aligned“? Do you refer to the fact that
the handle is not at the end of the 15m segment? That is on purpose, this
is what „recreational mode“ is about: The second handle is the last
manually entered waypoint and in recreational mode the planner stays at
that depth for the maximum time that does not get you in conflict with gas
usage and deco obligations.

Thanks for the explanation,  user manual needs to clarify on this,  I
think. Will do more testing on this tomorrow.

>> Note a peak on a SAC graph
>
> Maybe I am stupid but I cannot see it on your screen shots. Actually, I
don’t see the pO2 graph at all. When I run subsurface, I can see the graph
but no peak. Could you indicate on the screen shot where I am supposed to
look?

I was talking about  cylinder pressure graph (SAC is irrelevant here, just
color of the line). Look for the spike just around ascent beginning.

Sergey
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface