On 10/12/2016 00:43, Robert Helling wrote:
John,
Am 09.12.2016 um 22:51 schrieb John Van Ostrand <[email protected]
<mailto:[email protected]>>:
On Thu, Dec 8, 2016 at 9:36 AM, Willem
Ferguson<[email protected]
<mailto:[email protected]>>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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
