Deco algorithm verification

AD_ward9

We want to publish our deco algorithm models. Would appreciate some feedback on what is considered adequate verification.

To set the scene, there are some things that worry us:

1. Virtually all references used for deco algorithms seem to have errors. In fact, all references we have used have errors. What this means is we can produce the same result as the reference publications, but only by inserting an error into the algorithm: in some cases this is a series of rounding errors, in others failing to account for all tissue compartments, in others, plain errors in the equations.

2. Chris at Abyss seemed to have tried his best when RGBM was coming out. He produced a simulator, did lots of comparisons, got feedback from a wide base and seemed to be working closely with Bruce Wienke. Now problems arise on dives to depths where none of these algorithms have been verified, and people seem to be sueing each other, sadly, Bruce seems to be walking away from Chris. See http://www.inspired-training.com/RGB...ds%20Model.htm

3. Divers seem to rate models by how fast they bring them to the surface. This means the best models for the human being, are rated the worst by the diver. Easy way to cheat: leave off the last few tissue compartments as these double or triple the deco time - the result will be nerve damage but not really noticeable short term. Some published papers do just this. This makes verification a nightmare.

So, what do we do?

We have Matlab and Simulink models of ZH-16A, VPM and RGBM, or at least our understanding of each: RGBM is being hidden by its authors. These models are run and compared the C version of the algorithm: the results should be identical. Being graphical, the Simulink model is easy to verify. Anyone can check easily each line of the equation against published sources and can see exactly what is going on.

Starting with the ZH-16A algorithm, we will publish a report giving the Simulink model, describe how the algorithm works, and show some examples. We will use the same examples as in the common references used to implement the algorithm, and we will tabulate the errata in those references so when our numbers are different then the reason can be traced easily.

This then gives a reference model than anyone can use to verify their version against.

We then run a few million profiles. Each profile takes about 80mS to run on a fast processor (or about 1.5 seconds on a desktop PC). So a server farm with 16 processors spare can run 17 million profiles a day. This means about 8 million reference profiles and 8 million coded profiles. If we run it for a week, that should give as many profiles as people have used in the history of diving. That seems to be sufficient, as that is orders of magnitude more information than contained in the knowledge base on which the deco algorithm is built.

For ZH-16 and VPM models, this approach is easy because the algorithms are published. We can simply publish our verification models and our data.

Moving onto RGBM, Bruce Wienke has a database of about 3000 profiles, we understand, but has declined to make these available to us to check our RGBM interpretation against his (licensed) versions. In this case, we will check carefully what we have against what is published, then publish our results and compare against the other sources.

Anyone with any better ideas on how to verify a deco algorithm?

We will leave this offer open until mid Jan 06, then publish the ZH-16 models. VPM will follow once we have concensus on the ZH-16.

Cheers

Alex

abowie

Retrain divers. Sorry I know that's not particualrly helpful to you in your current situation.

__________________
Andrew Bowie

Rebreather-friendly Buddy

dantheman

Can you elaborate on this?
Until your algorithm is verified, I don't see how it can produce a reference profile.

And this is the chicken and egg problem you are grappling with.
I want to help, as I have some similar concerns.

--dan

Genesis

This would be INCREDIBLY useful...... I'm definitely looking forward to it...

jradomski

Ellyat deserves what he got, and so does Chris for helping Ellyat.. The RGBM model as supplied by B.W. is specifically limited to 180m.. This is documented. The abyss implementation was a work in progress, and it only worked with trimix, it wasn't valid for other gases..

If ellyat wanted to do this deep stuff using abyss he should have stayed with the dissolved gas model within abyss.

Throught RGBM Bruce uses approximations for the various differential equations so his limits must be observed. This depth was chosen as the limit used in the approximations because around this point fluid shifts have to be accounted for and there is no real data on that..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

AD_ward9

You are right: it is a chicken and egg problem.

Using Matlab and Modelsim, we have written the algorithm down in a very clear manner. Exactly what the algorithm is doing is also very clear because of the graphical nature of Simulink. We check each line in the published equations/algorithms against our model, and verify that the model is executing them correclty (or rather, we have typed them in correctly).

The only spanner in the works is that the various publications of decompression algorithms seem to have a lot of errors in them. These range from simple things line printing (1/k)*PPN2 as 1/k*PPN2 (works in FORTAN, but is not correct in printed form), to rounding errors that accumulate enough to affect a result by 6%, to complete misprints, and then the cheats of leaving off the slow compartments when running examples. The result is we have a nebulous body of knowledge which is coded up into a precise structure, almost crystal like in its rigorous definition. That is a dangerous thing to do, and worries us.

We then have a different group, with a Chinese Wall to the first group, write the algorithm as they understand it. We run millions of the two together, comparing results automatically. When the results differ, each group must go off and find why. When one group changes their code based on the perceived error, that is another danger point (the Chinese Wall is perforated).

So, let us start by publishing the Matlab and Simulink model, with the clearest possible description of exactly what we have coded up. We have written this up, just checking our spelling etc and it should be out as soon we get over the New Year holiday (Bob Davidov is working with me on this, and is in Russia - where there is no Christmas but 9 days of holiday for New Year).

Cheers

Alex

Genesis

Alex, the obvious question is whether the printed copies have errors or the algorythms as implemented have errors!

Even if you have a "reference" implementation, that doesn't mean you have what's in a piece of computer software, or a wrist meter. Have you been successful in getting the actual code that is in the meters and/or desktop software - in source form - so you can see what's REALLY there?

Or is that the point of the simulation - to attempt to verify that what you think you understand is what someone implemented?

If the latter, that doesn't prove that you're true to the model - just that you get the same result. If the implementation you verify against is wrong, so are BOTH of your results - even though they agree.....

AD_ward9

I do not know how much Chris helped Mark Ellyat. Mark knew perfectly well that there was no data or verification at the 300m+ depths he was nipping down to and the risks he exposed himself to. His choice of air for very deep dives shows how he regards those risks it is his choice - great if it works, really mucks up the future plans if it does not.

I hope Mark will come to realise that plaintiff lawyers are leeches who feed on immature types until their victim is so drained they drop off and go elsewhere. Lets see what Mark looks like when they drop off: how much time and money he will have given to total strangers (his legal team). I hope Mark Ellyat reads this so he can put is energy into something that contributes to mankind rather than become a feeding pot.

Back to subject:
We are running the algorithm comprisons for depths randomly distributed for 10m to 600m for verification purposes (ie, of each algorithm). When this is done, relating statistically the differences in profile will be interesting.

Cheers,
Alex

AD_ward9

Your first question: yes, we do have a number of deco algorithms in source form written by other people, and several reverse engineered. The team writing our own code do have access to that information, and a separate QA team check very carefully that they have not used any of it. Ironic, isn't it.

I think you may have picked up our objective incorrectly: we are not trying to debug other people's code. What we want to do is to find how to verify our code. Running it against someone elses partially verified, difficult to read, code is not the route we are choosing, because it does not lead back to anything concrete. If we find a way to verify our code in an acceptable manner, publish it, then others may wish to use it. Fine: gives better code for us all to dive with.

Steps in the route we advocate are:
1. Take the papers in which the deco algorithms are described, and express them in Matlab/Simulink. That is, we take the papers as a group because in that way there is peer review of what is published and the theory accepted by the peer group.

2. Publish the Simulink model, fully documented. Simulink is really transparent: graphical, easy to check.

3. Publish what errors we think exist in the common papers (or at least pick a paper we know someone else used for their code and point out what we think that meant to say and what errors their printer inserted), with comparison of results before correction and after correction.

4. Solicit feedback.

5. Do this for several algorithms.

6. Publish results, and hopefully others will have run the reference model against their own implementation and also publish results. Result is a refined model.

7. You now have a group of reference models. Then anyone who has written a deco algorithm can run it against the reference models. If there are differences, and they think the differences are due to an error in the model, then can post to a public forum (this one) and say so. The authors of the reference model can then answer them or correct.

As I said, any better ideas?
Cheers
Alex

Genesis

Ok, I understand now....

The reason I asked specifically about various meters and implementations is that while, for example, the VPM code is available publically, the base VPM code isn't what's in Ross' software, for example....

I like where you're going with this - that could be extremely useful to a lot of people - perhaps myself included......