Mailing List Archive

Mailing List: techdiver

Message Display

Hi me again!,

>
> > This is rather more than a little bit hard to swallow: are you trying to imp
ly
> > that as a software vendor you have no responsibility for any results of usin
g
> > your product??!!  So I suppose then that you advertise your product as simpl
y
> > being an electronic Buhlman table, and not a product which generates
> > decompression schedules?  NOT!
>
> Our software is a calculator, a tool.  The user generates decompression
> scheduals, not the software.  It's made pretty clear in the MiG Plan user's
> guide.
>
> > o Buhlman has never claimed that his research was to be used the way tech
> > divers currently use it: as a straight algorithm to generate deco schedules
> > for real-world diving.  Somehow, I get the feeling that you do not properly
> > relate this to your clients...
>
> Sure he has.  He presents his algorithm, explains how it can be used to
> make tables, and gives you a set of air tables to both save you the hassle
> of making them yourself, and to give you a standard to check your math
> with.  I've never heard him quoted as saying "look, making tables like
> this is unsafe."
>
> > o The straight Buhlman algorithm lacks conservativeness, and has been
> > responsible for many cases of DCI.  If you somehow add conservatism to the
> > algorithm, you are then no longer producing even a version of the Buhlman
> > algorithm, but rather a one-off deco algorithm which is completely untested
> > and unproven.
>
> As far as I know, all the popular models (with the possible exception of
> the DCIEM model, anyone who knows otherwise please jump in here) have

Yep, I've been with someone hit diving DCIEM (I must be the kiss of death!!)
Cheers Jason O-)

> been responsible for many cases of DCI.  There is a statistical risk of
> DCI on any resonable exposure dive, and even very "conservative" tables
> would not eliminate it.
>
> I don't think that adding small amounts of extra conservatism helps you
> very much.  I don't hear people running around saying "boy, with the new
> shorter no-dec limits on the RDP we have only 10% the DCI we had on Navy
> Tables."  Once you get to low risk, you get dimishing returns with
> increased conservatism.  It may be that Buhlmann tables are not low risk
> when they are used for dives with hours of decompression, and in that
> case adding some conservatism would be prudent (says so in the MiG
> user's manual, in-fact.)
>
> > o The entire notion of "adding conservatism" is a rather interesting area to

> > explore: how are you sure that the modifications you made to the Buhlman
> > algorithm actually do increase conservatism (and therefore safety)?  Did you

> > test them?  Is more decompression time always more conservative?  Can you
> > prove this?  Oh wait, I forgot: you are not responsible for the outcome of
> > using your software!
>
> Adding or lengthening decompression stops without a mathmatical basis can
> produce unpredictable results and is therefore a BAD IDEA.  Pulling back
> the maximum super-saturation gradients (M-Values or factor a's) is a
> mathmatically sound approach.  Does it increase reliability?  Maybe.  It
> is the best we can do without a totally new model.
>
> > o How do you know that the output of your program is actually faithfull to t
he
> > Buhlman algorithm?  Can you prove your implementation of the Buhlman
> > mathematics rigorously?  Do you test your software with the naieve approach
of
> > running some number of known dives, or do you actually do something more
> > sophisticated?  Remember, people are trusting their life to your software --

> > but of course, you deserve neither credit nor blame for the reliability of t
he
> > output, right!! (NOT!)
>
> We did extensive testing against Buhlmann's published tables, ensuring
> that our numbers agreed EXACTLY.  There is little to prove in the basic
> math we used; we use exactly the same equations as Buhlmann uses for the
> most part.  We are not using any fancy iterative equasion solving methods
> that could yield unexpected results under some conditions, so the risk of
> the program giving correct answers for one set of numbers but not another
> is near zero.
>
> > o How would you feel about this situation:  Boeing produces a new, computer
> > controlled plane, but they use the fly-by-wire algorithms developed by Airbu
s.
> > Rather than subject the plane to rigorous testing, they simply claim that
> > their implementation is faithful to the original algorithm development done
by
> > Airbus, so Boeing bears no responsibility.  Would you fly in that plane?
> > Would you insure it?
>
> Fly-by-wire is a control system.  Control systems are based on feedback
> loops, in the case of fly-by-wire many many feedback loops.  This type of
> system is prone to develping osillations and sudden violent control
> deflections until the interacations between each of the systems is fully
> optimized.  This type of system must be given rigerous testing because
> its actions under all conditions cannot be fully predicted in the lab.
> Despite such testing, there have been several accidents caused by
> fly-by-wire systems in Airbus's, largely attributable to that most
> critical interaction between the control systems of the airplane and the
> pilot.
>
> A program such as decompression table generator does not use feedback
> loops, and there are no possible "strange" interactions due to the
> influence of other variables such as wind gusts in fly-by-wire systems.
>
> > o Adaptations of the Buhlman algorithm for Trimix diving are hacks which hav
e
> > never been supported by Buhlman.
>
> There are accepted methods for using models to make mixed gas tables.  I
> have never heard them disputed.  If you do not accept the view that these
> methods are safe, then you should limit yourself to air diving because all
> other tables, from NOAA Nitrox to US Navy Heliox tables are based on them.
>
> > o The Buhlman *tables* are just that: tables.  The *tables* have built-in
> > rounding which makes them inherently different than the Buhlman *algorithm*.

> > Unless your software is simply doing table lookup, it does *not* generate th
e
> > Buhlman *tables*.
>
> Not true at all.  The Buhlmann tables match the algorithm exactly.  There
> are no "fudges" to the tables, I assure you.  There are a couple things
> in Buhlmann's book that many people overlook when designing software to
> generated his tables, resulting in small descripancies that many people
> pass off as "rounding errors".
>
>     Jody Svendsen
>     MiG Technologies
> --
> Send mail for the `techdiver' mailing list to `techdiver@opal.com'.
> Send subscription/archive requests to `techdiver-request@opal.com'.

Navigate by Author: [Previous] [Next] [Author Search Index]
Navigate by Subject: [Previous] [Next] [Subject Search Index]

[Send Reply] [Send Message with New Topic]

[Search Selection] [Mailing List Home] [Home]