Meaning of GF settings

[Dirk Hohndel]

Jan Schubert <Jan.Schubert at GMX.li> writes:
> Oh forgot to put some notes to Dirks question about the "odd shape" of
> the deco ceiling curve: When calculationg the deco ceiling all the 16
> tissue compartments has to be taken into account. The deco ceiling is
> defined by the compartment/tissue having the highest overpressure,
> called the leading tissue. This leading tissue can (and will!) switch
> during a dive resulting is such mentionable jumps (ups  and downs) when
> looking at the smooth deco ceiling curve not based on 3m steps. 

That part I understand - what surprised me is how drastic these steps
are. It seems as if there still is a 3m step hidden in the code
somewhere... and I already found where... it's in the GF adjustment
code:

	new_gradient_factor = gradient_factor_calculation(&mydata);
	below_gradient_limit = (new_gradient_factor < actual_gradient_limit(&mydata));
	while(!below_gradient_limit)
	{
		mydata.pressure += PRESSURE_CHANGE_3M;
		new_gradient_factor = gradient_factor_calculation(&mydata);
		below_gradient_limit = (new_gradient_factor < actual_gradient_limit(&mydata));
	}
	depth = rel_mbar_to_depth((mydata.pressure - surface_pressure) * 1000, dive);
	return depth;

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?

> In my opinion nothing strange but really nice to see as all the dive
> planning software (not saying that subsurface is supposed to be such a
> software!) 

Actually, that is the part that I am trying to add right now. The gual
would be to have the best dive planner simply integrated in Subsurface -
it can then use the knowledge of the dives you've just completed without
having to approximate them when typing them in. And given the way things
are set up it should be very easy to support multiple deco algorithms
and compare the results (that latter part will need a little more
infrastructure, but I think I have figured out how to do that, too).

The biggest challenge is the UI. We need UI people. Urgently.

> I know is just printing run time tables based on 3m steps. Personally
> I really like this profile based visualization and being able to
> switch 3m stops on and off - helps me understand decompression theory
> better.

The printing of tables could easily be done based on the diveplan
structure - which means it would simply use the stops that you
pre-define. Should be really easy to do.

What is missing at this point:

- UI
- gas use prediction based on SAC rate (for OC folks)
- printing of tables (with big disclaimer on them)

and then maybe

- multiple deco algorithms
- better ability to compare between them

(and I want to do some caching in the infrastructure - right now we
re-calculate the same information over and over and over... I know how
to do that, just ran out of time last night)

/D