Perdix CEIL, does it take into account the estimated off-gassing on ascent (with an assumed ascent rate)?

[NX32]

Damn, this thread got very interesting and informative.

I was surprised that Shearwater claims CEIL takes into account off-gassing on ascent just as NDL does. While NDL makes sense (as in an actual limit with a way out given an ascent rate of x), "adaptive" CEIL is counter intuitive to me - I was sure it's an objective depth at which you're oversaturated over the limit (pretty much as SurfGF is an objective, yet theoretical metric that assumes you'd teleport to the surface). One could argue theoretical is useless, but it's informative on its own.

On the other hand, while typing it out I realised it might make sense. While SurfGF gives you an oversimplified idea "how loaded you are", CEIL should be consistent with NDL in this regard.

While I don't like it on a theoretical level, I think I'll have to adjust my model implementation and maybe introduce a separate "calculating ceiling" metric (like SubSurface) to still be able to provide it by both definitions. Given my code, in most cases even with current raw ceiling actual stop calculations come down to the same thing 99% of the cases, but still..

 

[dmaziuk]

I was surprised that Shearwater claims CEIL takes into account off-gassing on ascent just as NDL does. While NDL makes sense (as in an actual limit with a way out given an ascent rate of x), "adaptive" CEIL is counter intuitive to me ...

If you don't, your users can end up with a ceiling and non-zero NDL at the same time, and get confused. This is an "implementation detail" for you to figure out.

 

[NX32]

If you don't, your users can end up with a ceiling and non-zero NDL at the same time, and get confused. This is an "implementation detail" for you to figure out.

Absolutely right. I mean it made sense to me, but I absolutely get the business decision behind that. I didn't expect it to work that way, there's a reason I didn't notice it though - in OC TEC I use CEIL as a replacement for NDL, so while I always take a lot of time analysing different readings (especially right on the edge of going into and during deco), that's one detail I didn't catch because of that.

EDIT: Right, while that's an implementation detail in the context of a product, my implementation is a library that (hopefully) would be a ground for other project, retroactive computation for some purposes etc (and a core for my emulator, but that's an actual "product" that can have implementation details). As such, it shouldn't have any implementation details, but to be fair, that goes beyond just the model - if that was the case it wouldn't calculate anything besides tissues saturation and instant M-values, everything else starting from GF and all its implications are in fact implementation details (not to mention deco stops etc, it got out of hand a bit I guess), but I'm trying to balance that and keep it as raw as possible. Maybe splitting it is actually a way to achieve that