Meaning of GF settings

[Dirk Hohndel]

Jan Schubert <Jan.Schubert at GMX.li> writes:
>>
>> So while we do the smooth calculation for most of the time, the GF
>> pushes us into 3M changes... I think I'll play with a modification that
>> does the loop here with 1M increments if we are in 'smooth' mode.
>>
>> Do you think that would be useful, Jan?
>
>
> 1m ist still to much to be considered smooth in my humble opinion. Why
> not use 0,1m instead? And of course you should stick to 3m when doing
> the NonSmooth mode.

ok, I'll do 10cm or 4in. Easy enough :-)

>> What is missing at this point:
>>
>> - UI
>
> Yeah would be nice. We should allow to configure several parameters
> there which are now fixed. F.i. surface pressure is set to 1013mbar
> several times, in my regions we use to have around 940-970mbar (which
> would make some difference for deco calculation). Of course I've seen
> that this could be changed in planner.c.

The logic is this: if it surface pressure isn't set, we default to
standard pressure (and that is indeed 1013mbar). But the data structures
are setup so that the diveplan contains the surface pressure (the other
thing I was considering was to look if there is another dive that ended
less than 6h ago and if no surface pressure is set in the plan, but a
surface pressure is in that last dive, to take that instead).

> Please also note that there is also a safety_dist_deco_stop of 0,5m
> defined in deco.c from the DR5. This is not used so far from what I've
> seen but if we do in future calculations this should also be a
> configurable parameter (like in the OSTC firmware).

The logic here is that you are usually stopping slightly below the
planned deco stop depth. I find that just a bit silly to use in planning
software. Because all you do is lying to yourself - instead of 6m and 3m
you are now planning for 6.5m and 3.5m stops... what's the point?

>> - gas use prediction based on SAC rate (for OC folks)
>
> Very important part, also for CC bailout calculation. Note: It is common
> to differ between a (higher) bottom SAC and a (lower) deco SAC. And then
> it would make sense to have a link to the tanks used and defined in
> subsurface and previous dives (which I never used so far).

long term goal would be to walk back through the divelog and
pre-populate the fields with data from dives that look similar... but
the problem is the definition of similar. In warm water with a single
tank my SAC rate tends to be about 50% of what it is in cold water with
full tec gear (twins, two stages, etc). So for the first version I'll
just give you "SAC during travel time" and "SAC at deco stop".

>> - printing of tables (with big disclaimer on them)
>>
>> and then maybe
>>
>> - multiple deco algorithms
>
> Would be appreciated very much!

That will require finding good sources to start from. And in general
starting from Java sources is a nightmare. Java was invented by people
whose brains work differently than mine.

/D