Retrospective gradient factors on real dives

[Willem Ferguson]

On 10/12/2016 00:43, Robert Helling wrote:
> John,
>
>> Am 09.12.2016 um 22:51 schrieb John Van Ostrand <john at vanostrand.com 
>> <mailto:john at vanostrand.com>>:
>>
>> On Thu, Dec 8, 2016 at 9:36 AM, Willem 
>> Ferguson<willemferguson at zoology.up.ac.za 
>> <mailto:willemferguson at zoology.up.ac.za>>wrote:
>>
>>
>>     Would it be feasible to calculate retrospective gradient factors
>>     on real dive profiles? We sometimes use a VR3 dive computer which
>>     does give this information, but it would be very useful to to
>>     have it being calculated automatically for each dive.
>>
>>
>>  Do you mean you want to see the decompression stops for a different 
>> set of GFs? Or do you want to automatically find the most liberal GFs 
>> that fit a dive profile?
>>
>> For the former questoin set up GFs in the Preferences and go back to 
>> view the dive. For the latter question I iterate through GFs manually 
>> to find the closest one.
>>
>
> I guess what Willem meant was to do something along the lines we do 
> now for VPM-B planned dives: There we compute GFhigh/low such that you 
> would get a similar decompression profile.
>
> I have not yet answered to Willem’s original mail as I do not really 
> know how one would implement this. Here are my thoughts: At each 
> instant of time during the dive, we could compute a gradient factor 
> such that the current depth would be the ceiling. That part is easy. 
> One could then try to find  a line in the gradient factor vs depth 
> plot that best approximates these points. The problem is that this 
> makes only sense during the decompression phase of the dive, i.e. for 
> the time where it makes sense to consider the current depth to be at 
> least roughly the ceiling. During the bottom part of the dive as well 
> as during the first part of the ascent this would give you far too low 
> gradient factors.
>
> So we would need to find out for which part of the dive to apply this. 
> I don’t know what a good criterium would be: Something like the last 
> 25% of max depth? Some part where the ascent is slower than the 
> current ascent rate? We could take user input (maybe in form of the 
> ruler) or we could find that last part of the dive where a linear 
> approximation for the gradient factor vs depth plot is best (measured 
> in chi squared or something similar).
>
> Best
> Robert

Yes, I was implying the interpretation that Robert gave to my initial 
idea, something similar to what is calculated for dive plans under VPM-B 
in Subsurface. I agree that the part of the dive over which the FGs need 
to be calculated could be problematic. As examples I attach two images 
of dive profiles. The first case is a dive where GF information would 
really be useful. The ascent is is clearly defined and was planned using 
VPM-B and GFs can be calculated from 75% or 80% of the maximal depth. 
The second case is a different type of dive (a cave dive in this case 
with clear levels) that would make it very difficult to calculate GFs. 
But in this case the GF information is not nearly so important as in the 
first case. So if there is a lot of noise in the second case it is not 
serious because there is not a ceiling that has been used as a yard 
stick to determine the ascent. I suppose the possibility is that one 
could use the ruler of the profile toolbar and use the two ends of the 
ruler to determine the part of the dive over which the GFs are 
calculated. This would make the operation user dependent. My main point 
is that, for dives where the GF data would be really useful, there is 
unlikely be a demarcation problem and one could start not very far from 
max depth up to the point where the surface is reached.

Thank you for your time an considerations.

Kind regards,

willem


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20161210/f3913c07/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: secondcase.jpg
Type: image/jpeg
Size: 21952 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20161210/f3913c07/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firstcase.jpg
Type: image/jpeg
Size: 26032 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20161210/f3913c07/attachment-0003.jpg>