Graph documentation [was: Re: Meaning of GF settings]

[Dirk Hohndel]

"Robert C. Helling" <helling at lmu.de> writes:
> re b) I implemented it with a compiler option as I think, ultimately you 
> want to set it to FALSE and remove the other code but did not do that so 
> you can easily compare the two possibilities. As I said, I don't think it 
> makes a big difference but from Baker's text it is clear he means "FALSE". 
> But as the gradient factor thing is an ad hoc hack and has no real 
> physiological basis (apart than giving similar profiles as bubble models) 
> "TRUE" is likely to be a similarly valid deco model (assuming good 
> parameters), it's just not Baker's.

Ok - that makes sense. I'll take the patch as is.

> a) I did as otherwise the computation of the moving ceiling as reference 
> for GF_low has no consequence at all for dives with a ceiling that never 
> gets deeper than 20m (like my test case). But you are right, you want it 
> deeper. This whole gradient factor business is there to add deep stops and 
> you only want those for sufficiently deep dives. So at least 20m is 
> probably a realistic value.

I will adjust that accordingly.

>> The reason I decided to give the ceiling in multiples of meters (and sadly of
>> ft for imperial users, but I am considering switching this to multiples of 5 ft)
>> is that you otherwise end up in a 'fake precision' situation. There is no such
>> thing as 10cm precision of knowing where exactly you risk getting bent.
>
> 100% agree. I only said that as I had the impression that Jan was worried 
> that his computer had cleared the deco while the mouse over still hat a 1m 
> ceiling. I wanted to say that the real difference is likely to be even 
> smaller but again, even a 1m difference does not have much of a practical 
> significance.

Ok. Totally agreed.

>> Finally, hey, Robert… would you like to help us implement an alternative
>> deco algorithm as well? I think there are quite a few people who would be
>> interested in comparing the profiles between Buehlmann with GF and say
>> VPM (which I think is the only bubble algorithm that is sufficiently
>> documented that we could try an implementation, anyway).
>
> Hmm. I don't have a strong urge to do that I have to admit. Of course, I 
> would be intererested in the results. The problem is only that the prose 
> descriptions of VPM are far from being precise/clear enough for me to be 
> able to turn that into a (or better: the correct) program. There is, of 
> course, the FORTRAN (in all capital letters) source code (or what f2c made 
> of that) on http://www.decompression.org/maiken/VPM/Links.htm . It was bad 
> enough for me to write C (which I had not done in about 10 years given I 
> earn my living in other ways), but 176k of FORTRAN? I had printed that a 
> couple of years ago and starred at it for a significant amount of time but 
> I have not been able to completely grasp the logic.

I hear you. I learned FORTRAN in high school and forgot it as quickly as
I could. I actually looked at those same sources before Heinrichs and
Weikamp kindly offered to let me start from their C sources...

> Now might be a good time for me to try that again. But doing that and then 
> reimplementing this in C is certainly not something that I can do in a 
> day. So, no promises.

I wasn't asking for that. Seriously. I really appreciate the work you
have already done. I was simply wondering if this would be something
that long term you'd be interested to play with.

> In addition, I don't believe that VPM(B) (or RGMB for that matter) does 
> any better than gradient factors as the additional parameters (like 
> physical properties of the bubbles) don't have a good empirical basis 
> (like varying those, producing a number of different tables, running real 
> decompression experiments at least with goats and from those determining 
> the values that get you out of the water in a save way as fast as possible 
> for a large number of dive profiles). Everything else is just varying the 
> parameters to obtain those deco profiles you knew before were reasonable. 

Yes - that always bothered me. What bothered me even more was that some
of the discussions with the original RGBM authors that have been
documented online clearly seemed to show that they literally started
from "known good profiles" and then tried to make their algorithm fit
those. That seems a wee bit backwards to me.

But what I like about VPM(B) and RGBM is the abstract idea behind it. To
me it feels more "right" to try to estimate the bubble build-up then to
use some magic formulas to make 16 (or fewer in many cases) compartments
that simulate my tissues match empirical data. Call that naive (because
frankly, I realize it is), but I would love a working, well tested
bubble model :-)

Having said that - questions about this keep coming up and allowing
people to play with this in the rather nice visual representation that
Subsurface can do - and do so on top of their own dive profiles... I
think that does have value.

I certainly have spent way more time than I'm willing to openly admit
using different GFlow/high pairs against my existing deco dives... :-)

Thanks again!

/D