RFC: support for deco algorith and parameter fields

[Dirk Hohndel]

On Thu, Oct 16, 2014 at 03:43:11PM +0000, wrob311 at gmail.com wrote:
> On Thu Oct 16 2014 16:09:06 GMT+0100 (IST), Jef Driesen wrote:
> [...]
> > 
> > +typedef enum dc_deco_alg_t {
> > 
> > I'm not really in love with the "deco_alg" abbreviation. But 
> > "deco_algorithm" becomes pretty long. Maybe just "algorithm", or 
> > "decomodel"? Other suggestions are welcome too.
> 
> While 'algorithm' is used quite often, the 'model' is more correct,
> IMHO. Quite often a simple change to deco model parameters causes its
> name change i.e. ZHL-16B vs. ZHL-16C. Calling them two different
> algorithms does not make sense.

Yeah, I like dc_deco_model_t

> > +	DC_DECO_ALG_BZH,    /* Buehlmann ZH, no GF */
> > +	DC_DECO_ALG_BZHGF,  /* Buehlmann ZH, with GF */
> > 
> > The BZH name sounds a bit cryptic to me. How about naming it BUHLMANN 
> > instead?
> 
> If I am not mistaken Buhlmann was calling  his models ZHL-XY, i.e. ZHL-16C. There are Buhlmann models with different number of tissue compatments than 16...

I thought about that - but given how incredibly sloppy many of the
implementations are (often due to limited processing power), it seems that
even if the vendor were to tell you exactly which model they use (as some
do), there is very limited benefit in knowing that. More importantly, I
believe in most cases we don't know which exact model has been
implemented. Some don't even tell you if they use gradient factors (and
which ones).

> > > DC_FIELD_DECO_INFO
> > > 
> > > and
> > > 
> > > struct dc_deco_information_t {
> > > 	unsigned int algo;
> > > 	unsigned int param1; /* e.g. GFhigh or GFS */
> > > 	unsigned int param2; /* e.g. GFlow */
> > > 	unsigned int param3; /* currently unused */
> > > };
> > 
> > I'm not really sure what would be the best solution here. Are there any 
> > other algorithms besides the GF that have parameters that make sense to 
> > support? One concern is that with an integrated structure, we can't add 
> > new parameters if that's ever necessary. I'm not really in love with 
> > placeholder fields either. While with a separate DC_FIELD_DECOPARAMS 
> > type, we can introduce different data structures for each deco 
> > algorithm. For example:
> > 
> > struct dc_decoparams_gf_t {
> > 	unsigned int low;  /* e.g. GFhigh or GFS */
> > 	unsigned int high; /* e.g. GFlow */
> > };
> 
> You are basically opening a can of worms. :) Manufacturers like to add
> their own parameters it seems. Look at OSTC custom functions where
> ZHL-16C is extended with desaturation/saturation multipliers ( note:
> non-GF version).

Both versions, I believe.

> Also there are parameters which I find hard to classify. Is calculating
> your deco 1m deeper than you are part of deco model extension or a
> safety feature? And these are probably specific to a dive computer
> manufacturer. 

And most of those are not really well specified or documented.

I get specific requests from tech divers to show the gradient factor used
by their dive computer on specific dives - I think that's because
Subsurface shows the GF we use for our own deco calculations and people
want to be able to compare. I have not received any other requests for
paramters. I simply made this somewhat more generic when I saw in the
Shearwater documentation that they have the fused VPM-GSF where they
basically take the lower ceiling of VPM or Buehlmann with that parameter
as surface GF (so basically GFhigh).

> Maybe the best structure would be simple list of (name, value) pairs for
> all dive computer configration options (name being a string)?

Interesting. What exactly would that include? Metric vs imperial? 12 or
24h? yyyy-mm-dd or mm/dd/yy? Just trying to understand how broad you take
"all configuration options".

/D