Dive planner

[Robert Helling]

Willem,

[I added the mailing list as somebody else might have an idea what is going on]

Would you be prepared, at all, to have a look at this mock-up dive plan? Two issues.
1) More important, there is a ceiling crossing at 33 minutes, yielding a warning and a red depth profile. I often get this problem while using the planner.
2) The first trimix switch (11/60 -> 31/30) does not yield a gas change icon with an exclamation mark.
The isobaric error occurs just after the ceiling crossing. These problems related?
As usual, finger trouble on my side?

I can confirm the problem and here is a simplified version that also shows problem 1) (let’s deal with that first). Don’t worry if the gases are sensible, I just tried no eliminate noise.



My suspicion is that somehow it get’s confused by the gases and the manual gas changes. Let me investigate this


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: [phone] Theresienstr. 39, rm. B339
stupid .sig\n"; http://www.atdotde.de <http://www.atdotde.de/>

[Robert Helling]

Hi,

Post by Robert Helling
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
--
.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: [phone] Theresienstr. 39, rm. B339
stupid .sig\n"; http://www.atdotde.de

[Robert Helling]

Hi,

Post by Robert Helling
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 <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: [phone] Theresienstr. 39, rm. B339
stupid .sig\n"; http://www.atdotde.de

[Willem Ferguson]

Post by Robert Helling
Hi,

Post by Robert Helling
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

[Willem Ferguson]

Post by Willem Ferguson

Post by Robert Helling
Hi,

Post by Robert Helling
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.

Post by Willem Ferguson
Kind regards,
willem

[Benjamin]

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

Post by Robert Helling
Hi,
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
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[Willem Ferguson]

There are some difficulties with calculating CNS% values de novo.
Attached is a document by Eric Baker: I have no idea when or where this
was published, probably early 1990s. It gives information for
calculating CNS% as well as OTUs for dives. In both cases the ultimate
sources appear to be NOAA documents in the late 1980s.

As far as OTUs are concerned the case is a bit simpler. I implemented
this for a few simple dive profiles and it appears that Subsurface
overestimates the pulmonary toxicity (OTU) count for a specific dive.

As far as CNS% calculations are concerned, I am not sure that the Baker
publication is correct. The CNS calculations include a lookup table of
slopes and intercepts to be used at different PPO2 levels. The
intercepts represent the max dive duration (minutes) at fixed PPO2
values, the slope parameter allowing for interpolation between fixed
PPO2 values. However, the lookup table in the Baker publication applies
to OTU calculations, *not* CNS calculations. The last line in the lookup
table is a total outlier with no apparent relevance. This appears to be
a gross error in the Baker publication. The example FORTRAN code (the
DATA block) that follows this appears to use this wrong (OTU)
information for calculating CNS% values. I digitised the graph from the
NOAA diving manual, presented as Figure 2 in the Baker document and
created a lookup table of intercepts and slopes for use in CNS%
calculations (this graph was presented in one version of the NOAA diving
manual but has been dropped since). Using these digitised values I
obtain realistic values of CNS% for some simple dives that broadly agree
with both the dive planner in Subsurface as well as with Multideco.

Obviously the calculation of CNS% is problematic and I would not like to
use these calculations in attempting to benchmark the CNS% calculations
in Subsurface.

Does anyone have any better information?

Kind regards,

willem

[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

[Robert Helling]

Hi Willem,

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.

thanks a lot for digging into this. Too bad, I have not really had the time, yet, to read up on this (I had a quick glance at the Baker paper though). I should say, this is in no way “my” calculation, I had nothing to do with it. According to

git blame core/divelist.c

Glance wrote that in

commit 186c27f17c0a865c4a484437a28497b6a5765366
Author: Anton Lundin <***@acc.umu.se>
Date: Tue Apr 9 19:25:21 2013 +0200

Add a simple table-based cns calculations

Maybe he knows more.

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
Phone: [phone] Theresienstr. 39, rm. B339
http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515 BB44 0820 367C 36BC 0C1D and
DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F

[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

[Anton Lundin]

Post by 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.

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

[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