ON GETTING SAUL INTO DIVE COMPUTERS

A recent comment on my The Doctor is In Part IV blog post, followed by a more detailed letter to me raised some issues that need to be addressed.  The comment read as follows:

SAUL sounds like a giant leap forward in dive safety and one that will always be attributed to the brain work of Dr Saul Goldman. As far as I understand however a route has been chosen to make the invention a proprietary solution, which is an unbelievable shame. Have you considered to make this algorithm available to the public domain so that *every* dive computer manufacturer can implement it, including those that do not want to be involved in the proprietary IP madness of this world. What if Einstein had taken a patent on all his inventions? What’s more important: A bank account or saving lives?

The writer refers to my making SAUL “a proprietary solution”.  This is not exactly the case.  SAUL – or, more accurately, the model upon which it is based – is patented.  What’s the difference?  A proprietary solution is generally kept secret, because, not being patented, secrecy is often the only way to protect it from being “stolen” by others.  A patent provides its own legal protection, is not secret, and, in fact, is published online by the U.S. Patent Office.  In addition to that, my article in Journal of Physiology (which can be downloaded from the Articles section) contains details of my model.

The two main objections the writer seems to have to what he calls a “proprietary solution” are: first, that he would like every dive computer manufacturer to be able to implement it, and, secondly, some apparent distaste for my wanting to make money from it.

I have no problem with the first objection.  In fact, it is my goal and my expectation that  every dive computer manufacturer will eventually implement it.  I have no intention of selling exclusive rights to a single manufacturer, nor have I ever considered doing so.  SAUL was, and is, my way of giving something back to the diving community for all the enjoyment I have had, and continue to have from diving.

So, why do I not overcome the second objection by putting it in the public domain (or, as one computer manufacture I approached put it, “make it open source, like Buhlman”.)?   Perhaps I would – if computer manufacturers offered their products for free, mechanics repaired cars for free, airlines gave free flights, etc. – but I don’t really see that happening.

I spent years of my life, and a fair amount of my own money, developing SAUL and, while I’m not looking to get rich from it, there’s no way I will allow computer manufacturers to profit from it without my profiting as well.

There’s also a secondary reason I won’t make it open source:  The model underlying SAUL is different from, and more complex mathematically than, Haldane-based models (which includes all the others out there, including so-called “bubble-based” ones).  I have some concerns about the potential for people with insufficient mathematical and scientific skills trying to “adapt” or change the algorithm.

In his longer letter to me, the writer mentions some objections he has heard from dive computer manufacturers he queried: specifically, that they were either “unaware of” SAUL or that it was “untested”.  I can’t speak to whether any of them are actually unaware of SAUL (although I have my doubts).   SAUL is also no less “tested” – in a formal sense – than are any of the algorithms in use today.  While dive computer manufacturers do  test their computers before their release, they do not test the accuracy of the algorithm.  What they test is, essentially, the functioning of the hardware and the software environment – in other words, that the computer is actually doing what the algorithm tells it to do.

As far as being tested, the largest body of test data in existence was amassed in an extensive series of experiments conducted by the U.S. Navy, in conjunction with the Canadian Navy and the (British) Royal Navy.  Real-life testing to that same degree can’t  be done by anyone nowadays -  not even by the Navy  (some of it would never pass an ethics committee).  These provide the data that all algorithms use, either directly or indirectly, as they calibrate their equations to fit, as best they can, the known facts.  (In the case of SAUL, I had access to that entire data set and used it extensively.)   To the best of my knowledge and belief, SAUL’s predictions fit the Navy data better than any other algorithm.  I have also been given access to a large portion of the recreational dive data collected by DAN in their Project Dive Exploration.  SAUL predicted the actual incidence of decompression sickness in those dives very accurately, much more so than typical Haldane based algorithms whose predictions were too high by a factor of 10 or more.  SAUL is also the only model to account for the beneficial effect of safety stops and slow ascents.

It’s also worth mentioning, that I have given about 20 invited talks about on my model and related subjects to audiences composed variously of physicians, scientists, and divers.  I have spoken at meetings of the Undersea Hyperbaric Medicine Society (UHMS), American Academy of Underwater Sciences (AAUS), Canadian Association of Underwater Sciences (CAUS), South Pacific Underwater Medicine Society (SPUMS), and the International Congress on Hyperbaric Medicine (ICHM).   Of all the questions I was asked following these talks, the single most common one was “When will this be available in a dive computer?”  So far, I haven’t been able to provide a definitive answer to that question, but I’m still trying.


Comments

ON GETTING SAUL INTO DIVE COMPUTERS — 8 Comments

  1. I was also one of the guys making this kind of objections on another blog post.

    Just to add a point: making a program open source does not mean that you can not / you will not make money on it. It only depends of the terms of the open source licence you choose.
    You can easily authorize developments of other open source and free dive plannification programs (for example) and not authorize any commercialisation without your consent.

    This will certainly increase knowledges of your model, let power users/developpers ‘play’ with it. I’m sure this will also accelerate the real ‘dive computer development’ (having more than one implementation of the same algorithm is always a good thing for a developper)

    The ‘too complex’ argument is certainly not a good reason, for me it’s quite the opposite.

    Thomas.

    • Quite frankly, even aside from the money issue, I really don’t want power users/developers to “play” with SAUL. Even small changes can have large effects and could be dangerous. The fact is, there is no need to “play” with SAUL. I understand the need for power users to modify other algorithms. Sometimes, an algorithm seems reasonable enough on some types of dives but not on others. It may prevent you from doing a dive that you believe is safe enough. It may simply not fit your style of diving.

      SAUL does not have these issues. I say this, not just because SAUL is more accurate than the other algorithms (although it is), but because it operates based on a completely different paradigm. Where other algorithms set no-decompression limits (NDLs), SAUL calculates the actual probability of decompression sickness throughout the dive or series of dives. You, the diver, can decide how much risk you are prepared to take. Because divers are accustomed to NDLs, SAUL works with that. You enter the maximum risk of decompression that would be acceptable to you, and SAUL will operate as if it used NDLs, where the limit will conform to your preferred level of risk. But, alongside the time remaining calculation, SAUL will also continually show you the probability of decompression sickness if you were to begin your ascent right then with a 3 minute safety stop, and the same ascent without the safety stop. You might select a different level of risk if, for example, you were supervising an inexperienced diver than you would if you were exploring a wreck. What I’m trying to say here, is that you don’t need to modify SAUL in order to do the type of diving you want to do. You’re already in control.
      What else is there that you think should be developed?

      From my perspective, there is one additional thing which I will probably be doing in the not too distant future. Because it’s taking longer than I had hoped to get SAUL into dive computers, an online SAUL dive planner may be the next step.

      Would I ever provide SAUL to a developer as open source? Possibly, if there was a real reason to do so, but even then, only if I were confident in the developer’s understanding of the math and science behind the model.

      For the reasons above, there is really no need or benefit to having more than one implementation of SAUL.

  2. A Saul dive planner is a good idea. That would allow all of us to compare Saul to the decompression algorithm(s) we are currently using such as Buhlmann ZHL16-C with GF or VPM-B. This would also allow us to simulate series of dives, above what you wrote in one of your previous blogs regarding PADI NDLs.

    I don’t think I’ve ever seen how Saul handles a decompression dive (exceeding the time the model allows at depth without exceeding the chosen probability of DCS). Does Saul give typical decompression stops and times to lower the probability of DCS to a level below that which was chosen? How are the depths for the stops chosen, perhaps analogous to choosing GFs?

    • Good question. To answer it properly brings up a number of related issues, so it will be done as a blog post, which should be up within a couple of weeks.

  3. Hi Saul,

    Are there any plans on releasing a dive planning tool using the ICM.

    Also, and forgive me my ingorance, how would a potential dive computer using a probabilistic function work? i undertsand it may have a model like ICM, but how would te interface with the diver be? Would you see a DCS probability rating changing with depth or how would it work, and how would decostops be defined during diving? I mean the risk of DCS at depth would inherently depend on the ascent rate and any stops made under way?

    Thanks

    Christian

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha Captcha Reload

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>